Trainer GUI

Codetapper · 23 July 2007, 23:15

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 · 24 July 2007, 01:13

Quote:

Originally Posted by Codetapper

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 · 24 July 2007, 01:14

Quote:

Originally Posted by Codetapper

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 · 24 July 2007, 01:29

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 · 24 July 2007, 04:25

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:

Code:

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)",0

And 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 · 24 July 2007, 05:33

Quote:

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 · 24 July 2007, 10:11

@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

Galahad/FLT · 24 July 2007, 10:20

Can't we all just hug and get along?

girv · 24 July 2007, 10:46

Well alright come on then GHD, have a hug

Codetapper · 24 July 2007, 10:57

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 · 24 July 2007, 11:00

Quote:

Originally Posted by girv

Well alright come on then GHD, have a hug

No tongues!!!!!!

girv · 24 July 2007, 11:51

Quote:

Originally Posted by Codetapper

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 · 24 July 2007, 11:54

Quote:

Originally Posted by Galahad/FLT

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 · 24 July 2007, 12:24

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

girv · 24 July 2007, 12:31

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

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

Codetapper · 24 July 2007, 13:51

Quote:

Originally Posted by girv

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 · 24 July 2007, 14:56

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 · 24 July 2007, 18:19

Quote:

Originally Posted by Hungry Horace

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 · 24 July 2007, 18:56

Quote:

Originally Posted by girv

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 · 24 July 2007, 21:13

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?

23 July 2007, 23:15	#1
Codetapper 2 contact me: email only! Join Date: May 2001 Location: Auckland / New Zealand Posts: 3,182	Trainer GUI 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!

24 July 2007, 04:25	#5
Codetapper 2 contact me: email only! Join Date: May 2001 Location: Auckland / New Zealand Posts: 3,182	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: Code: 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)",0 And 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.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
GUI and minimizing	mark_k	support.WinUAE	3	14 March 2012 17:33
Kumiko GUI - Amiga Workbench 3.1 GUI for Windows	milika	Amiga scene	31	18 April 2007 19:16
OS 3.9 GUI Improvements	redneon	Amiga scene	11	17 February 2005 08:56
Screenshots in GUI?	snarfo	request.UAE Wishlist	4	30 December 2004 19:49

24 July 2007, 01:29	#4
Hungry Horace Wipe-Out Enthusiast Join Date: Nov 2005 Location: . Age: 43 Posts: 2,538	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

24 July 2007, 10:11	#7
girv Mostly Harmless Join Date: Aug 2004 Location: Northern Ireland Posts: 1,109	@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

24 July 2007, 10:20	#8
Galahad/FLT Going nowhere Join Date: Oct 2001 Location: United Kingdom Age: 50 Posts: 8,986	Can't we all just hug and get along?

24 July 2007, 10:46	#9
girv Mostly Harmless Join Date: Aug 2004 Location: Northern Ireland Posts: 1,109	Well alright come on then GHD, have a hug

24 July 2007, 10:57	#10
Codetapper 2 contact me: email only! Join Date: May 2001 Location: Auckland / New Zealand Posts: 3,182	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

24 July 2007, 12:24	#14
musashi5150 move.w #$4489,$dff07e Join Date: Sep 2005 Location: Norfolk, UK Age: 42 Posts: 2,351	Possibly followed by the clearing of the throat and a conversation about football in a deep voice

24 July 2007, 12:31	#15
girv Mostly Harmless Join Date: Aug 2004 Location: Northern Ireland Posts: 1,109	Power tools, beer, sports cars or "Hot Or Not" would also be acceptable Maybe a mod would like to split or move this thread? We've wandered off the title topic...

24 July 2007, 14:56	#17
Hungry Horace Wipe-Out Enthusiast Join Date: Nov 2005 Location: . Age: 43 Posts: 2,538	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....

24 July 2007, 21:13	#20
Wepl Moderator Join Date: Nov 2001 Location: Germany Posts: 866	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?

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)