Save-Point
Ruby Scripting - Printable Version

+- Save-Point (https://www.save-point.org)
+-- Forum: Games Development (https://www.save-point.org/forum-4.html)
+--- Forum: Tutorials (https://www.save-point.org/forum-19.html)
+--- Thread: Ruby Scripting (/thread-7532.html)

Pages: 1 2 3

RE: Ruby Scripting - kyonides - 07-17-2023

To Encapsulate? Or Not to Encapsulate?
That is the... Controversy! Shocked

On another board I wound up talking about breaking encapsulation.

Happy with a sweat What is encapsulation?

Thinking Is it a bad thing at all?

The term itself is defined as:

Wikipedia Wrote:Encapsulation is used to refer to one of two related but distinct notions, and sometimes to the combination thereof:

A language mechanism for restricting direct access to some of the object’s components.

A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data.

That is limiting how you call and manipulate a given portion of code belonging to the object. Keep in mind that an object can be either a class or a module in Ruby Ruby. Even numbers are objects because they do own several methods.

The second part handles the way you implement your internal and external calls inside blocks called methods in Ruby and functions in C, C++ and Javascript. This is some sort of task management. A single method is NOT supposed to take care of EVERYTHING.

A bad example that is linked to the lack of modularity is any main method in scene scripts found in RMXP. main contains almost everything. (The usual exception would be its update method.) That changed in VX and VX ACE because they do feature many helper methods like pre_start and start or terminate there. Now every method has a task or a group of related tasks to perform inside every method.

How do we know we are breaking the encapsulation?

Happy with a sweat Have you asked a scripter to give you at least a hint on how to access any of the current scene's methods from the Game_Party or the Spriteset_Map or vice versa?

Indifferent Guess what? You broke it! Judge Police 

You are only supposed to access the methods already provided by the script and that's it!

Happy with a sweat Oh yes, I know that it would make custom patches very difficult to be crafted under certain circumstances. Even so, you could accomplish the same goal in a totally indirect way instead.

And it is totally true that we got the attr_reader and attr_writer or attr_accessor methods to quickly make its variables accessible for free. But there's a catch! Shocked

Thinking What happens if you call the variable directly?

In order to make a point here, I will need to come up with some mockup code to better illustrate it.

Code:
class Game_System
  alias :gm_sys_init :initialize
  def initialize
    gm_sys_init
    @traps = []
  end
  attr_reader :traps
end

There I created a new traps method belonging to the Game_System class that is accessible via the $game_system global variable.

Am I breaking the encapsulation principle here? Confused
Apparently not... but I could be in no time. Shocked

Who Knows? How could you do it?

Well, it could be as EASY as making the following call.

Code:
$game_system.traps[10] = BearTrap.new

There I have already altered the actual contents of the traps Array without caring about checks and controls. Confused

Such cases demand from us the creation of custom methods to ensure we won't be leaving blank spaces or any foreign object that should not be found there like a number or a boolean. Happy with a sweat

A good but quite limiting example of this could be the $game_party.add_actor method that will limit the number of heroes that can join our party in RMXP or RMVX.

Happy with a sweat Yes, that means you got to create more and more wrapper methods to keep access to $game_system or $game_party methods safe. Laughing

A scripter's life is hard, guys! Tongue sticking out


RE: Ruby Scripting - kyonides - 08-22-2023

This is something everybody should know about Patches and Bug Fixes.

Patches could also be named bug fixes depending on the issues that might have appeared while working on modifications of existing scripts. In other cases they might just alter or even replace the way the "original" script was supposed to work.

ALWAYS treat them as separate scripts. You'll thank me later on. Especially true if any patch you have included in the script editor ends up giving you headaches because it's not compatible with any other script there. Also true if it has some bugs that need some fixing.

If the Patch includes any mention of class SomeName or module AnotherName, it NEVER belongs to a script call event command. Create a new section in the script editor and paste it there.

Patches and Bug Fixes should always be placed in any free section BELOW their "parent" scripts, the scripts they partially modify or extend with new features.

RE: Ruby Scripting - kyonides - 08-28-2023

self && @instance_variables

In RGSSx scripts it is not impossible to find calls that begin with a self reserved word.

What is self? Thinking

As we had learned long time ago, self simply means the same class or module.

Why is it there? Detective

In modules like Kernel or RPG::Cache alias Cache and the File class, you cannot call certain methods UNLESS you include the actual module or class name somehow.

While defining stuff pertaining to your module or class, you can avoid using its actual name and simply replace it with self. It is way more practical than typing the same name over and over again. Tongue sticking out

Why can't you call them in any other way? Happy with a sweat

That is because the method has become what we call a singleton method. Only a single instance will get access to the data it contains at any given moment. What instance? The module or class itself!

HEY! That's not true! Shocked

Huh? Huh? What do you mean by that?

I've seen it used in other circumstances and it's not referring to the module or class at all. Angry

Oops! Oh, you mean those instances like self.contents and self.bitmap found in window scripts.

For starters, yeah... Sarcasm

Grinning Don't worry about it! That is easy to explain indeed.

What happened there is that some of those calls are seeking hidden methods, those written in C or C++, and there is no other way to access them or else they could be treated as simple local variables.

Code:
self.contents.font.size = 32

In this example, the use of self is optional. Just use contents and it will work fine.

Confused Is there any difference between using one option or the other?

Happy with a sweat You got me here. Yes, there is one!
What takes place there is that contents alone forces Ruby Ruby to look for any instance of either a local variable OR a method called contents. While self.contents already informs the interpreter that you are looking for a method, be it a class or instance method. (Class methods are singletons by default.)

Sarcasm + Confused But there is a catch! There is always a catch! Confused

Code:
contents = Bitmap.new(32, 32)
self.contents = Bitmap.new(32, 32)

The first call would just create a local variable that will cease to exist the moment that method finishes its execution. The latter is ye old and trustworthy self.contents assignment method and it will keep the Bitmap object stored there for future references.

This is What Actually Made Me Write This Review!

There is a caveat that we scripters should know about just in case we still ignored it for any reason.

What happens very often in RGSS1, namely on RMXP, during battle is a very unusual phenomenon in Ruby Ruby scripting. This is one of the very few places where this has ever happened in decades.

classes like Game_Battler make several references to methods like self.damage instead of using @damage directly.

Why does this ever happen? Detective 

Well, Happy with a sweat I guess that scripters were not fully aware of how @instance variables were supposed to be used in a script. Thus, what I mean here is that they did something totally weird by calling self.damage instead of simply typing @damage whenever they want to calculate the actual damage or healing any given Game_Actor or Game_Enemy is about to receive at any moment.

Look Up But is it something really bad at all?

Hrm, I suppose Thinking that depends on what you want to accomplish there. Laughing

If you are planning to pre-calculate some basic damage, that might be helpful indeed. Shocked
Indifferent Otherwise using a plain @damage instance variable would suffice there, letting you to hit that bad mobster Ghost as hard as you can. Shocked Go for it, Arshes!

Other implementations like RGSS3 actually provides us with calls to methods in place of variables to let you calculate base prices, for instance. Winking And nope, they do not use the self pseudo variable at all.
Indifferent They may or may not have the same name as the actual variable that is going to be used there.
Happy with a sweat You see, once you choose to use a method there, you are free to name it they way you prefer to your heart's content. Winking
And anybody can later alias the method at will. Grinning

The Conclusion

Headache This is one of those cases where there is no way to get quite conclusive about what you are supposed to do now because people can tell you at a certain point that it is a matter of style or taste. Eating Hamburger
And they might be right about that Tongue sticking out no matter how weird that might sound like. Laughing

RE: Ruby Scripting - kyonides - 11-18-2023

Moronic Design: Ruby & The Embedded Methods

Months ago there was a discussion on a topic that made some people not used to Ruby's nuances pretty mad indeed. The topic at hand was defining a method inside another method, pretty much embedding it without caring about the consequences of such a poor design. I heavily critized it because it will never ever make any sense in Ruby Ruby nor RGSS any version at all.

Now I am going to cover that here to let you know what actually happens when you try to imitate one of the effects, namely treating Ruby's methods as JavaScript's functions thinking they both are first class citizens in their respective programming languages.

The results might heavily disappoint some of you for not reflecting your wishes or fears as accurately as it was expected. Actually, the outcome is quite predictable while still retaining its nonsensical nature intact. Happy with a sweat

Conclusions:

  1. Ruby has NEVER treated its methods as objects that can be easily and perfectly defined pretty much anywhere in your code like JavaScript functions do in later iterations of the RM engine.
  2. The contents of embedded methods will not be accessible from within the "parent" method. They will just get defined as usual and will belong to that instance of the class, aka the current object, only and not to the fake parent method.
  3. Ruby will parse and (re)define that weird internal method will take place every single time you call the so called parent method. (Ruby will only keep a reference to the last definition of a method. Here it will only replace the previous definition over and over again.)
  4. There is no way you can make Ruby get in trouble by making a large chain of methods the way it allows you to chain constants in a weird mix of module / class & constant list kept together as a single but large script call that has no theoretical end as far as we scripters know.
  5. There is no way we can ever get something meaningful and useful out of making this terrible mistake.

The Proof

We need to come up with some test code to make sure we can prove what I have exposed above as the only valid conclusions I could come up with after running it several times in a row.

So here it is!

Sample Code

Code:
class A
  def hello
    print "Hello!"
    def bye
      print "Bye!"
    end
  end
end

Now let us run it by pasting the following snippet right on a Editor script section located before the Main script and lets launch the game after saving our changes to the script editor.

Test Code

Code:
print a = A.new
print a.hello
begin
  print a.hello.bye
rescue
  print "Failed to execute a.hello.bye"
end
a.bye
a.hello
a.bye
a.hello

Side Note:

If you print both the a.hello or a.bye calls, you will not get any error messages. Even so, removing the print call like I did in the code above can make you throw an error for relying on a rescue call inside an IRB binding. What this means is that a console window running the Ruby interpreter is not supposed to execute such a rescue statement. Confused This is true for the 2.7 release at least.

Inline rescue calls work normally even while running the IRB on a console window aka shell.

What we are going to do now is test it on vanilla RMXP (or VX or ACE if you prefer) and also on HiddenChest game engine and just see what happens then. Thinking Will both engines return the same results?

Ruby 1.8's Output - vanilla RGSS1

Code:
#<A:0x41a3481>
Hello!
nil
Hello!
Failed to execute a.hello.bye
Bye!
nil
Hello!
nil
Bye!
nil
Hello!
nil

What we should notice after reading the output above is that whenever a method gets defined, meaning being parsed and evaluated first, it will always return a nil object as its normal outcome.

Ruby 2.7's Output - HiddenChest

Code:
#<A:0x00007f1d4cf54810>
Hello!
bye
Hello!
Failed to execute a.hello.bye
Bye!

Hello!
bye
Bye!

Hello!
bye

OK, this is very similar to the first output, except that Ruby 2.7 returns a :bye symbol after defining any given method. For some reason still unknown to your servitor, it doesn't return anything readable after printing the bye method's return value.

Note:
After other people also ran the code and reviewing the default implementation of Ruby called either MRI or YARV depending on the version, using two consecutive print calls like I originally did will return a nil value or a whitespace accordingly.

In both cases you can either get a bye string representing the method's name by calling the usual print function or the actual :bye "symbol" (actually a string that keeps its typical colon at the beginning) if you call the p function instead.

RE: Ruby Scripting - kyonides - 04-16-2024

Using or Abusing of Game Logic:
The Perfect Excuse for Covering a Clear Case of Friendly Fire

Normally, we wouldn't combine a game skill or plot to cover a sinister plot that involves a casualty caused by some friendly fire.
Why would anybody ever do that, right? Confused

Yet, somebody unintentionally managed to come up with the perfect scenario where the heroic Orson Ghim Slayne platoon can no longer blame anybody else, like a devious Wizard foe, for hurting them. Why? I'll tell you why in a moment.

Code:
$game_party.members.each do |mem|
  item = $data_skills[80]
  mem.item_apply(mem, item)
end

That code above lets you apply a skill as an item, because that's how VX ACE implemented both of them, on a given target. In this case the target is a hero, starting from the party leader Orson himself.

This is the first quake alarm that should shake us like crazy... if we ever care about these petty details, that is. Laughing

IF you pay close attention Detective to that seemingly innocent piece of code, it has a serious flaw. A logical one indeed.

You see, both the actual attacker and its victim is... the same guy! The hero himself! Incredible 
So now they all can claim that they were hit by an ally! Shocked
That's what we'd call an extreme but also laughable instance of friendly fire taking place under the hood. Laughing

How do I know that? Thinking
That's an easy one, guys! Tongue sticking out 
I know that because both the attacker and the target are the same mem or party member Shocked in that specific order.

What Actually Happens There

Let's say your skill is physical by definition. That would mean that Wizard Slayne mages who normally have high MATK stats but not ATK ones could be seriously hurt by a warrior's skill while fighters like Orson Orson wouldn't. If it's magical by nature and cast by a Wizard mage, then Orson Orson with high DEF or PDEF but not MDEF would be the first casualty here.
Winking Of course, this might not take place if they also have high DEF / PDEF or MDEF stats.

Of course, if you simply don't mind Indifferent about these technicalities, well, you're good to go! Two Thumbs Up!  Laughing

My Suggestion

You better pick an enemy from the database to cast the spell instead.
And yes, it's that simple. Winking

NOTES

Here the caster or attacker must be a Game_Battler or one of its child classes like Game_Enemy.
item doesn't need to be redefined every single time you pick another hero.

Code:
caster = Game_Enemy.new(0, 1) # Enemy ID is 1 here
item = $data_skills[80]
$game_party.members.each do |member|
  member.item_apply(caster, item)
end

It doesn't have to be enemy #1 Ghost, obviously. Happy with a sweat
Keep in mind that now your heroes would no longer need to Worried worry about not cleaning their guns properly following all local regulations. Laughing

RE: Ruby Scripting - kyonides - 12-21-2024

Revisiting Strings & Symbols

Not long ago, a furry Wulfo noticed something about using strings and symbols in Ruby, either by running a vanilla RMXP game or my own custom engine HiddenChest. Without further delay, let's read his comments thoroughly.

Some Wulfo Once Said

Honestly, that's old news to me. Tongue sticking out

And there's something I'd really like to add to his remarks there. Adding the condition to not convert a string into a string if it's already a string object is quite Mad Scientist weird, to say the least.

"string".to_s by itself will simply return self, this means it will return "string" after processing that line. It won't transform anything. Instead, it will return its default value, the string itself!! Shocked

I suspect this change might have happened in Ruby version 1.9 or later.

Based on old comments online, it seems that the Ruby on Rails aka Rails community and base code pushed Ruby core developers into implementing more and more symbols in the default MRI code to reduce the amount of unfrozen strings that needed to be frozen at runtime.

The Advantage of Relying on Symbols Not Strings

Symbols are unique by definition. Once created, there'll be just a single copy of it for the rest of the code's execution. This is great if you need unique identifiers for very specific things in your custom script. I can give you my Terms module script as an example. By using a single language symbol like :eng or :deu or :spa you can make many different arrays or hashes of strings quickly change your game's graphical user interface or GUI in no time. You'd only need to change a single instance variable in Terms module and you're done! Grinning

Happy with a sweat Fine, you'd also need to refresh your windows or sprites right away or you'd never notice any changes on TV screen.

RE: Ruby Scripting - kyonides - 03-24-2025

Effects of Relying on a Bad Explanation:
Getters, Setters & Wrapper Methods

When someone else was explaining how the getter and setter methods work in Ruby, the next thing this guy mentioned was that they were some sort of wrapper methods created around the corresponding variables to let the program access them. Later on you could also read that it limit the circumstances under which the variables can be altered by mistake, but is that true?

I've got some sad news for all those people that once thought it was true. No, that's not how it works and it doesn't prevent you from changing the value at any inconvenient moment and those methods can be accessed from ANYWHERE at ANY GIVEN TIME.

Thus, some var=(val) method isn't a wrapper of @some, it's its actual setter method. It simply was manually created instead of using Module's attr_writter shortcut. Even if the setter included a conditional statement, it'd remain as a setter.

If you don't want any scene or window or sprite to be able to alter those variables, then don't define their setter methods. Tongue sticking out
Thinking Well, you could add a condition either in the line of code where you need to alter them externally OR add a condition inside the setter method to prevent it from ever being a nil value or a negative number or anything the like.

Is it a good idea of calling a manually defined getter or setter method a wrapper?

Nope, it isn't. It'd be quite terrible for setters. You better reserve that term for other instances where you'll definitely need it.

It'd be a wrapper method in Ruby IF:
  • It had another name or a different number of arguments like set_vars(a, b)
  • It's a custom spriteset class that lets you change all of its sprites' visibility state with a visible=(bool) method.
  • The Game_Party#add_actor method that will limit the number of heroes that can join our party in the RM engine.
  • Of course, there might be other ways to create wrappers that I haven't mentioned here like Game_Actors class being a wrapper class for a @data Array object that contains Game_Actor objects, i.e. $game_actors[1] calls the Game_Actors#[](index) method that internally returns the value of @data[index] or creates a brand new Game_Actor object.

Is there a way to easily prove that those getters and setters don't behave like mere wrappers?

Yes, there is! Let's use a simple test code.

Code:
class Person
  def initialize
    @age = 1
  end

  def age
    print "Current age #{@age}\n"
    @age
  end

  def age=(new_age)
    print "Altering your age now!\n"
    @age = new_age
  end
  attr_reader :age
  attr_writer :age
  # Or just call this instead: attr_accessor :age
end

The code above would define 2 methods for the same @age variable, its getter and its setter in that specific order. They are supposed to print something on screen on both RMXP and RMVX. In RMVX ACE it would require you to open the console window first.

But there's a catch! Shocked By calling the attr_reader and attr_writer methods, or simply the attr_accessor method, we have overwritten the getter and the setter we had manually created for the @age variable.

What that means is that now we won't ever be able to print anything on the popup window or the console window depending on which RM engine you're using.

Happy with a sweat OK, you still can #comment out the attr_ lines to be able to read those strings as first intended.

NOTE

I have added the initialize method to the Person class to make sure that the @age variable will never return a nil value, which is the default return value of any variable that has not been assigned a different value at some point.


Other Ways to Deal With It

Later on Dog Wulfo showed some interest in adding some alternate code to let people handle the return of a nil value in a different way, especially if I had not defined the initialize method there.

The code I had proposed would look like this then:

Code:
class Person
  def age
    print "Current age #{@age}\n"
    @age ||= 1
  end

  def age=(new_age)
    print "Altering your age now!\n"
    @age = new_age
  end
  attr_reader :age
  attr_writer :age
  # Or just call this instead: attr_accessor :age
end

What does that altered line of code do there?

Well, it's pretty simple indeed. If the @age has not been predefined, it will pick 1 as its default value. If at some point the value of @age has been altered, let's say that now it's 15, it will ignore 1 and return 15 instead.

Confused Why? Because it's no longer equal to nil. Only nil values would get replaced using the ||= operator.

Yet, don't forget that the attr_ methods are still in use so they won't ever print anything on a popup window or the console window if any.

If it were able to print anything, you'll soon notice that the age getter method would print a nil (an empty string "") instead of a number as its current age. Sad

Is that the only way we could have done it?

Tongue sticking out Nope, there's yet another way to deal with it, but it's not as efficient as using the ||= operator there.

Grinning Here's the code that Dog Wulfo had suggested a while ago. It presupposes that there has been no attempt to define the initialize method so far.

Code:
class Person
  def age
    @age = 1 if @age.nil?
    print "Current age #{@age}\n"
    @age
  end

  def age=(new_age)
    print "Altering your age now!\n"
    @age = new_age
  end
  attr_reader :age
  attr_writer :age
  # Or just call this instead: attr_accessor :age
end

As you can see, the interpreter would have to always make the check in a separate line before printing the @age variable via print and then returning the value of @age... IF the attr_reader or attr_writer or attr_accessor methods had not been used there or had been #commented out.

You shouldn't underestimate that piece of code. It does work as intended, but the ||= operator makes it easy to skip it.

Nonetheless, there's a caveat! Shocked

The ||= operator won't let you preassign the value before printing the previous value of @age. Confused So it does have a downside after all.

RE: Ruby Scripting - kyonides - 03-30-2025

Your Verbose Code Might Be Wasting Your Computing Time!

The present post will consist of an actual request that asked any scripter to alter the default actors' behavior in VX ACE in battle.

The Default Behavior & Its Actual Code

Actors' actions are based on AGI just like it happens to enemies.

Code:
module BattleManager
  def self.make_action_orders
    @action_battlers = []
    @action_battlers += $game_party.members unless @surprise
    @action_battlers += $game_troop.members unless @preemptive
    @action_battlers.each {|battler| battler.make_speed }
    @action_battlers.sort! {|a,b| b.speed - a.speed }
  end
end

What the maker does is to create an array of battlers before adding the party members and the enemy troopers depending on the battle start type: normal, surprise or preemptive. Then it sorts them all based on their actions's lowest speed. (It uses the battler's AGI and perhaps the ATK speed as well.)

The Desired Behavior

Actors' actions order should be based on their party index instead.
Enemy actions would remain unaltered.

The Solution Originally Posted by Another Scripter

Code:
module BattleManager
  def self.make_action_orders
    @action_battlers = []
    party_battlers = []
    troop_battlers = []
    party_battlers += $game_party.members unless @surprise
    troop_battlers += $game_troop.members unless @preemptive
    troop_battlers.each {|battler| battler.make_speed }
    troop_battlers.sort! {|a,b| b.speed - a.speed }
    @action_battlers += party_battlers
    @action_battlers += troop_battlers
  end
end

By just looking at the code, any experienced scripter would soon notice that the OP has replaced 3 lines of code with 7 custom ones. These lines are very slight variations of the original code.

First, let's mention the merits this scriptlet has. It's quite readable, methodical, and it works as intended.

The downside is that it's not as concise as it should be. It doesn't show any signs of it being a slightly creative solution. So it's just a simple one.

NOTE: For some reason the actors ALWAYS go first, even if no one had asked for this feature at all.

Can that piece of code be shortened somehow?

The answer is yes, it can! Grinning And it's extremely easy to implement for sure!

The Compact Code I'm Proposing

Code:
module BattleManager
  def self.make_action_orders
    @action_battlers = @surprise ? [] : $game_party.members
    troop_battlers = @preemptive ? [] : $game_troop.members
    troop_battlers.each {|battler| battler.make_speed }
    troop_battlers.sort! {|a,b| b.speed - a.speed }
    @action_battlers += troop_battlers
  end
end

The method's first line already assigns the party members to the battlers' actions array. It's followed by a similar array focused on the enemies only. Both check if there's a flag that might exclude them from being processed while sorting the actions. Then let's say it has found some enemies and the next 2 lines proceed to find the actions and sort them by their corresponding speed as usual. Finally, it just add the sorted array of troopers to the original list of battlers.

OK, this scriptlet is no longer as newcomer-friendly as the previous one for sure, yet, it handles the creation of arrays or assignment of existing ones to the @action_battlers array without packing too much stuff inside that method. And it doesn't create arrays that are quite similar nor does it imitate other arrays' behaviors or method calls unnecessarily.

NOTE: Actors STILL go first. Enemies will also have to wait for the party to finish attacking them before they launch their counterattack.

Stop Assuming You Know All About How the Requestor Wants to Alter a Given Feature

What would happen if one day the original requestor, an average forumer, finally realizes that your code grants the actors an inexcusable advantage over their enemies?

If that ever happens, you'd be forced to refactor your code to take that situation into account from that point onwards.

How could we solve that issue?

Well, we could alter the original code to include a way to easily check who should go first.

In this particular case we'll assume the change will be PERMANENT and should be defined before the game loads.

Now let's take a look at this code:

Code:
module BattleManager
  PARTY_GOES_FIRST = true
  def self.find_party_battlers
    @surprise ? [] : $game_party.members
  end

  def self.find_enemy_battlers
    @preemptive ? [] : $game_troop.members
  end

  def self.make_action_orders
    if PARTY_GOES_FIRST
      battlers = find_party_battlers
      other_battlers = find_enemy_battlers
    else
      battlers = find_enemy_battlers
      other_battlers = find_party_battlers
    end
    other_battlers.each {|battler| battler.make_speed }
    other_battlers.sort! {|a,b| b.speed - a.speed }
    @action_battlers = battlers + other_battlers
  end
end

There are 4 changes applied to the scriptlet that allows the game developer to predefine the team that will attack first.
  • We use a CONSTANT that will hold a boolean value.
  • We encapsulate the ternary conditions so we can easily call them from the make_action_orders method in any order.
  • We define a conditional if statement using our custom constant as the actual test.
    Adding == true to the condition is optional in Ruby for any existing object is true except for false and nil objects. Even 0 is true...
  • @action_battlers concatenates the preferred team and the remaining one in that particular order.

NOTE: Here I let you treat the other battlers as the ones that will be sorted by their actions' speed. If that's not what you want to implement, rename the lines that alter other_battlers as battlers. Now it will only sort the first group by their party or enemy indexes.

Thoughts on Refactoring [Pieces of] Code

Normally, we wouldn't touch a functional scriptlet and modify it just to make it compact, but the original code gave me the perfect excuse to do so here. The thing is that a scripter should get to a development stage where he or she should be able to realize on his or her own that they gotta be more ways to deal with an issue than just sticking to the engine or its scripts' default features or coding style.

The usual reasons to revisit a script might be stuff like adding or removing features, fixing bugs, renaming methods because their current names are misleading or have been repurposed, adding exceptions or conditional statements to prevent happy-go-lucky aficionados or some happy-trigger apprentices from triggering events or script calls at a bad moment, etc.

One special circumstance when you might want to change your code would be to get rid of nested loops like defining a for loop inside another one. The only exception to this rule might be nesting 3 for or each loops to iterate over all tiles in the X, Y and Z layers in the RM series. Happy with a sweat You can't really find a way to avoid that process, you're simply forced to do that to get the tileset working as intended. Laughing