@Tsukihime - I wouldn't liken it to either, since it doesn't actually properly reset the game. A normal reset will simply handle the error outside the accessible areas of the scripts, but still apparently within Ruby. Part of the handling process is to call Graphics.__reset__ which disposes all graphics (bitmaps, sprites, etc). If rgss_main has been called, the program will continue here. If not, the program will resume from the top of the script editor. Aside from disposing the graphics, everything else about the program state remains as it was prior to this "reset", which leads to a ton of garbage variables that are no longer valid since the game was supposed to have been reset. Even the bitmap and sprite objects all remain in their respective variables, even though they have been disposed and are now useless.
@TheoAllen - This implementation of F12 is terrible because it is at the program level with no way to work around it or disable it. A true hard reset would be trivial to implement and could easily be tied in to, say, Input.update so at least there would be a fixed point to work around if you decided you didn't want it like that. The ability to one button reset isn't the point of contention, its that it remains active in completed projects and has been thus far impossible to work around. That and the default implementation doesn't clear memory, so it is questionable even as a dev tool. The fact that it conflicts with Steam's default screenshot key is just another reason to hate it.
@Zeriab - Unfortunately, I have yet to find a good way around this issue. F1 and F2 presses appear to require the window to respond to specific messages from the keypresses. Neither will happen unless the windows is in focus, but they will happen independent of where you are in the code (F2 will not display FPS if Graphics.update is not being actively called, but the keypress is registered and it will display FPS when there is sufficient data to do so). If you press F1 or F2 when the window is not in focus their respective functions do not activate. F12, however, is a completely different animal. Even when running the RGSS Player on a loop doing nothing but retrieving the windows messages, it will not stop F12 from activating. F1 and F2 both will not register in this loop. I have no idea what exactly causes the program to respond to the messages for the keypresses on F1 and F2, specifically, I can only say that adding a sleep(0.015) to the loop will allow both to occasionally "slip through", so I know they are not based from any specific line of Ruby code. Filtering messages at the Ruby level wouldn't be viable anyway since we are thread locked and Graphics.update halts Ruby while allowing the window to still process messages, this is just the information that I have been able to glean.
If F12 is pressed with ANYTHING in focus, and the Ruby environment is not locked from progressing (eg., being at Graphics.update or Graphics.transition), the error is thrown instantly and the reset will occur as soon as the window is put back in focus. This suggests to me that F12 is implemented differently than F1 and F2. My initial line of thought was that maybe if the could be linked to a specific message being received by the window, the windowproc function could then be replaced. Sadly, all ways to actually create a callback function have been removed for RGSS and extensions are disabled, so I never pursued it beyond this, but I'm not sure it would have worked anyway since I'm still not clear on how exactly it is implemented.
Example: (you'll need to turn on Console and use the exit button on the console to cause the game to exit, because this also filters the WM_QUIT message)
Spoiler
count = 0GetMessage = Win32API.new('user32', 'GetMessage', 'plll', 'i') p "before loop"loop do count += 1 buf = "\0" * 32 GetMessage.call(buf, HWND, 0, 0) p countend
Pressing F1 and F2 within the loop causes the message to be swallowed and the window to not respond (I misplaced the code that checked which messages were being retrieved but I know that keypresses for F1 and F2 were definitely being retrieved, but I do not recall seeing the keypress message for F12). Pressing F12 at any point will cause RGSSReset to be thrown that instant, the actual reset process occurring when the window next receives focus.
@dekita - Your new method to ensure everything is updated really falls into the same pitfalls as before, namely, you don't know where the RGSSReset was thrown, so you could be double-updating some things. It may not be immediately apparent, but it can cause problems down the line. You are also leaving a bigger gap for an actual reset to be triggered - when you rescue into updating everything for the frame this method itself does not rescue RGSSReset. Again, very small window, but F12 retriggers very often so even a lingering keypress can cause a stray reset. start, post_start, pre_terminate, and post_terminate are still completely uncovered, leaving transitions vulnerable to being reset. This method will unfortunately never be foolproof because the damage has already been done when the error is thrown; without literally tracing every single line of code the best you can do is try and make sure the essential functions have taken place. Just rescuing the scene's update method as you did in the original version could potentially have a lower percentage error rate than actually trying to cover the smaller holes. Either way, you are still be risking a crash, reset, or game breaking bug every time you try to take a screenshot using Steam.