rgss tips : xp structures and ace structure

[Tsukihime]

It's not impossible to alias in XP.


It just isn't as effective as it is in VX or Ace.

 

[Heretic86]

I dont get what is so difficult about aliasing in XP.  This is typically the way I do a lot of stuff:

class Some_Class  alias new_update update unless $@  def update    # Call Original or other Aliases    new_update    # Do Stuff    @property = change_things_around()  endend
Admittedly, when everything is more modularized, it makes the use of aliases much easier, but not impossible, however, there are times it is very inefficient...

class Interpreter  alias interpreter_update update unless $@  def update    # if Some Condition    if some_condition(condition_value)      # Do some other update thing     do_update_thing     # Return if some other condition     return unless some_other_condition(condition)   end      # Call Original or other Alias      interpreter_update  end  endend
None the less, the way I've learned to try to write my own code is to try to keep it as modular as possible.  I didnt do this in many of my early scripts, but through experience now know to write XP scripts with VX modularizations for improved compatability.  If I have to do any sort of nested loops and make checks inside those loops, I use methods to create the list of items to iterate through and more methods where the conditional checks are needed.

For example, instead of this:

class Some_Class  def update    # Do lots of other code here    for event in $game_map.events.values      if event.move_route_forcing        return      end    end  # Lots of other code that may not run based on the nested conditions above  endend
Thats bad juju.  The whole thing would have to be bypassed to achieve our goals, especially if the goal is prevented from running by the internally nested returns with unmodifiable results.  The better way to do it is to modularize so that conditions can be altered without the need to replace the method.  We complain a lot about the way Enterbrain wrote the code for XP, yet, when we write our own scripts for XP, we fall into the same traps.  Guess what, the guys at Enterbrain are human and make mistakes too.  They've definitely learned from the 'mistakes' in their older versions becuase they've learned the consequences of not modularizing stuff.  We should all be careful to not fall into the same traps.

This is more modular

class Some_Class  def make_events_list    # Returns all Map Events    $game_map.events.values  end  def this_method_condition?(event)    # Returns value of condition    event.move_route_forcing  end  def update    # Bunch of code    # Nested Loop with modifiable results    for event in make_events_list      return if this_method_condition?(event)    end    # More bunches of codes  endend
This code allows for altering the results without replacing the method, so an addon script might look like this:

class Some_Class  def my_new_condition     $game_switches[switch_id]  end  alias new_make_events_list make_events_list unless $@  def make_events_list    # If this scripts new conditions are met    if my_new_condition      # Returns smaller list of events to iterate through if my_new_condition is enabled      return $game_map.select_events_at_xy(@x, @y)    end    # Call Original or other Aliases    new_make_events_list  end  alias adjustment_to_this_method_condition this_method_condition unless $@  def this_method_condition(event)    # Check for some other condition    return false if event.move_route_repeat    # Call Original or other Aliases which doesnt check for move_route_repeat    adjustment_to_this_method_condition(event)  endend
As you can see, you can use aliases to alter the outcome of the larger chunks of code that have heavily nested iterations as long as that nested code is modularized well enough.  This is probably the most imporatant difference between XP and the VX series, and the reason that XP ended up with a bunch of scripters trying to create an SDK, and VX+ did not have any need for it.  Problems do result when everyone tries to completely replace core methods as all of the aliases of the original methods are ignored, depending on the placement of the script.  Its also why most scripts need to go between Scene_Debug and Main.  The more that aliases are used, the better the compatability.  The more that methods are flat out replaced, the less compatability.  The SDK for XP replaced most of the methods, with a few exceptions, and resulted in a requirement to be directly below Scene_Debug and above all other scripts.

Since the title of this thread is in regards to RGSS Tips : XP Structures, we can focus on how to write the best code possible, not just griping about "cant do this".  So lets carry on to other significant scripts: The RPG Module.  The RPG Module is not listed as part of the default scripts we have access to.  Certain sections of it are available in the Help file, while other proprietary stuff is not.  A few of us might decide to alter the way that those RPG Module scripts work as well.  Since these types of scripts are modified by experienced scripters, they are usually much more compatible.  The reason for this is the structure of the RPG Module scripts have very few update methods, so there is a lot less nesting as opposed to something like Interpreter update, where conditions are heavily nested and not modular. 

For example, from the Help file for XP, this is RPG::Actor

module RPG  class Actor    def initialize      @id = 0      @name = ""      @class_id = 1      @initial_level = 1      @final_level = 99      @exp_basis = 30      @exp_inflation = 30      @character_name = ""      @character_hue = 0      @battler_name = ""      @battler_hue = 0      @parameters = Table.new(6,100)      for i in 1..99        @parameters[0,i] = 500+i*50        @parameters[1,i] = 500+i*50        @parameters[2,i] = 50+i*5        @parameters[3,i] = 50+i*5        @parameters[4,i] = 50+i*5        @parameters[5,i] = 50+i*5      end      @weapon_id = 0      @armor1_id = 0      @armor2_id = 0      @armor3_id = 0      @armor4_id = 0      @weapon_fix = false      @armor1_fix = false      @armor2_fix = false      @armor3_fix = false      @armor4_fix = false    end    attr_accessor :id    attr_accessor :name    attr_accessor :class_id    attr_accessor :initial_level    attr_accessor :final_level    attr_accessor :exp_basis    attr_accessor :exp_inflation    attr_accessor :character_name    attr_accessor :character_hue    attr_accessor :battler_name    attr_accessor :battler_hue    attr_accessor arameters    attr_accessor :weapon_id    attr_accessor :armor1_id    attr_accessor :armor2_id    attr_accessor :armor3_id    attr_accessor :armor4_id    attr_accessor :weapon_fix    attr_accessor :armor1_fix    attr_accessor :armor2_fix    attr_accessor :armor3_fix    attr_accessor :armor4_fix  endend
As you can see in that code, there is no update method.  We can add properties without replacing the method.  This class is also used as the parent class of Game_Actor, so it is possible to also add the same properties in Game_Actor < Game_Battler initialize method instead of modifying RPG::Actor.  RPG Modules are accessed with the super() calls.  I have not found very many reasons to access the RPG Modules, of course, there are exceptions.  Things like Weather would need to modify the RPG modules to pull off an effect like making the rain or snow change direction.  RPG::Weather does have an update method where as RPG::Actor does not.

In short, we would all do well to continue to learn from mistakes in general, just as Enterbrain has.  Mistakes are never failures, nor are they valid reasons to quit learning.  We learn just as much from mistakes as we do from successes.  If Thomas Edison were alive today, he would tell you that he only knows a few ways to make a Lightbulb, but because he learned from mistakes, he knows thousands of ways to NOT make a lightbulb.  He understood the value of mistakes.  He knew that success comes just as much from doing something right as it does from the undersdtanding that comes from knowing how not to do something.

There is no 'right' or 'wrong' way to do something.  It either works, or it does not.  RPG Maker XP is a functional product.  If it did not run at all, no one would use it.  It can be modified as much as VX and Ace can be modified.  It is more challenging to write for RPG Maker XP because of the lack of modularization, more challenging, but certainly not impossible.  Many of the scripts I have written all work together, with and without the SDK.  So I will tell you from experience that when your code is properly written in XP, you can achieve what seems like the Impossible.  In my scripts, I have replaced just two of the Enterbrain definitions.  Then I wrote a few more scripts that enabled me to do things that I could not have done before, and they work together 100%.  So in short, just by replacing two methods, which is normally bad, I use those two replacement methods as a foundation to build on.  Just by replacing those two methods, I am able to achieve allowing NPCs to move around on Event Tiles like the Player can, fully control which tiles each Character can move on, Loop Maps, I have Vehicles including Boats, Magic Carpets and Airships, I can restrict passage per event and per event page based on Bush flags, I can move Characters Diagonally on Stairs, I can make them slide Downhill on Downhill Ice, I've created a Hotfoot Tiles without any need for Terrain Tags, I've optimized the Collision Detection engine by making Event Lists modular and work more like Game Switches instead of iterating every single Map Event for every other Map event, and will soon start working on a Platforms Script as well.  They all work with a Caterpillar script for XP as well as a Framerate Optimization script.  These scripts are not released yet because they all need to be created together so that they work together.  I will release this pack of scripts eventually.  Although replacing core methods is usually bad juju, the methods were written to be fully 100% modular so ANY necessary alaterations to the data inside the nested loops can be altered.  How many XP games can claim Vehicles, Stairs, Ice, Caterpillar, Framerate Optimizations, Total Control over Character Movement, Platforms and Looping Maps?  Scripts for each feature are already out there, but I have yet to see a 100% compatability between ALL of them.

None the less, the point is that when scripts are properly written by us, not just Enterbrain, we can achieve seemingly impossible things.