Unfortunately, rescuing RGSSReset mid Scene update is not the same as disabling it. The error does not actually have a specific point it is actually thrown at (ie., nothing in the accessible Ruby environment is testing for the keypress, the program itself is sending the reset), therefore, even if every script uses update method correctly, this is not a valid solution. The error can be thrown at literally any point during that frame update, including in the middle of crucial calculations or variable assignments, which can cause further problems down the line, or an instant crashing error on the next frame due to a missing variable or something. Anything that uses a local loop and doesn't yield back to the scene's normal update method is also going to instantly run into problems here, as well as any operation not branching from the Scene's update method (for example, transitions, which take place during start). Rescuing here is also not foolproof, for example, the error could be thrown at a point past where some sprites were initially created, but before the screen was faded in. You would then be left with missing sprites which would crash when referenced. Alternatively, if you used retry to run the method again to get everything, you'd have existing sprites being recreated and stored in the same variable, orphaning the original created sprites, which is a potential for a Game.exe crash.
Granted, it is not likely that you will commonly run into any of the above problems just by randomly pressing the F12 key a couple times during normal operation, as the point where the error is sent is more than likely going to land within a Graphics.update or in one of the sprites update methods, which might cause a visual blip and nothing else, since this is where the bulk of the time on a frame is spent. So if you are accidentally hitting your F12 a lot during playtest for some reason, I guess this might save you some time. However, this would not be an acceptable solution to say, for example, wanting to rebind the F12 key to another function in a commercial project for a release on a platform where, say, F12 is the default screenshot key.
It is nice to see more people against the F12 reset, though. It would be nice to have an actual way to disable it.
@Mithran - yea, its not foolproof. Certainly something though.
Your completely right that it wouldn't be any help for rebinding the key etc. After further tests I found that if you hold the key down for some time it will eventually reset.
And yea, all the F keys bindings really annoy me. I've wanted to write up a scene where the user selects their keys - like, user defines which keys trigger what. Cant do that with the F1 binding. The F2 binding is pointless now that I have an fps script and the F12 is just a huge pain in my ass - especially for incorrectly terminating connections with my server :/
@Zeriab - Yeap, I plan to. I am certain it can be done somehow, either via the given ruby interface or via external dlls's catching the keypress and somehow rerouting it.. Out of curiosity as I have never seen not heard of it, what is the F12 fix for xp ?
Uhh, also, I done a small update to kind of allow the scene to continue updating whilst the F12 is pressed. Still not foolproof, like when your scene is changing and you F12 it will crash and ****.. But looks nicer for scene flow when it continues to update.
Instead of put them in update, I guess, it would be better if you put them into update_basic instead
In Scene_Battle, wait method usually call update_basic instead of update. So, F12 can be pressed there
By the way, F12 is not completely useless.
It's very useful if you're going to test things. Like Battle test. You're not required to click battle test once and once again after you beat the enemies. Just press F12 and it will be reseted back. Well, F12 is merely a devtool that should not functional in Game.exe. I hope the next RPG Maker will fix this thing.
Edit :
P.S I like the way you named things in your script
@TheoAllen - I am actually thinking of having it directly in the Graphics#update as that is the one update method that is guaranteed to be called during each frame for all scenes. Still looking into the best way to house the method.
@Zeriab - I will have to have a rad up on your rant then
@Mur - Thats strange, I also use steam ace. Do you have any other scripts that could be conflicting?
@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)
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.
So yea, apparently the steam version updated and changed out my dll - which is stopping the script from working all together (only on the map though). Looking into that :/
@Mithran - Yes, you are completely right in saying that F12 is triggered differently. Not that one would want to of course, but you can change those key triggers (by altering the 'accelerators' portion of the dll in something like resource hacker. not sure if this is eula breach or not as using resource hacker is ok for changing the game exe.
Anyway... yea, the accelerators only lists keys for F1, F2 and At+Enter, nothing mentioned about any F12 key or Reset Key or anything.
SideNote:
FenixFyre reckons its possible using umm 'SetWindowsHookEx()'. I have no idea what the parameters it wants are / how to get them, looking into it though
@Dekita - SetWindowHooksEx requires a Windows callback function, which cannot be defined in RGSS3 to my knowledge and the function to load Ruby source files has also been removed. If you find a way to do so, though, I'd love to know about it. Using DL to load function from a C library might work if one were created. But if the reset does happen to be triggered from a Message, which Message? This would be the odd based on my previous experiment, if you run the loop provided in my above post you can't even use the x to close the game, move the window with the mouse, etc, because messages are being removed from the queue fast enough that even mouse clicks and quit messages are being removed before the window sees them. But F12 always instantly resets.
And yes, I am looking for solutions that don't fall within the EULA only, so no external exe or dll hacking (but the use of another DLL, or changing memory values from within the Ruby environment while the RGSS3 player is running would be fine).
Good luck, though. A real solution to this problem would help a lot of people.
Some years ago I've written such a script/DLL, which also en-/disabled F1 or Alt+Enter (probably by using the already mentioned SetWindowsHooksEx). But it's likely gone.
RGSS3 calls GetKeyState with VK_F12. If you “alias”, or to use the correct term, hook it, you can simply return 0 and RGSSReset will never be raised by the DLL. Do the same for GetAsyncKeyState and I think, as I'm not sure, it'll also prevent that exception in other major versions. You probably don't even have to write a DLL to do that. And don't quote me on that, but I'm sure it's legal and not against the EULA.
@Dekita - SetWindowHooksEx requires a Windows callback function, which cannot be defined in RGSS3 to my knowledge and the function to load Ruby source files has also been removed.
You can load Ruby source files in all RGSS versions. But you can't load native extensions (*.so or *.dll). I've never done it myself, but in RGSS3 with dl it might be possible to define callback functions. But you have to import and maybe modify the Ruby part as only the extension(s) are included in RGSS3. Also, even though dl is mightier than Win32API, it's also ugly and not good documented. Plus writing these things in Ruby is quite tedious.
Is this possible: Press F12, instead of reset the game or nothing happened, it will show a choice?
Or should i say: Trigger a common event when press F12?
Cartoonier cloud cover that better fits the art style, as well as (slightly) improved blending/fading... fading clouds when there are larger patterns is still somewhat abrupt for some reason.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
