06-13-2019, 06:50 AM
(This post was last modified: 07-16-2023, 02:06 AM by DerVVulfman.)
Hello friends, I wish to talk about the key that many in the RPGMaker community believe is a bugged and broken feature. Nearly everyone has at one time talked about the dreaded F12 bug at some point in the course of their game development history. But few ever stopped to consider, what is the actual issue with the F12 key itself.
The F12 key is not broken, nor is it bugged or contains an error. The F12 key is merely the 'game reset' key built into your Game.Exe file. If the player wishes to reset the game quickly, and doesn't wish to use the exit option in their game menu, they can hit the F12 key. It's merely that simple a feature.
The problem that people have designated as the F12 Bug is really an issue with the way a script was written. To be more specific, it has to do with something that the author had overlooked when he or she utilized the 'alias' command to add some new piece of code.
Now to be fair, many scripters were never given a course on writing scripts for RPGMaker. So the cause of the so-called bug was never widely revealed, nor any manner to prevent its occurrence.
What has been widely and incorrectly referred to as the F12 bug is actually a Stack error, the typical error message displaying 'stack error too deep'. So you may ask yourself the question "What is a stack error?"
This particular error is properly called a 'stack overflow' where a program is trying to use more memory than what's been set aside. You could have made an infinite 'loop...end' block to add new monsters to your game and forgot to add a feature to exit the loop. But when a stack error crops up because the player hits the F12 key, it is because of something slightly different.
When you start your game, all the scripts get loaded into memory whether they're the ones from your project's Script Database or if they are special hidden class scripts. And hitting the F12 key forces the game engine to reload the scripts each and every time.
However, many scripters use the 'alias' command to attach new code to an already existing method. This practice is fine enough and looked favorably. It is considered to be preferable to use this tactic to add new code instead of rewriting the original code. But there are times where the use of an alias command creates something that coders call an 'infinite loop'.
An infinite loop in a game can cause the game to stall indefinitely and should be avoided at all costs. But an infinite loop caused by the use of the alias command is more insidious. Whether you run a fresh game or hit the F12 key, your game should load the original script, and then the custom script with the alias command to attach the new code. But some custom scripts, when the F12 key is pressed, forces the reloading of an already altered script with the alias command already embedded and this coerces the game engine to continue attaching code into this same script over and over, ad infinitum. So as the script continues to load, it takes up more and more memory until the memory allocated is used up and the game crashes as a result of a stack overflow.
Now, this is not to say that the person writing the script did anything bad. The scripter merely needed to make sure that the script only runs the 'attachment' to the original script once. It's actually easy to do once you know what script is causing the crash. You just need to encapsulate the line of code in the script that creates the relationship between the new/aliased code and the original as seen below:
Let's assume that someone is attaching some new code to the Input module itself, and this code adds full keyboard control. Fine enough, and would work normally until the F12 key is struck. But funny things happen with the hidden classes, and you would very likely get a stack overflow reloading. But by adding a test for the existence of an instance variable that exists nowhere else in the project (the @f12_stack_fix_input_update value), we force the update method to be altered with this custom code only once.
But as you can see, it is not the fault of the F12 key and not the fault of the RPGMaker engines itself. Those making the new scripts were never informed about the prevention of stack overflow in their code. And the community of scripters merely pointed their finger at the F12 key as the simplest of explanations.
The F12 key is not broken, nor is it bugged or contains an error. The F12 key is merely the 'game reset' key built into your Game.Exe file. If the player wishes to reset the game quickly, and doesn't wish to use the exit option in their game menu, they can hit the F12 key. It's merely that simple a feature.
The problem that people have designated as the F12 Bug is really an issue with the way a script was written. To be more specific, it has to do with something that the author had overlooked when he or she utilized the 'alias' command to add some new piece of code.
Now to be fair, many scripters were never given a course on writing scripts for RPGMaker. So the cause of the so-called bug was never widely revealed, nor any manner to prevent its occurrence.
What has been widely and incorrectly referred to as the F12 bug is actually a Stack error, the typical error message displaying 'stack error too deep'. So you may ask yourself the question "What is a stack error?"
This particular error is properly called a 'stack overflow' where a program is trying to use more memory than what's been set aside. You could have made an infinite 'loop...end' block to add new monsters to your game and forgot to add a feature to exit the loop. But when a stack error crops up because the player hits the F12 key, it is because of something slightly different.
When you start your game, all the scripts get loaded into memory whether they're the ones from your project's Script Database or if they are special hidden class scripts. And hitting the F12 key forces the game engine to reload the scripts each and every time.
However, many scripters use the 'alias' command to attach new code to an already existing method. This practice is fine enough and looked favorably. It is considered to be preferable to use this tactic to add new code instead of rewriting the original code. But there are times where the use of an alias command creates something that coders call an 'infinite loop'.
An infinite loop in a game can cause the game to stall indefinitely and should be avoided at all costs. But an infinite loop caused by the use of the alias command is more insidious. Whether you run a fresh game or hit the F12 key, your game should load the original script, and then the custom script with the alias command to attach the new code. But some custom scripts, when the F12 key is pressed, forces the reloading of an already altered script with the alias command already embedded and this coerces the game engine to continue attaching code into this same script over and over, ad infinitum. So as the script continues to load, it takes up more and more memory until the memory allocated is used up and the game crashes as a result of a stack overflow.
Now, this is not to say that the person writing the script did anything bad. The scripter merely needed to make sure that the script only runs the 'attachment' to the original script once. It's actually easy to do once you know what script is causing the crash. You just need to encapsulate the line of code in the script that creates the relationship between the new/aliased code and the original as seen below:
Code:
if @f12_stack_fix_input_update.nil?
alias fullkeyboard_update update
@f12_stack_fix_input_update = true
end
Let's assume that someone is attaching some new code to the Input module itself, and this code adds full keyboard control. Fine enough, and would work normally until the F12 key is struck. But funny things happen with the hidden classes, and you would very likely get a stack overflow reloading. But by adding a test for the existence of an instance variable that exists nowhere else in the project (the @f12_stack_fix_input_update value), we force the update method to be altered with this custom code only once.
But as you can see, it is not the fault of the F12 key and not the fault of the RPGMaker engines itself. Those making the new scripts were never informed about the prevention of stack overflow in their code. And the community of scripters merely pointed their finger at the F12 key as the simplest of explanations.