Trainer GUI

[Codetapper]

Incidentally Girv, whatever happened to your mega-trainer screen that was going to appear before WHDLoad games started up?

I think your energy would be far better spent on that as it would make setting cheats a lot easier than tooltypes, and would eliminate those annoying GUI's that popup on your installs!

[girv]

Incidentally Girv, whatever happened to your mega-trainer screen that was going to appear before WHDLoad games started up?

I heard Wepl was working on building something similar into WHDLoad so there was no point developing it further. That was some time ago though.

D'ya think its wise to start adding extra hardware hitting "whdtro" code to installs anyway? I wondered about that and came up with a Plan B to do a similar idea but as an OS GUI, but again since I thought something like that was going into WHDLoad anyway...

TBH I'm not sure what the best approach would be if the project were to be resurrected.

[girv]

and would eliminate those annoying GUI's that popup on your installs!

Not everyone thinks they're annoying ;) They can be disabled and they're removed in updates anyway.

[Hungry Horace]

just to jump in "as a normal whdload user" - i like to see all the cheats / variants etc done on tooltypes, and would like to avoid -any- kind of gui if possible.... (sorry Girv!)

largely because i use whdload a lot from my own GUIs, (in the style of the game menus) which means working with command-lines.... and i still like to include trainers where i can.


this thread has made fascinating reading btw guys

[Codetapper]

For the trainer, I thought the idea was it would be some extra module that WHDLoad loads and calls. The slave programmer would just put in a list structure something like:

dc.l LivesValue, YES_NO, _LivesName, DEFAULT_NO
dc.l EnergyValue, YES_NO, _EnergyName, DEFAULT_NO
dc.l LevelValue, NUMBER, _LevelName, MIN_VALUE, 1, MAX_VALUE, 8, DEFAULT, 1

LivesValue dc.l 0
EnergyValue dc.l 0
LevelValue dc.l 0

_LivesName dc.b "Infinite lives",0
_EnergyName dc.b "Infinite energy",0
_LevelName dc.b "Starting level (1-8)",0And a nice system-unfriendly menu (running inside WHDLoad of course) would popup with the 3 questions, mouse/joystick/keyboard routine that allows setting the values, and when it returns those 3 values would have been set to whatever the user selected.

And the same trainer module would be used in all slaves that support it so only one place to fix bugs.

[mr_a500]

I think your energy would be far better spent on that as it would make setting cheats a lot easier than tooltypes, and would eliminate those annoying GUI's that popup on your installs!

Hey! I like Girv's GUIs. They work fine and can be made to look quite nice if using VisualPrefs.

(using your own logic...)
Why go to all the work of changing Girv's GUIs when they work fine as is and will only benefit a few slaves? ;)

[girv]

@mr_a500: the suggestion was to make a common menu module to benefit all slaves.

@Codetapper: yes, a common trainer module, but would it be better as OS or non-OS ? Though I guess I have the non-OS one half done already :rolleyes

[Galahad/FLT]

Can't we all just hug and get along?

[girv]

Well alright come on then GHD, have a hug :D

[Codetapper]

The trainer module would have to be non-OS if it runs inside WHDLoad, otherwise it would require a kickstart image in devs. Plus you can debug them easier inside WHDLoad :)

[Galahad/FLT]

Well alright come on then GHD, have a hug :D

No tongues!!!!!! ;)

[girv]

The trainer module would have to be non-OS if it runs inside WHDLoad, otherwise it would require a kickstart image in devs.

What I meant was non-OS/WHDLoad or OS/non-WHDLoad, sorry :) So a non-OS module loaded into the slaves, or a regular OS program running outside of WHDLoad.

The WHDLoad module is probably easier to write but needs slave updates to be used. It also has an outside chance of being added to WHDLoad itself someday.

The OS program would be set as the default tool of the icon and use a definition held in a human readable text file to parse the other icon tooltypes and display a GUI, launching WHDLoad with the chosen options when its done. The advantage is that anyone who can understand the text file format can add a GUI to a game with no change to the slaves.

[girv]

No tongues!!!!!! ;)

Tongues!? That's not the sort of hug I had in mind matey. I was talking of a manly hug, of the kind shared by manly men and not in any way womanly or even slightly effeminate or homoerotic at all. Definitely no tongues.

;)

[musashi5150]

Possibly followed by the clearing of the throat and a conversation about football in a deep voice ;)

[girv]

Power tools, beer, sports cars or "Hot Or Not" would also be acceptable :great

Maybe a mod would like to split or move this thread? We've wandered off the title topic...

[Codetapper]

The OS program would be set as the default tool of the icon and use a definition held in a human readable text file to parse the other icon tooltypes and display a GUI, launching WHDLoad with the chosen options when its done. The advantage is that anyone who can understand the text file format can add a GUI to a game with no change to the slaves.

Personally I would prefer WHDLoad to handle the trainer screen. Anyone that launches games from the CLI (like CFou's tool and all the other launchers) would then have to know for game xxx you launch the trainer exe rather than WHDLoad.

If there isn't enough memory to run the game, the external trainer menu would still appear, pick all the options, then WHDLoad says it can't run the game. The external file would still have to process and handle possible bogus data in the text file vs assembled flags similar to a patchlist in the slave which is far easier to check.

The WHDLoad method would also mean you are not restricted to 5 CUSTOMX tooltype parameters passed to the game. The trainer menu itself could be globally disabled for people that do not like cheats.

[Hungry Horace]

so much serious discussion!



all i hope is that you allow "us norm's" to still disable the GUI (be it OS or non-OS based ) and still access the cheats via standard tooltypes (like the massive "Zeewolf 2" set of addable tooltypes!) should we want to....

[girv]

all i hope is that you allow "us norm's" to still disable the GUI (be it OS or non-OS based ) and still access the cheats via standard tooltypes

Disabling the GUI or presetting the menu options from tooltypes would be up to the individual slave programmer to implement. It wouldn't be possible (with current WHDLoad ;)) to save changes made in the GUI back to the tooltypes though.

[Hungry Horace]

It wouldn't be possible (with current WHDLoad ;)) to save changes made in the GUI back to the tooltypes though.


that's ok... i wouldnt be bothered about doing that, since i doubt i would be using the GUI that often anyway when emulating....

(i notice your JSW2 gui still lets you define everything by tooltypes.. athough i havent tried it yet - this is the way i like it!)


edit: anyone actually tried StingRay's updated DogFight slave yet?

[Wepl]

My plans for implementing this are:

Extend Slave header to allow the Slave to describe Custom options (type, value range, description) like the example from Codetapper

New option for WHDLoad refering to a text file which contains the same information, to make it possible to add the trainer gui without updating the Slave

I like to add the trainer gui into the splash window.
There should be a save button to write the config into tooltypes back (if started from wb).

New option TrainerDelay which specifies how long the trainer gui will be displayed. 0 means no display, -1 means unlimited display.

The splash window will then be shown for:
SplashDelay if there is no trainer
SplashDelay+TrainerDelay if there is trainer
if SplashDelay=0 it is only opens if there is a trainer

If someone likes to write a own Trainer gui he can still does this by a program running before WHDLoad and reading the Slave header/seperate text file and then call WHDLoad as possible today.

Does this cover all needs?

[keropi]

I don't mind popup menus, and Wepl's idea sound EXCELLENT!
...but I am a simple user :spin

[girv]

Extend Slave header to allow the Slave to describe Custom options
...
New option for WHDLoad refering to a text file which contains the same information

I guess if the text file is used it will take precedence over the slave header?

Will it be possible to describe how to map existing tooltypes to the new trainer options? eg: bit 0 of CUSTOM1 is the on/off flag for the infinite lives trainer, bits 0-7 of CUSTOM2 are the start level etc.

Does this cover all needs?

Works for me. IMHO it's much better if this is integrated into WHDLoad itself. Plus it saves me a load of work finishing my own one! As a rule, I like things that save me loads of work :bowdown

Now the $1E06 question: when will it be done? :)

Also, since you're extending the slave header anyway... :evilgrin;) (kidding!)

[girv]

To answer Codetapper's original question in this thread, I don't actually know what has happened to the mega trainer :sad :crying

I went to gather the source together so I could fire it into The Zone for the interested, but I could only find an ancient early experiment version and that didn't even work properly. I'm guessing the later version was only a WinUAE hardfile that went byebye a while (years) ago, though it's not like me to only have one copy on the go :confused

The last version let you build a custom screen of your chosen size and configuration, render text in any bytewide or system bitmap font in any colour with bold/italic/shadow/outline/background effects, render IFF images of any depth to the screen (from fastmem!), set colours at any line using the copper and animate them with a vblank callback hook and probably some other tricks, all using a taglist style structure defined with easy to use macros.

Honest it did! ;) :D

All that was missing was the control system to move around the gadgets and cycle through the values, and IIRC I'd made a start at that.

But it seems it's lost now, so it's a good job that Wepl has his own plans :)

[Codetapper]

So Girv, it could basically do every bell and whistle imaginable, except for actually setting a YES/NO field, and ranges for numbers etc? ;)

I would guess you are the only one that has ever used bitfields for those trainer screens. All my installs use one option per CUSTOM tooltype, and most include trainer toggle keys in the game anyway. Bored Seals are the same, ditto Keith, Czeslaw and Harry's.

It's probably not that much work to redo your 31 installs anyway is it? ;)

[girv]

So Girv, it could basically do every bell and whistle imaginable, except for actually setting a YES/NO field, and ranges for numbers etc? ;)

lol :D Well you're a programmer too so you know how it goes - you take 80% of the project time doing the fun 20% of the work, then cram in the remaining boring 80% of the functions that are actually necessary in the remaining 20% of the time ;) It's a sign of creative genius, I think ;)

A word in my defence though: you could actually define lists of gadgets, set values and cycle through them, you just couldn't navigate around the gadgets (yet). It got complicated at that stage and I had to rethink a few bits as you'd requested support for scrolling lists of gadgets to fit unlimited options into the menu ;)

I would guess you are the only one that has ever used bitfields for those trainer screens.

Seriously? I'm surprised. Seems like the obvious way to do it to me! Oh well, wierd and wrong again :rolleyes

It's probably not that much work to redo your 31 installs anyway is it? ;)

Not really, no. Most of them need redone anyway, that's where the work would be, but I have other plans that will require that in any case so it's not a big deal. Adding support for Wepl's new option screens will be easy in comparison. But you, Mr. 200+, only have yourself to blame ;)

@Wepl: will there be a limit to the number of options that can be displayed? How will you handle slaves with many many options?

[Wepl]

I guess if the text file is used it will take precedence over the slave header?
yes
Will it be possible to describe how to map existing tooltypes to the new trainer options? eg: bit 0 of CUSTOM1 is the on/off flag for the infinite lives trainer, bits 0-7 of CUSTOM2 are the start level etc.
I think not, only you have used that and so far nobody has complained that the 5 customs are too less
Now the $1E06 question: when will it be done? :)
We will see :nervous
Also, since you're extending the slave header anyway... :evilgrin;) (kidding!)
try to find real arguments for, none seen yet ;)

[Wepl]

@Wepl: will there be a limit to the number of options that can be displayed? How will you handle slaves with many many options?

the limit is currently Custom1-5 so 5 options, not more