06-13-2019, 09:54 PM
(This post was last modified: 07-16-2023, 02:01 AM by DerVVulfman.)
A response to above showing his 2019 post date
In your description of CRuby, you fail to recognize that Ruby and RGSS also have initialize and dispose methods as defaults. While you may visit the Scene_Battle code of the default scripts and do not see any initialize method, it is present and is set to the system defaults. Likewise, so too is the dispose method in Scene_Battle. This holds true to other classes within Ruby. I have used 'alias' methods to classes where an initialize method does not appear visible, yet they are there none-the-less.
However, you're not accepting that we are dealing with an interpreter version where the custom scripts (ie the Scripts Library) is being loaded from an encrypted file after the Game.Exe file loads. Thus, we are not having the actual code embedded in a C+ engine. Even so, a faulty scripter could still cause a stack overflow if their code was wrong.
In regards of the main method, I clearly stated "Hiding the main method is not wise at all" and not that hiding the method couldn't be done. You as well as I and anyone with programming language in C programming (among others) know that the main method is the starting / jumpoff point of a program.
In both of these cases, I feel your statements are argumentative and meant solely to hide the fact that a coder could use a simple technique to prevent stack overflows.
Post 4 by Kyonides
In your description of CRuby, you fail to recognize that Ruby and RGSS also have initialize and dispose methods as defaults. While you may visit the Scene_Battle code of the default scripts and do not see any initialize method, it is present and is set to the system defaults. Likewise, so too is the dispose method in Scene_Battle. This holds true to other classes within Ruby. I have used 'alias' methods to classes where an initialize method does not appear visible, yet they are there none-the-less.
However, you're not accepting that we are dealing with an interpreter version where the custom scripts (ie the Scripts Library) is being loaded from an encrypted file after the Game.Exe file loads. Thus, we are not having the actual code embedded in a C+ engine. Even so, a faulty scripter could still cause a stack overflow if their code was wrong.
In regards of the main method, I clearly stated "Hiding the main method is not wise at all" and not that hiding the method couldn't be done. You as well as I and anyone with programming language in C programming (among others) know that the main method is the starting / jumpoff point of a program.
In both of these cases, I feel your statements are argumentative and meant solely to hide the fact that a coder could use a simple technique to prevent stack overflows.