SUGGESTION: eEventQuitGame enumerated value

monkey0506 · Mon 19/12/2005 18:11:25

I couldn't find anything similar to this in a brief forum search or in the tracker, so I figured I would suggest it. Recently there have been some reports of warnings being generated due to DynamicSprites not being deleted before the game is ended.

If a module creates DynamicSprites, but the user fails to delete them before they quit the game, these warnings will be generated. So, to prevent this, I'm proposing that a new value be added to EventType, eEventQuitGame. That way module creators could call DynamicSprite.Delete() for all of their DynamicSprites before the game exited, which would stop these warnings from being generated.

Rui 'Trovatore' Pires · Tue 20/12/2005 01:41:21

But since you can already control QuitGame, why would you need this event? You can place all your code in the same function that quits the game, just before the QuitGame command.

Gilbert · Tue 20/12/2005 01:46:28

Read his post, Redrum.

Quote from: monkey_05_06 on Mon 19/12/2005 18:11:25
If a module creates DynamicSprites, but the user fails to delete them before they quit the game, these warnings will be generated.

The problem is, the user quit his game, without doing the required procedure for the module before that. Currently there's no way for the module to take care of it.

Rui 'Trovatore' Pires · Tue 20/12/2005 02:32:33

There could be, if the module itself had the "quit game" command inside a function the user would call instead of QuitGame. Granted, it's all a bit of a hack, but it's not even a big hack. I'm not saying the suggestion isn't useful, just that it's workaroundable at the mo.

Gilbert · Tue 20/12/2005 02:47:22

Provided the user will really read the documentation provided with the module and knows that he should not use QuitGame() for it.
It may not even work that good if there're 2 different modules used, each has it's own "quit game" function to be called.

fovmester · Tue 20/12/2005 06:22:25

Or you could supply a QuitGame() function with the module that will be run when the normal QuitGame() command is run, much like repeatedly_execute is. Then the module creator could delete all dynamic sprites and stuff in there and it will be run independently on how well the user reads the documentation.

Pumaman · Tue 20/12/2005 08:11:19

It's a reasonable request, certainly. I'll look into it.

Gilbert · Tue 20/12/2005 08:19:12

Trackered.

Rui 'Trovatore' Pires · Tue 20/12/2005 09:59:09

QuoteProvided the user will really read the documentation provided with the module and knows that he should not use QuitGame() for it.

Yeah well, I think everyone who doesn't bother to read documentation deserves the problems they get.

Gilbert · Tue 20/12/2005 10:12:43

And we deserve getting numerous posts of stuff not working in this forum? Though people should read documentations, it won't hurt if your modules/templates/whatever can handle stuff in a much more friendly way.

monkey0506 · Tue 20/12/2005 18:00:08

Quote from: SSHPosted by SSH on 20-Dec-05 at 03:45 (IP logged):
This would be good for handling when the user clicks the windows close button when windowed. There may need to be restrictions, like no blocking functions and no calls to QuitGame!

True, calling blocking functions or QuitGame might mess things up, but I'm sure that could be prevented.

Rui, yes the user can handle it themselves, but the idea behind suggesting the eEventQuitGame event would be to prevent the exact situation that Gilbot has just described.

GBC recently posted in the SimpleSnow thread regarding several warnings that were generated when he exited his game without first calling the SimpleSnow.No() function.

If GBC had implemented several modules that created DynamicSprites and he forgot to call the module functions to remove them, he could end up with several hundred warnings.

The idea of this event would be so that module authors could ensure that their module didn't cause this sort of thing to happen.

Rui 'Trovatore' Pires · Tue 20/12/2005 18:19:04

QuoteIf GBC had implemented several modules that created DynamicSprites and he forgot to call the module functions to remove them, he could end up with several hundred warnings.

Right-o, I'm not against this suggestion, never was, I just suggested a workaround in case it was needed, but before I pipe down I have to say this - if GBC deleted a sprite that was used by a script he had forgotten, or if he deleted a GUI and identified his GUIs via their numbers, or disabled the "abort game" keycode and didn't include a QuitGame command anywhere, or... well, you see what I mean. Yes, biggest ease of use and flexibility possible, but in the end if the user doesn't read the documentation much good may it do...