Tinylauncher 3 Tooltype Support?
 

My Tinylauncher crashes on game selection whenever Tooltype support is enabled (by pressing 'T'). Is there a fix for this? What is the benefit of tooltype support? Do some WHDLoads come with important prefs stored in the tooltypes?

More importantly:
Why in god's name does WHDLoad save its prefs in the tooltypes in the .info file, and not in a little .ini file in the game directory? Tooltypes are pretty much impossible to use from the command line, only by clicking on the icon. Who launches their games by clicking on the icons?

If there was at least an option to specify the .info on the command line so that whdload will read the tooltypes...

Tooltypes are the most clunky part of Amiga OS IMO. Badly thought out and useless from CLI. Most mysterious behaviour I fought with in Amiga OS was because of some obscure tool type settings somewhere. The main problem of tooltypes is an important one: complete inconsistency between clicking on a program and launching from CLI, without any indication of what is going on. Storing important program preferences in the icon file is just a ridiculously bad idea IMO.

Do you use a ClassicWB with Scalos? It's known to have problems with TinyLauncher and tooltypes (though ClassicWB LITE is fine since it doesn't use Scalos as a WB replacement). You also have to install NewIcons or it won't work or indeed crash TinyLauncher.

Tooltypes are used for stuff like trainers, joypad selection, language selection, disable/enable caches, setting the quitkey etc. Of course you can launch every WHDLoad game via shell with tooltypes like that e.g.

whdload gamexyz.slave preload customx=x

Check the readme of a specific game which tooltypes are supported, e.g. custom1=1 could be a trainer, custom2=1 CD32 pad support and so on).

It's not. The prefs are saved in the "whdload.prefs" file which is installed/manually copied to the WB s: folder. The configs in the whdload.prefs file are global. Tooltypes set in gameicons overwrite the global settings.

Incorrect. There is a command called WBRun which loads programs as if you double clicked on the icon to start it, reads all the tooltypes from the icon.

http://aminet.net/package/util/cli/WBRun

Or via kgiconload (included in all ClassicWB setups).

kgiconload gameicon.info = starts the game with all tooltypes set in the icon.

There is also a WBrun included in OS3.9.

Sorry for asking but what is the difference between wbrun and kgiconload? I am getting errors with kgiconload so I am now interested in using wbrun to load games manually with tooltypes without clicking. Has anybody here tried wbrun with slave info files?

Something is cleary wrong on your side. kgiconload is rock solid on my real A1200+ClassicWB LITE. In emulation too. :confused

Still getting this error trying kgiconload included with ClassicWB LITE now:
"Failed to load segment"

Using ClassicWB Lite booting into CLI now.

I had it working before on a different WB setup. Must just be a problem with the version that's bundled in ClassicWB...

Nice derailment :) but nope. Have you tested this? I tested wbrun and it is completely useless for WHDLoad. wbrun does not take a .info file and then launch it as if you double clicked on it. It can't launch .info files at all. It can launch only other programs and then maybe just maybe it will load the tool types from associated .info? Does it REALLY load the tool types? I doubt it but didn't test after I found out it is useless with WHDLoad slaves. Which brings me back to how terrible tooltypes are again as a concept.

In other words, for sure wbrun cannot launch .info files directly. And WHDLoad slaves have an icon but there's no executable to launch with wbrun, only a .slave file.

So the ONLY option for this seems to be kgiconload. That makes sense to me because otherwise KG wouldn't have gone through the trouble of making kgiconload.