Inhaltsverzeichnis

1. Einleitung
2. Instructions
3. Credits and Thanks
4. Author's Notes

1. Einleitung

How many of you tried creating a parallel process where you put in an amount of frames and then a script call or something else afterwards? Basically a simply way of doing something after an amount of frames.

This is the principle behind the script. To schedule pieces of code to be executed after an arbitrary amount of frames. No making decrementing counters. The scheduler takes care of all that or well most of it. It is still not as simple as using the wait event command.

2. Instructions

You can schedule in two ways.
You can do a one-time schedule which works like this: (Using the class method)

The 65 means that the proc will be called after 65 frames. (Or 65 ticks to be more precise. 1 update = 1 tick usually)
After 65 ticks the proc {|x,y| p x,y} will be called with the arguments x = "A string" and y = 42. (The *arguments means any number of arguments. This can also be no arguments at all)
The Scheduler uses duck typing and assumes that anything which has the .call method works properly in the context. I imagine procs and methods to be the most commonly used.

The next is that you can schedule a recurring call which works like this: (Using the class method)

The arguments is the same as for the one-time with the addition of the frames_to_wait argument.
This specifies that after the first 65 ticks each recurring call will happen after 30 ticks.
This will continue until the callable returns FalseClass. (Mind you it's false.class and not false)

Now you have to update the schedule every frame or it won't schedule properly.

Note that the class methods only work for one scheduler. I believe this should be the generally working Scheduler.
Compatibility

The Scheduler alone use only Ruby and could easily be placed in a Ruby if one wanted that.
It is highly unlikely that you will encounter any compatibility issues with the backbone alone since it is independent from RGSS/2 library.

On the other side there could potentially be problems with the bindings which makes use of the scheduler so it actually does something in game.
Currently there is only the Graphics.update binding which makes compatibility issues very unlikely.
Future Work

• Explicitly exit/stop a scheduler. The scheduled items can then be discard, executed or maybe something else.
• Error handling. (This may be an external. I.e. not embedded in the core)
• Documentation

3. Credits and Thanks

Credits goes to Zeriab for creating the system

I would like to thank everyone using their time to try and use my system.
I would like to thank everyone reading this topic.

Thanks.

4. Author's Notes

I would be delighted if you report any bug, errors or issues you find.
In fact I would be delighted if you took the time and replied even if you have nothing to report.
Suggestions are more than welcome.

Note that I will release a demo which shows a couple of ways of using this script.
Note also that I will always make a post when I have an update. (Small stuff like typos excluded)

And finally: ENJOY!

- Zeriab