Script and Event checker

[Zabaka]

My game's having a very bad FPS decrease, and i want to know what's the cause of this problem. Is there any script, like, a creator's tool to check out which scripts and events are running?

 

[Andar]

Only parallel process events can create a lot of lag if badly programmed - if the lag is due to too many decorative events, you'll have to remove one or two hndred decorations from your map.


So please check your parallel process events, especially the common events on parallel - remember that parallels get executed sixty times per second unless you place a wait inside them.

 

[Zabaka]

But the problem is, the lag occur even when there's absolutely no parallel process event or parallel process common event...

 

[Bex]

Dont know about such Programm. Sorry.

But you could also Provide more Information.

 

[Andar]

But the problem is, the lag occur even when there's absolutely no parallel process event or parallel process common event...

Then please provide more information, like how big are the maps where the the lag happens, how many events you have and what scripts you added to the engine.
But best guess is that you made a parallel process and simply forgot it - because there is (as far as I know) only one script that causes a lot of lag, and that's Khas Light Script.


Everything else will either require an extremely big map (above 200x200) or a parallel process.


Especially I suggest checking the common events again and see if you accidentally switched one to parallel process.

 

[Zabaka]

Checked all the common event. All of them is not parallel, only work via common event calls. The map is just a 20x17 normal map with normal tiles from RTP. Almost all of events on map is triggered by action button and some by player touch. There are 2 parallel process events to make weather change, but the switch is turned off. I use a lot of script, so i really don't know which of them cause the FPS decreasement. That's why i want a tool or script to check out.

 

[Hudell]

Is your computer on battery-saving mode? That usually cut's the CPU performance and makes the game run much slower than it usually would.

 

[Zabaka]

I can't say you're wrong... My laptop is running with battery-saving mode. But even the bigger map than that FPS only decrease to 25~20 (a pain, but still acceptable). But this map is even lower than 10 FPS! Don't know why...

Edit: tested with balanced mode. every other map got 60 FPS. This map's FPS run unstappable. From 33 FPS, down to 6 FPS after some walk, back to 33 FPS and repeat above. Stand still don't change this loop.

 

[Hudell]

That's very weird.

Try adding this small script and running the game with the console visible, it will display on the console what events are running:

class Game_Event    alias :hudell_start :start    def start        begin            print "running event " + @id.to_s + " from map " + @map_id.to_s + "\n"        rescue        end        hudell_start    endendclass Game_CommonEvent    alias :hudell_update :update    def update        begin            print "updating COMMON event " + @event.id.to_s + "\n"        rescue        end        hudell_start    endend

 

[Andar]

Edit: tested with balanced mode. every other map got 60 FPS. This map's FPS run unstappable. From 33 FPS, down to 6 FPS after some walk, back to 33 FPS and repeat above. Stand still don't change this loop.

If only this map has the lag, then it's most probably a parallel process in an event on that map.
Scripts are map-independent, which means that unless something on the map triggers specific script functions no script can cause lag only there.


However:

There are 2 parallel process events to make weather change, but the switch is turned off.

Have you confirmed that the switches are off?
Some scripts are triggered or configured by switches. If you forgot to reserve those switches and used them for something else (like those weather events), then either the script can trigger such events or an script can triggered by changing other switches or variables.


So please check all script configurations: have you reserved all the switches and variables set in those configurations?


If you don't know what I'm talking about: http://forums.rpgmakerweb.com/index.php?/topic/40589-how-to-use-a-script/

 

[♥SOURCE♥]

What is your CPU's clock speed? RGSS, in all its versions, runs on a single core alone. No GPU usage. The clock speed is very important.

So please check your parallel process events, especially the common events on parallel - remember that parallels get executed sixty times per second unless you place a wait inside them.

Important note regarding that: under default circumstances, parallel process events get executed 30 times per seconds due to a bug in the default scripts. More information and a fix can be found here.

 

[Zabaka]

That's very weird.

Try adding this small script and running the game with the console visible, it will display on the console what events are running:

class Game_Event    alias :hudell_start :start    def start        begin            print "running event " + @id.to_s + " from map " + @map_id.to_s + "\n"        rescue        end        hudell_start    endendclass Game_CommonEvent    alias :hudell_update :update    def update        begin            print "updating COMMON event " + @event.id.to_s + "\n"        rescue        end        hudell_start    endend

That snippet give me a bug like the image below.

If only this map has the lag, then it's most probably a parallel process in an event on that map.

Scripts are map-independent, which means that unless something on the map triggers specific script functions no script can cause lag only there.

However:

Have you confirmed that the switches are off?

Some scripts are triggered or configured by switches. If you forgot to reserve those switches and used them for something else (like those weather events), then either the script can trigger such events or an script can triggered by changing other switches or variables.

So please check all script configurations: have you reserved all the switches and variables set in those configurations?

If you don't know what I'm talking about: http://forums.rpgmakerweb.com/index.php?/topic/40589-how-to-use-a-script/

I'm pretty sure about that. 'Cause i've never turned them on ever to begin with.

What is your CPU's clock speed? RGSS, in all its versions, runs on a single core alone. No GPU usage. The clock speed is very important.

Important note regarding that: under default circumstances, parallel process events get executed 30 times per seconds due to a bug in the default scripts. More information and a fix can be found here.

I'm not sure about clock speed...

 

[Andar]

I'm pretty sure about that. 'Cause i've never turned them on ever to begin with.

That is exactly why I refered you to check the scripts. Because there are scripts that automatically turn on switches if those switches are configured to be used in the script.

For example Yanfly's message system automatically binds variables to the size of text messages. This is intended to allow the developer to increase or decrease the text box from its default size of four.

And whenever someone forgot to configure and reserve those variables correctly and started to use them...

This board is full of complains where either a calculation didn't work (because yanfly's message system loaded 4 as the default value into that variable) or that the text messages were suddenly zero lines high (because the developer used the variable and set it to zero without realising that this will change the message behaviour.

You cannot be sure that the values and switches are the defaults you know if you have added scripts to your project, unless you have checked every script for the switches and variables it uses. That is why you have to check their values on the map when it happens to see if something else changed them without your knowledge.

 

[Hudell]

That snippet give me a bug like the image below.

Ooops.

Fixed it:

class Game_Event    alias :hudell_start :start    def start        begin            print "running event " + @id.to_s + " from map " + @map_id.to_s + "\n"        rescue        end        hudell_start    endendclass Game_CommonEvent    alias :hudell_update :update    def update        begin            print "updating COMMON event " + @event.id.to_s + "\n"        rescue        end        hudell_update    endend

 

[Solistra]

Ironically, by using begin/rescue blocks in the event start code (and concatenating strings rather than interpolating them), you're significantly decreasing the startup speed of events when using your code to debug which events are starting. Most notably, begin/rescue blocks can slow down the Ruby interpreter by more than five times just by using them, regardless of whether or not the rescue is ever actually triggered. Honestly, in this case, I also don't see any reason why you would need to catch standard errors -- there really shouldn't be any unless some third-party script messed around with things more than it should have, in which case the error is actually useful and you want it to bubble up.

Also, I/O operations (such as puts, print, p, and friends) are generally slow operations as well -- basically, you're asking for more lag by writing to standard output on every common event update (which also reports common events which are not, in fact, active or doing anything in your code). It's also worth noting that your code above won't accurately report when a parallel process event is started as soon as the map is entered (the default scripts take those events and load their respective event lists into a specialized interpreter, not running them as a normal event -- weird spaghetti logic? Weird spaghetti logic). Autorun events will also start overflowing the console if they regularly repeat, as will those common event updates, meaning the tester might not even see which events are continually running.

Taking all of these considerations into account, I came up with this:

class Game_Event < Game_Character  alias_method :sol_debug_original_start, :start  def start    unless @trigger == 3      page = @event.pages.index(@page) + 1      puts "Running event #{@id} (page #{page}, map #{@map_id})."    end    sol_debug_original_start  end    alias_method :sol_debug_original_setup_page_settings, :setup_page_settings  def setup_page_settings    sol_debug_original_setup_page_settings    if @trigger > 2      page = @event.pages.index(@page) + 1      case @trigger      when 3        puts "Started autorun event #{@id} (page #{page}, map #{@map_id})."      when 4        puts "Started parallel event #{@id} (page #{page}, map #{@map_id})."      end    end  endendclass Game_CommonEvent  alias_method :sol_debug_original_refresh, :refresh  def refresh    state = @interpreter    sol_debug_original_refresh    puts "Started parallel common event #{@event.id}." if state != @interpreter  endend

The above code isn't perfect by any means, but hopefully it'll help to isolate potential eventing problems which could result in that kind of lag. I'm sure there are other edge cases that I didn't take into account, as well, so if anyone sees something which could be done better or more thoroughly, feel free to offer alternatives.

 

[♥SOURCE♥]

I'm not sure about clock speed...

http://www.wikihow.com/Check-CPU-Speed

 

[Hudell]

Ironically, by using begin/rescue blocks in the event start code (and concatenating strings rather than interpolating them), you're significantly decreasing the startup speed of events when using your code to debug which events are starting. Most notably, begin/rescue blocks can slow down the Ruby interpreter by more than five times just by using them, regardless of whether or not the rescue is ever actually triggered. Honestly, in this case, I also don't see any reason why you would need to catch standard errors -- there really shouldn't be any unless some third-party script messed around with things more than it should have, in which case the error is actually useful and you want it to bubble up.

Also, I/O operations (such as puts, print, p, and friends) are generally slow operations as well -- basically, you're asking for more lag by writing to standard output on every common event update (which also reports common events which are not, in fact, active or doing anything in your code). It's also worth noting that your code above won't accurately report when a parallel process event is started as soon as the map is entered (the default scripts take those events and load their respective event lists into a specialized interpreter, not running them as a normal event -- weird spaghetti logic? Weird spaghetti logic). Autorun events will also start overflowing the console if they regularly repeat, as will those common event updates, meaning the tester might not even see which events are continually running.

I can't open rpg maker when I'm at the office, so I just looked at the Game_Event and Game_CommonEvent scripts (I have them saved as rb files) and wrote something simple that should do the trick. I used begin/rescue because I wasn't sure if everything would always be assigned. I didn't really care about the performance of that, as I expected him to delete this script once he finds what's causing the lag.

 

[Solistra]

Well, I tried to take performance into consideration given that the problem was... lag.


I understand not having Ace available to consult, though, I'm in that situation a lot myself. I just saw the opportunity to educate a little bit and offer a slightly more thorough solution.


Really, I doubt that what I wrote is entirely sufficient; I'm absolutely certain that there are things that I didn't take into account. If you or anyone else finds anything that just isn't quite good enough, please, correct it.

 

[Zabaka]

Ooops.

Fixed it:

class Game_Event    alias :hudell_start :start    def start        begin            print "running event " + @id.to_s + " from map " + @map_id.to_s + "\n"        rescue        end        hudell_start    endendclass Game_CommonEvent    alias :hudell_update :update    def update        begin            print "updating COMMON event " + @event.id.to_s + "\n"        rescue        end        hudell_update    endend

I can't see any console open up...

Ironically, by using begin/rescue blocks in the event start code (and concatenating strings rather than interpolating them), you're significantly decreasing the startup speed of events when using your code to debug which events are starting. Most notably, begin/rescue blocks can slow down the Ruby interpreter by more than five times just by using them, regardless of whether or not the rescue is ever actually triggered. Honestly, in this case, I also don't see any reason why you would need to catch standard errors -- there really shouldn't be any unless some third-party script messed around with things more than it should have, in which case the error is actually useful and you want it to bubble up.

Also, I/O operations (such as puts, print, p, and friends) are generally slow operations as well -- basically, you're asking for more lag by writing to standard output on every common event update (which also reports common events which are not, in fact, active or doing anything in your code). It's also worth noting that your code above won't accurately report when a parallel process event is started as soon as the map is entered (the default scripts take those events and load their respective event lists into a specialized interpreter, not running them as a normal event -- weird spaghetti logic? Weird spaghetti logic). Autorun events will also start overflowing the console if they regularly repeat, as will those common event updates, meaning the tester might not even see which events are continually running.

Taking all of these considerations into account, I came up with this:

class Game_Event < Game_Character alias_method :sol_debug_original_start, :start def start unless @trigger == 3 page = @event.pages.index(@page) + 1 puts "Running event #{@id} (page #{page}, map #{@map_id})." end sol_debug_original_start end alias_method :sol_debug_original_setup_page_settings, :setup_page_settings def setup_page_settings sol_debug_original_setup_page_settings if @trigger > 2 page = @event.pages.index(@page) + 1 case @trigger when 3 puts "Started autorun event #{@id} (page #{page}, map #{@map_id})." when 4 puts "Started parallel event #{@id} (page #{page}, map #{@map_id})." end end endendclass Game_CommonEvent alias_method :sol_debug_original_refresh, :refresh def refresh state = @interpreter sol_debug_original_refresh puts "Started parallel common event #{@event.id}." if state != @interpreter endendThe above code isn't perfect by any means, but hopefully it'll help to isolate potential eventing problems which could result in that kind of lag. I'm sure there are other edge cases that I didn't take into account, as well, so if anyone sees something which could be done better or more thoroughly, feel free to offer alternatives.

Tested, nothing happened...

That is exactly why I refered you to check the scripts. Because there are scripts that automatically turn on switches if those switches are configured to be used in the script.

For example Yanfly's message system automatically binds variables to the size of text messages. This is intended to allow the developer to increase or decrease the text box from its default size of four.

And whenever someone forgot to configure and reserve those variables correctly and started to use them...

This board is full of complains where either a calculation didn't work (because yanfly's message system loaded 4 as the default value into that variable) or that the text messages were suddenly zero lines high (because the developer used the variable and set it to zero without realising that this will change the message behaviour.

You cannot be sure that the values and switches are the defaults you know if you have added scripts to your project, unless you have checked every script for the switches and variables it uses. That is why you have to check their values on the map when it happens to see if something else changed them without your knowledge.

I made an event to turn off all switches of common events and parallel events on the map, but it's still the same.

Here's all scripts i'm using. Don't know if this could help...

Scripts.rar

 

[♥SOURCE♥]

Really, you should check your CPU clock speed.