Zeriab

Thanks Nisage :3

Welcome to RMXPU :D I hope you will enjoy your stay and also find it fruitful *hugs*

Thanks for the nice welcome :3 @rgangsta: I also hope we become friends ^_^ @Enigma: I wish I knew so I could prevent it from happening again >_< I chose C# because my future employer asked me too. @CrimsonInferno: I actually do remember you although I don't remember for what. It is nice to see you all again and I hope you have been well :D *hugs*

I prefer Bing's picture search over google's now. -_- I wish there were a way to use the old one.

Hi everyone ^_^ I have missed you guys :3 I have been doing well being busy with stuff I am too lazy to describe. Do not expect much new work from me in terms of scripting though. It is mainly the culture I came back for. I have to learn C#, so it is possible that I will create and share some C# applications, but no promises. I do hope you have all been well in my absence. *huggles* - Zeriab

This is my final goodbye. I will not read any posts below this message. You really have all been so wonderful and it is not easy to say goodbye. It has been a pleasure knowing you all and giving you hugs <3 I hope this forum will continue to prosper and become even more grand. You can contact me at: vobbys (at) gmail [dot] com Do not expect fast replies as I'll only check the email very occasionally. (A month or more may pass between my checks) *gives every reader a LEGENDARY hug* Oh yeah, I have uploaded a bunch of unfinished stuff which is practically free to use.

Thanks for your kind words <3 @isaacsol: Yup, afraid so. Take care while I am away. @The Hooded Man: which am I missing =o? @Wyzrd: It has been fun contributing ^^ I hope I can come back fairly soon and I hope you will also take care, have fun and be safe. @Arkbennett: Thanks Ark. It means alot. It has indeed been a long time since we last talked. I will miss you as well. I am sure you'll do fine without me. I hope life treats you well :3 *hugs*

I'll miss you all. @RATED-RKOFRANKLIN: My welcome topic It is perhaps a bit outdated >_> Thanks for the well-wishes ^_^ Luckily nothing bad has happened IRL. I hope you will be well. @den13: Thanks, I hope you will have a good time as well. @Marked: Aww, thanks :blush: I have indeed been around a long time, but with great people you can never be around too long. I hope my contributions will keep being useful even while I am not here. I wish the best for you and your forum. @totalsticks: It's sad I didn't get to know you. Hopefully you'll be around for a long time and if I come back we can get to know each other :D @Polraudio: We have indeed had a long history ^^ I hope you will keep working and keep growing. I hope life will treat you good until we meet again. (Also afterwards) @The Hooded Man. Thanks :D I hope that will or maybe the developer will whom I am also hiding. Be well *hugs*

Hey all, Due to RL stuff I will take my leave for at least a couple of months and maybe even years. It has nothing do with this forum except that it uses my time. (Because you are all so wonderful :cute:) I have known it for a long time and nothing bad has happened, so don't worry about me ^^ I will therefore leave in one week rather than atm. It's I can respond to your goodbyes and have some last minute discussions I love you all *hugs* - Zeriab

Welcome back Legacy :D I hope you will stick around for a long time ^_^ Can I pm you with any scripting issue I might run in to? *hugs*

I did indeed post this on my site a while ago. My mistake was that you couldn't really write comments there >_< It's not the best code and the naming could be better. But then it would have been easier to figure out. Your guess is not correct. There is already a way of getting an event's terrain tag. No, it does something else. It is related to terrain tags.

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. Single Core 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. Graphic.update 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 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. Conclusion 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. class Medal include Comparable attr_reader :titel, :time def initialize(titel, time) unless time.is_a?(Numeric) raise ArgumentError.new("Time must be a numeric") end @titel = titel @time = time end def <=>(medal) return time <=> medal.time end end __END__ class TestError < StandardError; end bronze = Medal.new('Bronze', 180) bronze2 = Medal.new('Bronze', 180) bronze3 = Medal.new('Bronze3', 180) silver = Medal.new('Silver', 105) gold = Medal.new('Gold', 87.5) unless (bronze == bronze2) raise TestError.new("Medal.== does not compare #{bronze.inspect} " + "and #{bronze2.inspect} properly") end unless (bronze == bronze3) raise TestError.new("Medal.== does not ignore the title") end unless (silver <=> bronze) == -1 raise TestError.new("Medal.<=> does not return -1 when its time is less" + " than the medal compared to") end unless (silver <=> gold) == 1 raise TestError.new("Medal.<=> does not return 1 when its time is greater" + " than the medal compared to") end unless (bronze <=> gold) == 1 raise TestError.new("Medal.<=> does not preserve transitivity.\n" + "I.e. <=> is highly problematic.") end p 'Medal testing completed successfully'

To show one use of my Interpreter command_355 fix 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 Move'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) http://paste-bin.com/view/6af9b1c2 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[7].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: (Script put at bottom) 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. class Interpreter ## # Wait for movement where: (Nothing will happen in combat) # id < 0: Current event (if there is one) # id = 0: Player # id > 0: Event with that id (if there is one) # def wait_for_movement(id = -1) # If in battle return if $game_temp.in_battle # Get actor actor = nil if id < 0 && @event_id > 0 actor = $game_map.events[@event_id] elsif id == 0 actor = $game_player else actor = $game_map.events[id] end # Wait for actor's movement unless actor.nil? actor.wait_for_movement end end ## # Wait for player's movement # def wait_for_players_movement wait_for_movement(0) end end

This command has given people headaches and many don't really understand it. In the default scripts if the script call is evaluated to false then the event waits and tries evaluating the script again. Naturally if you don't think or accidentally cause false to be the result of the script call all the time, the event practically freezes. An example could be $game_switches[42] = false which will evaluate to false every time. I really think that is not the purpose. Of course you could have $game_switches[42] to halt the event until that switch is turned on. This can have some nice practical purposes that I haven't seen. The solution I most often see is: Oh god no! Let's remove it since it causes my game to freeze! This is obviously not the most ideal solution. It is true that in practice many errors has been cause by the default behavior and considering how little people seem to use that feature it does seem to better to remove it than to keep it as it is. As you can hear I am not too happy about the idea. It is a nice feature that I would want to keep. My solution would be to check if the call script evaluates to something which it is unlikely to do by accident. I have pushed through the check for FalseClass which is present in the SDK 2.4, but that doesn't really convey the purpose that well. Checking for the :wait symbol is a nicer solution since it conveys what it means very well. I believe it's very unlikely that someone would make a call script which returns :wait by accident. It is at least much more unlikely than false. Below is a script which also is compatible with the FalseClass version. class Interpreter SCRIPT_WAIT_RESULTS = [:wait, FalseClass] #------------------------------------------------------------------- # * Script #------------------------------------------------------------------- def command_355 # Set first line to script script = @list[@index].parameters[0] + "\n" # Store index in case we need to wait. current_index = @index # Loop loop do # If next event command is second line of script or after if @list[@index+1].code == 655 # Add second line or after to script script += @list[@index+1].parameters[0] + "\n" # If event command is not second line or after else # Abort loop break end # Advance index @index += 1 end # Evaluation result = eval(script) # If return value is false if SCRIPT_WAIT_RESULTS.include?(result) # Set index back (If multi-line script call) @index = current_index # End and wait return false end # Continue return true end end Notice that I also fixed the bug where it would not wait with multi-line call scripts. If you want to also have support for false then you can change SCRIPT_WAIT_RESULTS = [:wait, FalseClass] to SCRIPT_WAIT_RESULTS = [:wait, FalseClass, false] You can also put in your own objects to check for. *hugs*

Hey all! I stumbled upon project which contained a script I made who knows how long ago. I admit I had completely forgotten about it. So who can guess what it does? It's obviously for XP since it does something with terrain tags, but what? I may update this post with the answer some time later :3 *hugs* class Game_Character attr_accessor :terrain_tag alias_method(:zeriab_terrain_tag_passable, :passable?) def passable?(x, y, d) new_x = x + (d == 6 ? 1 : d == 4 ? -1 : 0) new_y = y + (d == 2 ? 1 : d == 8 ? -1 : 0) if terrain_tag if (terrain_tag > 0 && $game_map.terrain_tag(new_x,new_y) != terrain_tag) || (terrain_tag < 0 && $game_map.terrain_tag(new_x,new_y) == -terrain_tag) return false end end return zeriab_terrain_tag_passable(x, y, d) end end class Game_Event < Game_Character alias_method(:zeriab_terrain_tag_init, :initialize) def initialize(map_id, event) zeriab_terrain_tag_init(map_id, event) if event.name.include?('<t>') self.terrain_tag = $game_map.terrain_tag(x, y) elsif /<t=(\d+)>/ =~ event.name self.terrain_tag = $1.to_i elsif /<t=-(\d+)>/ =~ event.name self.terrain_tag = -($1.to_i) end end end

Here is a small script I cooked up some time ago. It extracts all the text messages and choices of all the events in the game. One file for the map events, another for the common events and a third text file for the battle events. It can be useful for reviewing purposes and also for simple-minded word spell-checking. Note that since there is loss of information to the format presented you should consider it infeasible to be able to inject your modifications back into the project by automatic means. I know there is a French project which can do this, but the text files are not as nice to read. To use the script create a new section right above Main and run the program. Delete the section afterwards. You now have 3 new dialogue_xxx.txt files in the project folder. *hugs* P.s. thanks to Trebor777 for the idea of using blocks instead of f = and f.close def update_sprite if @sprite.nil? @sprite = Sprite.new @sprite.bitmap = Bitmap.new(640, 120) end current = $current unless current == $last $last = current @sprite.bitmap.clear unless current.nil? @sprite.bitmap.draw_text(8,4,600,32,$last.map) @sprite.bitmap.draw_text(8,40,600,32,$last.event) end end end ## # A separate thread that will run and make sure the Graphics.update is updated # every now and then. # Thread.new { loop do # Lets the thread sleep for a while to minimize CPU usage sleep 0.1 # Update the sprite update_sprite # Update the graphics Graphics.update end } Current = Struct.new(:map, :event) $current = nil Map = Struct.new(:name, :map_id, :events) Event = Struct.new(:name, :event_id, :pages) Page = Struct.new(:number, :list) ListElement = Struct.new(:message, :type) ###### ###### class Map def write_to_stream(io) io.print "\r\n########################################" io.print "\r\n# Map #{map_id} ~ #{name} (#{events.size} events)\r\n" io.print "########################################\r\n" for event in events event.write_to_stream(io) end end end class Event def write_to_stream(io) io.print "\r\n-= Event #{event_id} - #{name} =-\r\n" for page in pages page.write_to_stream(io) end end end class Page def write_to_stream(io) io.print "Page #{number}:\r\n" for element in list element.write_to_stream(io) io.print "\r\n" end end end class ListElement def write_to_stream(io) io.print message end end ###### def process_list(list) # Go through the event commands in the list rlist = [] # resulting list command_index = 0 while command_index < list.size command = list[command_index] if command.code == 101 message = command.parameters[0].rstrip loop do break unless command_index + 1 < list.size if list[command_index+1].code == 401 command_index += 1 message += " " + list[command_index].parameters[0].rstrip elsif list[command_index+1].code == 102 command_index += 1 for text in list[command_index].parameters[0] message += "\r\n" + text.rstrip end else break end end rlist << ListElement.new(message, 'text') elsif command.code == 102 message = "" for text in list[command_index].parameters[0] message += "\r\n" + text.rstrip end rlist << ListElement.new(message, 'choice') end command_index += 1 end return rlist end ###### class CommonEvent < Struct.new(:name, :event_id, :list) def write_to_stream(io) io.print "\r\n-= Common Event #{event_id} - #{name} =-\r\n" for element in list element.write_to_stream(io) io.print "\r\n" end end end common_events = load_data('Data/CommonEvents.rxdata') ces = [] for ce in common_events.compact # Look at which event is currently processing cur = Current.new("Processing common events...", "Common event #{ce.id} - #{ce.name}") $current = cur # Process the list list = process_list(ce.list) unless list.empty? # Create struct current_ce = CommonEvent.new(ce.name, ce.id, list) ces << current_ce end end ###### ###### class Troop < Event def write_to_stream(io) io.print "\r\n-= Troop #{event_id} - #{name} =-\r\n" for page in pages page.write_to_stream(io) end end end troops = load_data('Data\Troops.rxdata') battle_events = [] for event in troops.compact # Look at which event is currently processing cur = Current.new("Processing battle events...", "Troop " + event.id.to_s + " - " + event.name) $current = cur # Create the event struct current_event = Troop.new(event.name, event.id, []) # Create pages event.pages.each_with_index do |page, page_index| list = process_list(page.list) unless list.empty? current_page = Page.new(page_index+1, list) current_event.pages << current_page end end # Let's disregard useless events battle_events << current_event unless current_event.pages.empty? end ###### ###### infos = load_data('Data\MapInfos.rxdata') maps = [] for map_id, map_info in infos.sort # Create map struct current_map = Map.new(map_info.name, map_id, []) maps << current_map map = load_data(sprintf("Data/Map%03d.rxdata", map_id)) # Create event structs for event_id, event in map.events.sort # Look at which event is currently processing cur = Current.new("Map " + map_id.to_s + " - " + map_info.name, "Event " + event_id.to_s + " - " + event.name) $current = cur # Create the event struct current_event = Event.new(event.name, event_id, []) # Create pages event.pages.each_with_index do |page, page_index| list = process_list(page.list) unless list.empty? current_page = Page.new(page_index+1, list) # Let's disregard useless pages current_event.pages << current_page end end # Let's disregard useless events current_map.events << current_event unless current_event.pages.empty? end end # Update status info cur = Current.new("All maps have been processed", "Writing to a text file") $current = cur File.open('Dialogue_Map.txt', 'wb') {|f| f.print "THIS FILE CONTAINS THE DIALOGUE EXTRACTED FROM THE MAPS\r\n\r\n" for map in maps map.write_to_stream(f) end } File.open('Dialogue_Common.txt', 'wb') {|f| f.print "THIS FILE CONTAINS THE DIALOGUE EXTRACTED FROM THE COMMON EVENTS\r\n\r\n" for ce in ces ce.write_to_stream(f) end } File.open('Dialogue_Battle.txt', 'wb') {|f| f.print "THIS FILE CONTAINS THE DIALOGUE EXTRACTED FROM THE BATTLE EVENTS\r\n\r\n" for be in battle_events be.write_to_stream(f) end } exit

I already have my site which is kinda bloggish: http://sites.google.com/site/zeriabsjunk Commenting for visitors is tedious at best, so I will be crossrefering to this blog in case anybody wanted to comment on anything. I'll start by reposting the RGSS related entries from my site here should people want to comment on them. Note that scripts for RPG Maker XP are filed under RGSS and scripts for RPG Maker VX are filed under RGSS2. Entries about scripts that works in both are filed under both RGSS and RGSS2 By standard assume that the entries are about XP since that is what I typically work with. *hugs*

Your assumption that each download is a lost sale bloats up the estimated loss. I can certainly see your reasoning from a business point of view. The higher the loss caused by the piracy the higher possible worth can your company generate for your customers. I think you have an interesting business idea and I am sure there is a market for it. I just hope you'll be able to become well established before the market saturates. *hugs* - Zeriab

I am happy that it has helped you :D

Hi, The code does not end properly. For example some code This is also present in the code block. Additional code blocks are wrapped in the earlier: some more code You have to wrap the code tags in another tag to stop that behavior I hope I have explained the issue properly ^_^ *hugs*

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 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) 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: Simply right? For events you have to specify the id, but to both protect non-scripters and to provide syntactic sugar here is another script you can use: (Add in its own section anywhere above main) Now the methods you can use in scripts are: 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. It has not been included due to the apparently many accidental evaluations to false. 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 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. P.s. I spoilered the code segments since the code tags doesn't work properly. *hugs* - Zeriab

According to the EULA for XP you cannot use the XP graphics in VX, but I dunno if they have made the other way possible. I haven't read the VX RTP EULA.

1: Wait for Move's Completion is an event command you have to be very careful when using. It waits for all Set Move Routes to end. If you have a Set Move Route on repeat or an event gets stuck so it never finishes, then you will wait forever. If player is frozen while you wait the game is practically stuck. Wait for Move's Completion can lead to errors which can be very hard to debug. It is much safer to wait for a specific amount of frames, but there are situations where using it is much more practical. Just be very careful when using it. It is a typical cutscene design problem. All event triggers except Parallel Process causes the player to freeze until the event has finished executing. You can make the player unable to move around by having a parallel process which sets the move route of the player to wait a frame or two. Note that you would still be able to call the menu screen. 4: Put this in a script call: var_id = 10 if $game_party.actors.empty? $game_variables[var_id] = -1 else actor = $game_party.actors[0].id $game_variables[var_id] = actor end You can change var_id to whatever variable you want to store which actor is leading. (No leading zeros, i.e. var_id = 09 bad, var_id = 9 good) You can then use a conditional branch to check which id the leading actor have. If party is empty then the variable is set to -1. *hugs* - Zeriab