Interpreter command_355 fix - Printable Version +- Save-Point (https://www.save-point.org) +-- Forum: Material Development (https://www.save-point.org/forum-8.html) +--- Forum: Scripts Database (https://www.save-point.org/forum-39.html) +---- Forum: RPGMaker XP (RGSS) Engine (https://www.save-point.org/forum-116.html) +---- Thread: Interpreter command_355 fix (/thread-874.html) |
Interpreter command_355 fix - Zeriab - 01-08-2010 Interpreter command_355 fix Version: 1.0 By: Zeriab Introduction You may have seen other Interpreter command_355 fixes. This is different from those I could locate by the fact that it repairs the nice feature rather than remove it. The script here fixes the multi-line issue with the call script command and improves the execution of the wait idea. For those who don't know. If the call script evaluates to false then the event waits a frame before running the script call again. (Consider it like Repeat next frame) If the script call was on multiple lines there was a single frame wait before it continued with the next event commands. This script fixes this issue so it wait whether single-line or multi-line. The script now waits on :wait. (And FalseClass for compatibility reasons) It is easy to change what call script should wait on. :wait conveys it's purpose much better than simply false and scripts accidentally evaluating to :wait is much less likely to happen than for false. Script Code: class Interpreter Instructions Copy and paste the script in a new section anywhere above main and below Interpreter 7. You can now use the new functionality in the script calls. (Event commands) Let the script call evaluate to :wait as long as you want the script call to repeat and anything else (except FalseClass) when you want it to continue. Could for example be :continue or nil. Naturally if the script call keeps evaluating to :wait then it will wait for ever. In practice it'll feel as if the event freezes. If it does not evaluate to :wait (or FalseClass) then it will continue interpreting the next event commands without any waiting. To show why this can be useful I have included a usage example. Usage example - Waiting for movements completion Most who have played around with the Wait for Move's Completion event commands knows that the command waits for the movement of all events to be completed. To precise it waits for all the movement set by Set Move Route..., not Autonomous Movement. This is can be problematic. If you one event which you have given a move route and checked Repeat Action then using Wait for Move's Completion will practically wait forever (unless that event is erased somehow). It is a typical cause for errors. There is no good method for waiting until itself, specific events and the player finishes the forced movement present in the eventing. By utilizing the waiting feature in the call script you'll see how we can solve this problem in an easy and elegant way. Let's start by making a method in Game_Character. (Add in its own section anywhere above main) Code: class Game_Character This method returns :wait whenever that character (the player or an event) is moving accordingly to a Set Move Route... and otherwise nil. (It won't wait on autonomous movement, just like Wait for Move's Completion) Now, how do you use it? Well assuming you have installed the script and you want to wait for the player to finish moving then it's just to put the following in a script call: Code: $game_player.wait_for_movement Code: class Interpreter Now the methods you can use in scripts are: Code: wait_for_players_movement # Wait for the player to finish movement Notice that nothing will happen the script call is used when in combat and wait_for_movement will only do something if called from a map event. It can be used in common events in which case it works if the bottom event of the call stack is a map event, but not if its anything else. (See my Common Events Tutorial for more information on how the call stack works) Note that if Repeat Action is checked or it gets stuck and Ignore If Can't Move is not checked, then freezes can happen. So be aware of these issues. At least you don't have to be aware of all the events. Only of the events you want to wait for. (And possible the player as well) Compatibility If you have scripts which relies on false => wait then you have to change SCRIPT_WAIT_RESULTS. Code: SCRIPT_WAIT_RESULTS = [:wait, FalseClass] #from this It waits on FalseClass to keep compatibility with my command_355 present in SDK 2.4 (It doesn't fix the multi-line issue, so I don't consider it an earlier version of this script) Terms and Conditions License Wrote:Copyright 2009 Zeriab Author's Notes Use :wait rather than FalseClass. If you use :wait then it will not only be easier to understand, but it is also likely that non-scripters will understand what it does. You could for example use :continue when the event should continue. It doesn't matter what it is as long as it is not one of those which cause the event to wait functionally, but it will document the behavior better. Self-documenting code is awesome :3 Be sure that it doesn't always evalute to :wait. *hugs* - Zeriab Interpreter command_355 fix - Lunarea - 01-08-2010 This is pretty cool. I often use "wait for movement" completion when eventing cutscenes and I have occasionally encountered the loop annoyance. I've saved a copy and will look into it in depth very soon. Thank you for sharing! *hugs* |