I cleaned up my event-driven mouse implementation in the default scripts I presented a long time ago. You can download the demo here: http://www.mediafire.com/?igqjhk8h01y2a2h
This does not add any functionality to click on the map except choices in the message window.
I will not present a modular script since this is highly integrated into the default scripts. Instead I have tried a different concept where I have placed all the copy-paste code just above main. (Except my attr_sec_reader and F12 fix, the latter which must be the first section)
I have marked the default script sections I have edited with a * in front of it's name. In those sections I have tagged the code I have removed with <REMOVE> using comment blocks and I have tagged the code I have added with <ADD> and </ADD>.
I could have been more precise showing more exactly what I have added/removed with my code tags but I decided to only doing whole line add and removal as that's easier understand.
Here is an example:
I just found this script by Bulletxt which abuses my butt-ugly $f12_cleaner_F3XXEFA1 from my previous F12 reset script. Yay for incompatibility -_-This time the testplay debug mode will not be lost.
I highly recommend that you do not try using the two scripts together.
Anyway I had a look at it and decided to revise it: http://paste-bin.com/view/0e59aa30
Oh, and this script is compatible with both XP and VX.
I highly suggest that you insert a section at the very top and paste the script there.
Here is a little ugly script which goes through all map and common events in the project checking the map transfers.
Copy and paste the script as the very first thing in the script editor.
Run the game. It should close after some time producing an out.txt file.
Delete the script again (so you can actually play the game).
This text file contains a list of maps you never transfer to. (If you use saves from a previous game they could easily end up here ^^)
A list of maps which there are transfers to, but which does not exist in the project. Each map id is accompanied by an array of map events (map_id:event_id) and common events (common_event_id) which has the transfer to the non existing map.
Here is a snippet which displays how you can read which controls have been entered through F1: http://pastebin.com/jQeJXLSF
Currently it disables gamepad controls. Anyone can feel free to merge it into their own work or use it as it is. (If you have gamepad troubles for any reason)
As I will leave for a long time I have decided to upload a bunch of unfinished stuff I have worked on. It's very unlikely that I'll finish any of them, so I thought I might as well make it possible for others to use and build upon the stuff if they want. They can all be retrieved from this mediafire folder. You'll find a short description of each below.
You are allowed to use anything I have made for any of these items for commercial and non-commercial projects alike except where explicitly otherwise mentioned.
A game I played around with several years ago. It turned into a script testing ground rather than a game. Eventually I forgot about it.
The relics of a system I made back when I was in the Gold Team guild in RMRK.
I abandoned it and didn't bother to try and solve its problems.
The idea is to allow RGSS library methods to be used in auto-completion and etc. in IDEs which for example could be Eclipse.
I started making a poker system based upon Trickster's Card Library. I believe credits goes to EiB, Tana and Wumpi for the cards. I don't know for which cards.
The PokerTest is a stress test of the two update schemes. I remember something about the Update_Scheme_Fast either being slower or insignificantly faster. Considering how ugly it looks it should probably just be removed.
Note that the license of the resources I use is not under my control. You are free to use the parts I have made.
A custom save/load system I made for a scripting contest back in November 2006.
A tech demo I made for a window system I once worked on. Some of the tests are stupidly multithreaded and there are game crashing race conditions present.
I remember the system as being a bit too elaborate and having some thight coupling problems. This is my second attempt.
ZWSold shows the first version before I started from scratch.
As far as I got with my multiple choice idea (I think).
The code sucks, but the idea doesn't. Hopefully someone will take the information here and make an awesome script. (Eventers will love whoever does it)
The structure for a minigame where you can give commands to a robot and let it execute them.
This is a tool which takes a project and attempts to swap pairs of switches and variables as specified in the config file. Its purpose is indeed to help make integration of event system simpler.
I think the idea is really cool and it would be awesome if someone extended it to work with more things.
Btw. let's not forget my mouse implementation into the default scripts:
Here are a few thoughts on multi-threading in RGSS. They may very well be applicable to RGSS2, but on the other hand there might be differences.
I am assuming that you have knowledge on the multi-threading in general.
It doesn't matter how many threads you make, only a single core on a single cpu can be utilized in RGSS.
I believe this is a short-coming of the Ruby interpreter itself although I am not completely sure.
It does seem like the Audio runs in a thread outside the Ruby environment and thus may be able to use another core to process the audio. (I am not completely sure about this)
In conclusion you should not expect any speed improvements by using more threads.
As you can derive from the name this method updates the graphics. It also tries to keep the frame-rate stable. This means that it halts until enough time has passed.
The problem is that Graphic.update does not only halt the thread calling the method. It halts all threads. You cannot stop calling Graphics.update since you will get a Script Hanging error after 8-10 seconds.
You can basically expect the performance of the other threads to decrease significantly.
Sprites appear not to be thread-safe. If you create sprites in one thread while another thread calls Graphics.update you may very well face a race condition which causes the game to crash.
It may perfectly be possible to safe-guard the Graphics.update call (by aliasing and making critical regions) so that the internal Graphics.update will never be called.
I suggest that you try to have all the sprite creation in the same thread as the Graphics.update. That way I don't think any nasty surprises will await you and allow normal thread-safety measures.
Performance-wise there is no real benefit in using more than 1 thread. In fact it will probably decrease the performance. Therefore only use more than one thread if alternatives makes the scripting much more complicated.
An example of where multi-threading could help is with a loading script or progress script where one thread takes care of handling sprites and updating Graphics.update as little as possible while the other thread does its loading or fancy (slow) algorithms.
Here's a little mention about an interesting special term, __END__.
The rest of the section after that will not be run. In fact I believe the parser will stop at __END__ and therefore won't even build the abstract syntax tree for what comes afterwards. (An effect is the lack of syntax checking)
This can be used for preventing the inclusion of test code except when you want to use it.
I am sure you can see how it can be helpful in providing test data for scripters while being ignored normally.
Of course you could use a if false ... end for similar effect.
The different is that the abstract syntax tree will be created while it will not when using __END__. On the other hand copy-pasting several sections into a single section may disable sections.
To show one use of Interpreter command_355 (RMXP) I'll show how you can make events wait for movement of a single event or the player to finish rather than all movements which the Wait For Movement's Completion command does.
Let's add this little snippet for checking whether Game_Character is moving or not. (Both Game_Player and Game_Event inherits from that class: (Add anywhere above main)
It returns :wait when called. You can now put $game_player.wait_for_movement in a script call and that event will wait until the player has stopped moving before continuing.
Likewise you can use $game_map.events.wait_for_movement for waiting until the event with id 7 has finished its movement.
It's simple, elegant and much easier than had the wait functionality been removed from command_355. It was an excellent idea in the default scripts albeit a little poorly executed and unfortunately not well-understood.
Next I will add some syntactic sugar to use in the call scripts which makes waiting for specific events easier. It's not needed at all, but it is more user friendly and nicer to use.
Add this script anywhere above main:
You can now simply put wait_for_movement in a script call and it will wait for its own movement to to be completed. (Note that it will simply skip if the interpreter does not originate from a map event. See my Common Events tutorial for more information on this subject)
You can specify a specific with wait_for_movement(id) where id is the id of the map event. If you for example want to wait for event 7 then use wait_for_movement(7).
You can wait for the player by using wait_for_movement(0) or by using wait_for_players_movement.
Note that it will do nothing if called in battle.
You cannot comment on the entries I post here, so I have decided to post RGSS related entries also in my blog here at owainc.net.
I will add links for the entries to there respective entries in that blog as a comment. This means you will actually have to on the entry or the 1 comment at the bottom to see the link. This is just to avoid clutter.
Note that you may have to register to see the blog.
1-10 of 22