Jump to content
Sign in to follow this  
  • entries
    2
  • comments
    10
  • views
    3,374

A foolish code aliasing mistake Rpg Maker coders should avoid

GethN7

1,185 views

To quote a line from Treasure Island "I own myself an ass."

 

Why? Because I made a very foolish rookie coder mistake when working on my current game project that has made every build since the errors were introduced have game breaking bugs, and it was because of foolish oversights on my part.

 

The issue was that the minigame scripts I used for my ingame casino lacked sane exit conditions for the scene window script they were intending to alias, and it caused my entire project to be retroactively corrupted.

 

However, I'm getting ahead of myself, let me explain aliasing in coding terms.

 

Aliasing in Ruby code (which RM VX Ace uses) means code that does one thing is rerouted to an alias, or alternative. For instance, if I aliased the word "apple" to be rendered "orange" in a program determining how many uses of the words apple and orange were in a block of text, all it would result in finding nothing but uses of "orange', since "apple" was aliased to render as "orange".

 

This is fine, but if an alias is not sanely terminated when you need the program to render "apple" as "apple", it will continue to render "orange" even when you need "apple", which will retroactively screw up everything afterwards since the aliasing never terminated sanely, so everything using the original code will be horribly screwed up.

 

In that sense, I own myself an ass, because I did not check to make sure the minigame scripts I imported sanely terminated the aliasing for their custom window scenes and reverted back to the stock settings, which was causing all sorts of anomalies in the display of all window scenes afterwards, and while some errors were not immediately apparent, I should have exercised due diligence to make sure the alias terminated sanely, since that would not be easily detected at first since aliasing does not ordinarily cause game crashes if it affects non vital code, such as the rendering of window boxes.

 

I have fixed the issues and confirmed them resolved, but this was a mistake I made due to lack of adequate back checking of the scripting calls, and I advise anyone importing any script into their game that uses aliasing of stock code make sure the alias terminates sanely, else your game will retroactively be corrupted in terms of functionality.

 

This tip also applies to Ruby coding in general.

  • Like 2


8 Comments


Recommended Comments

Eh? Wait are you saying you need to alias things and then unalias them later? That kind of defeats the whole point of aliasing as it is commonly used doesn't it? Or are you just saying the chain gets broken and the original method never called? It sounds like you are using monkey patching when you should be making a whole new window subclass to use for your minigame.

Share this comment


Link to comment

What I'm referring to is that the scripts I used did not revert control back to the stock RM VX Ace window scene code once it was done with it's need to alias to the alternative schema for correct visual display of the minigame.

 

So yes, more like the chain got broken and the original method was not called again when there was a need for it.

Share this comment


Link to comment

Oh I see. Still think new scenes should use subclasses instead of aliases though.

Share this comment


Link to comment

Oh I see. Still think new scenes should use subclasses instead of aliases though.

 

I agree, but since I'm a very poor coder, it's still good for newbs who use community scripts to make sure that if they have to use aliased scripts like I did, they should make sure they terminate sanely.

Share this comment


Link to comment

How does one know if an alias terminates sanely?

 

Let's say you have a custom scene where the text window changes font, appearance and size. If after leaving that custom scene the ordinary text window refuses to act normally, that's a good sign the alias for the custom window settings did not terminate sanely.

Share this comment


Link to comment

I'm no coder but I know enough about them to understand...when the window is given the name (alias?) at the beginning of the script, it must be deleted before the script ends? From what I've seen, that's how it appears to work..

Share this comment


Link to comment

I'm no coder but I know enough about them to understand...when the window is given the name (alias?) at the beginning of the script, it must be deleted before the script ends? From what I've seen, that's how it appears to work..

 

I concur.

Share this comment


Link to comment
×
Top ArrowTop Arrow Highlighted