RGSS scripting dissections and explinations

[kyonides]

Advanced Section

If dealing with module, it is part of metaprogramming, and it tells Ruby to insert methods (defs), like coins in a vending machine, in the module as if they were the module's own methods. It means all defs inside class << self till the last end will only belong to the module and nobody else. If you wanna get them, you gotta call the module first: Puma.scratch_siletrea
It's a way to set its exclusivity or sole ownership or only owner. Those methods won't belong to Game_Actor nor @puma_bakery nor anybody else. You use it mainly if you wanna change a module's method that already exists.

Simple Section

In arrays that is almost the same as push, you are actually pushing stuff inside the array like bullets in a gun or citton in a teddy bear. The difference between push and << is the way you use any specific vending machine.

push: The vending machine is slow and you insert a coin or bill and need to wait for confirmation before you can insert a new coin or bill. It is like a machine yelling at you to give it a break before you can insert another coin.

<< : The vending machine realizes you are inserting coins or bills one after another, it will quickly update the result without yelling at you that you should stop for a moment, and will also confirm the result after you stop inserting coins.

Edited for clarification.

[Siletrea]

ok...so ":" is slow and needs constant confirmations while "<<" examines everything as it goes through and figures it out when your done?

the vending machine example is pretty good btw

[kyonides]

In the first simple example it's push not :

<< will quickly confirm it without stopping you from inserting coins.

I updated the previous explanation as well.

[DerVVulfman]

Instance @ accesses everything within its script andor scripts connected with Pac-Man<

Almost.    Not everything within its script.  Only everything within its class.

But it CAN be accessed by other classes if some special commands are added.  An example of an instance variable being accessed from another script would be like $game_temp.battle_calling scene within the "call_battle' method in Scene_Map.  That statement is accessing the 'battle_calling' instance variable in the Game_Temp class.

But accessing instance variables or commands from other classes is another subject.

---

I love horizontal rule...

Now I take it that you have seen some methods that have parenthesis after their names, methods in the default scripts like this one from Window_Base:

Code:

 #--------------------------------------------------------------------------
 # * Draw Graphic
 #     actor : actor
 #     x     : draw spot x-coordinate
 #     y     : draw spot y-coordinate
 #--------------------------------------------------------------------------
 def draw_actor_graphic(actor, x, y)
   bitmap = RPG::Cache.character(actor.character_name, actor.character_hue)
   cw = bitmap.width / 4
   ch = bitmap.height / 4
   src_rect = Rect.new(0, 0, cw, ch)
   self.contents.blt(x - cw / 2, y - ch, bitmap, src_rect)
 end

Well, you have TWO different names you can use to describe these variables.  You can call them Parameters or you can call them Arguments.  And in the above example's case, you have three arguments:  an actor variable, an x variable and a y variable.  They will generally act as local variables for this method and are immediately put to use.

I'm not going to describe all the stuff in this method.   HECK no.   Not going after graphic manipulation, caches or stuff quite yet.  Instead, I want to discuss something else....  The super() statement that I've been talking about.

Have you noticed that I've talked about it having those parenthesis????  

The super statement may or may not have parenthesis.  But if it does, it might ALSO have arguments thrown in the mix.  For those making a window, here is an example of the super statement with parameters thrown in... from the Window_Help class:

Code:

#==============================================================================
# ** Window_Help
#------------------------------------------------------------------------------
#  This window shows skill and item explanations along with actor status.
#==============================================================================

class Window_Help < Window_Base
 #--------------------------------------------------------------------------
 # * Object Initialization
 #--------------------------------------------------------------------------
 def initialize
   super(0, 0, 640, 64)
   self.contents = Bitmap.new(width - 32, height - 32)
 end

Now you notice that this time the super statement reads:  super(0, 0, 640, 64).  And this Window_Help class is a child of the Window_Base class.   So, it appears that we're copying and using the initialize method from Window_Base, right?   Here's the Window_Base.....

Code:

#==============================================================================
# ** Window_Base
#------------------------------------------------------------------------------
#  This class is for all in-game windows.
#==============================================================================

class Window_Base < Window
 #--------------------------------------------------------------------------
 # * Object Initialization
 #     x      : window x-coordinate
 #     y      : window y-coordinate
 #     width  : window width
 #     height : window height
 #--------------------------------------------------------------------------
 def initialize(x, y, width, height)
   super()
   @windowskin_name = $game_system.windowskin_name
   self.windowskin = RPG::Cache.windowskin(@windowskin_name)
   self.x = x
   self.y = y
   self.width = width
   self.height = height
   self.z = 100
 end

Yes, Window_Base has a super of its own... it's a child of the hidden Window class

This initialize method in Window_Base has four parameters/arguments:  x, y, width and height.    So when we threw in the command of adsf, we basically told Window_Base to use those four values like so...

@windowskin_name = $game_system.windowskin_name
self.windowskin = RPG::Cache.windowskin(@windowskin_name)
self.x = 0
self.y = 0
self.width = 640
self.height = 64
self.z = 100

Yep.  It just filled in the BLANKS.

Now that's what it is like if you have a super statement with parameters.  It MUST be duplicating a method with an equal number of parameters.

If you are using a super  statement with no parenthesis at all, you must be duplicating a method from a parent class that has no arguments or parameters of its own.   The update method within Window_Selectable has a super statement that has no parenthesis and no arguments.  But that is because it is copying the update method from Window_Base, its Parent class.  And the update method in Window_Base has no arguments.   Both match!!!!

Now as to super() statements.... a super statement that DOES have parenthesis but no arguments in it....  This is a weird case, and might be easier to see visually.  Here's an example of the initialize method in Game_Actor:

Code:

 #--------------------------------------------------------------------------
 # * Object Initialization
 #     actor_id : actor ID
 #--------------------------------------------------------------------------
 def initialize(actor_id)
   super()
   setup(actor_id)
 end

This initialize method has a parameter:  actor_id.   This method basically CREATES YOUR ACTOR, but you gotta supply the actor's ID from the database.... the actor_id value.  However, it has a super() statement.  Hrm....

Now, the Game_Actor class is a child of the Game_Battler class.  So it is copying the initialize method from its initialize method.  Hold up, lookie here!!!

Code:

 #--------------------------------------------------------------------------
 # * Object Initialization
 #--------------------------------------------------------------------------
 def initialize
   @battler_name = ""
   @battler_hue = 0
   @hp = 0
   @sp = 0
   @states = []
   @states_turn = {}
   @maxhp_plus = 0

THE INITIALIZE METHOD IN GAME BATTLER DOESN'T HAVE ANY ARGUMENTS OR PARAMETERS!!!!    

So the super() command is used when the method you're creating does have a parameter, but the one it is copying doesn't.

Any questions?  Comments?  Pastry?



.

[kyonides]

Code:

class SomeIdioticSampleClass
  def a_moronic_method
    @any_instance_variable = any_value
    @just_another_instance_variable * 2
  end
  def just_another_instance_variable
    @just_another_instance_variable
  end
  def just_another_instance_variable=(new_value)
    @just_another_instance_variable = new_value
  end
end

In that excessively stupid example, I made it look idiotic on purpose, you can see two kinds of methods or "defs". The first method processes stuff like a computer would do it in the 50's or 60's while the second method is just a getter (method).

Getter or something that lets you get some instance variable, is like a store you don't own where you are allowed to purchase food or autoparts or tools but you can't sell them anything back.

A setter (method) like the third def above would be comparable to a store like DerVVulfman's pawn shop where you can sell them stuff if they find it worth buying it from you, a total stranger that rarely pay them a visit. (Well, you're Canadian, you're not supposed to walk around Maryland every single day of the year. ) The stranger would be any other class script, either you, MetalRenard, Kirito, LunarBerry, Nyakuya, etc. Anybody would be allowed to set any specific price to their product and try to sell it there. (Just skip the haggling part of the business here. )

An accessor in Ruby, a getter-setter combo, would be like Wulfo's shop but you would not only try to sell them stuff but also look for any interesting item like a guitar, a sword or a bow you might wanna buy for your personal collection.

SIDENOTES

As a sidenote I gotta admit that talking about super method is a BAD idea if a newbie is involved for super is one of Ruby's strangest exceptions to its rules. Let's say it's the only method that under certain circumstances might require to get a pair of () parentheses while no other method in Ruby actually needs them. (A lot of internal history of Ruby development is also involved here...)

Now that's what it is like if you have a super statement with parameters. It MUST be duplicating a method with an equal number of parameters.

Well, usually he would be right, BUT there is an exception in RGSS 1 and later versions (XP and later versions of the maker). If the last parameter of a child class's method is an array described as *array, then it might only look like it had the same number of arguments in both the child and parent class in the class scripts themselves (their defs). Sadly a call to those methods, using Class.method(argument1, argument2, argument3, argument4, etcera), might apparently have many more arguments or parameters or passed down values than those found in the defs where they were defined initially. WHY? Because the last *array parameter is like a large net waiting for some extra fish to catch than the amount the government would normally allow a single boat to catch in the sea. In the Class.method case etcera would be that special net's first victim.

In default scripts like Window_Base and so on you won't find such eccentricities or definitely crazy stuff at all, but I warn you it might happen a little bit more often in custom scripts.

By the way, super without () parentheses is not an innocent baby after all. It actually passes from 0 up to 17 arguments or passed down values to its parent class. Why zero as first possibility or option? Go ask Ruby's creator! The developers' team preferred to let you pass "nothing" as well in case the parent class did not need any parameter at all.

If you create your custom window class like I did here:

Code:

class MySharkyWindow < Window_Base
  def initialize(x, y, width, height)
    super
    self.z = 1000
    self.bitmap = Bitmap.new(width - 32, height - 32)
    self.bitmap.draw_text(0, 0, width - 32, 24, "I'm a shark with a laser gun!")
  end
end

You're passing down all four parameters to Window_Base, it's parent class. Yeah, Ruby let's you be quite lazy and skip the urge to specify what parameters the child class needs to pass down to its parent class. super is a perfect complement for lazy people!

[DerVVulfman]

You're passing down all four parameters to Window_Base, it's parent class. Yeah, Ruby let's you be quite lazy and skip the urge to specify what parameters the child class needs to pass down to its parent class. super is a perfect complement for lazy people!

True that. Ruby lets you be lazy. Under other computer languages, you would have to actually specify that X is an Integer, Y is an Integer, and whatnot. Fun Fun fun.... Heck, even Visual Basic required that you tell it what type of variable you were using!

There are other arguments you can put in as parameters. But I'm leaving *args and optionals arguments for later discussion.

In the meantime, study what we said about the super statement, and give a good reply with possibly some examples. It's always good to see how much you're grasping.

[Siletrea]

$ Global accesses anything anywhere thoughout multiple scripts but its sloppy and not really used too much

@ instance is used to call things from anywhere within its own script regardless of where it is

> pacman acts like a tree and allow one to connect scripts together to prevent rewriting

< ms pacman....I have no idea

if starts a conditional branch! example... if cat is grey then it does something like open a box and if its not it wont do anything unless you use "else" then you can specify what happens if the "if" doesent happen...OR theres "elseif" which makes the condictional branching alot bigger adding more options!

modules...I think theyre a way of labeling certain areas of your scripts...like making a box to put stuff in and having the name be there to organize it?

classes work inside the modules...like the stuff put in the box?

methods...are everything you do in scripting?

I'm going from memory feel free to correct

[kyonides]

< ms pacman acts like a tree and allow one to connect scripts together to prevent rewriting

Not entirely true, you can still rewrite whatever you like, including the parent class's methods if needed, but it's not mandatory. It's one of the first baby steps required in the encapsulation land of the Object Oriented Programming OOP world. Think encapsulation is just like catching a script with a pokeball! The pokeball is a convenient container not for a pokemon here but for a script. So < ms pacman tells the script manager (Ruby + RGSS) to go find another pokeball, the parent class. Like a Matroshka or matrioshka doll.

modules...I think theyre a way of labeling certain areas of your scripts...like making a box to put stuff in and having the name be there to organize it?

It's another sign of the existence of encapsulation in a script, and yeah, it does contain it as a basket with a specific label.

Classes can work inside and outside a module, it's up to you if you find it convenient to place it inside the module or not. It's a matter of taste or sense of order.

> What you called "pacman" is only used in mathematical operations like x > y where x is a number that is supposed to be greater than y like 3 > 2. I don't recall any example where you could use it in any other circumstance (if talking about RMXP).

Methods are... like what you find in a basket, let's say, lots of cola cans or chip bags or anything packed with paper or plastic. Their contents would be the method code.

[DerVVulfman]

Sleepy SIletrea? XD Really?

@ instance is used to call things from anywhere within its own script regardless of where it is

*BRZZZZ!!!* Not exactly. "It s a variable to use from anywhere in its 'CLASS'." That is, unless you use special commands to access them... but that hasn't been covered yet.

I could make a script that has contains both Game_Siletrea class and a Scene_Siletrea class. If I make a @misha variable within Game_Siletrea, that variable is unique to Game_Siletrea. I could make a similar @misha variable in Scene_Siletrea.

Now that doesn't mean I can't let some other class read the @misha value used by Game_Siletrea..... I 'CAN!!!!' WOOO! But I gotta throw in one of TWO statements: either attr_reader or attr_accessor. The 'reader' version lets the value be read from another class... but only read from it. The 'accessor' version lets you access the value for reading and writing.

Code:

class Game_Siletrea
  def initialize
    @misha = "cat"
  end
end

class Scene_Siletrea
  def main
    @misha = "is a cat"
    (other stuff)
  end
end

.... the @misha value from Game_Siletrea can only be used in Game_Siletrea

Code:

class Game_Siletrea
  attr_reader :misha
  def initialize
    @misha = "cat"
  end
end

class Scene_Siletrea
  def main
    @misha = $game_siletrea.misha
    (other stuff)
  end
end

.... the @misha value from Game_Siletrea can be read 'BY' Scene_Siletrea.

Code:

class Game_Siletrea
  attr_accessor :misha
  def initialize
    @misha = "cat"
  end
end

class Scene_Siletrea
  def main
    @misha = "Can Dance"
    $game_siletrea.misha = "Is a Dance Dance Revolution champ!"
    (other stuff)
  end
end

.... the @misha value from Game_Siletrea can now be changed from another class....!

There's a bit more too it than just this. We need to do stuff that lets that whole '$game_siletrea' thingie to work. But once we do, this is how you can make @instance variables from one class work within other classes.

Okay, Now refresh us on what you learned about Classes, Parent Classes, Child Classes and Supers. And what did you learn about local variables and parameters, the last thing I was discussing....

[kyonides]

Well, naming a scene after a person is not a good idea since it won't describe what the scene will do if you call it... What about you making a scene like this?

First we create a few objects that represent real life stuff.

Code:

class LivingBeing
  attr_accessor :name, :age
end

Code:

class Person < LivingBeing
  attr_reader :pets # only gets @pets value (an Array or basket for all of the pets)
  def initialize
    @name = ""
    @age = 0
    @pets = [] # The basket you bought for your kittens!
  end
end

Code:

class Pet < LivingBeing
  attr_accessor :attitude # gets and sets @attitude 's value (a string, a text, a label)
  def initialize
    @name = ""
    @age = 0
    @attitude = ""
  end
end

Here comes the scene itself!

Code:

class Scene_PetConvention # Everything takes place in a Pet Convention!
  def main # Everything that happens once the convention has started
    siletrea = Person.new # you're a person, aren't you? O_o?
    siletrea.name = "Siletrea" # you've got a name of your own
    siletrea.age = 22 # Guessing here...
    @puma = Pet.new # setting up a specific pet object representing... Puma!
    @puma.name = "Puma"
    @puma.age = 10 # Guessing here...
    @puma.attitude = "aggressive" # yeah, the poor cat girl is a claw-happy kitten
    siletrea.pets << @puma # you placed all of your pets in a basket or anything like that
    dervvulfman = Person.new
    dervvulfman.name = "DerVVulfman"
    dervvulfman.age = 60
    @patches = Pet.new
    @patches.name = "Patches"
    @patches.age = 12
    @patches.attitude = "spoiled" # yeah, he spoils all of his cats :P
    dervvulfman.pets << @patches
    @owners = [siletrea, dervvulfman] # Now both of you are partaking in the contest!
    Graphics.transition # The announcer lets the owners and their pets come in
    loop do # The contest is being broadcasted!
      Graphics.update # Like a video, it needs to scan the surroundings every so often, like every second
      Input.update # Whatever people say or a poll to collect people's votes
      update # Define what you want the audience or the organizers or the judges or the pets do during the contest
      break if $scene != self # If show is over, let the announcer tell who was the winner pet
    end # End of the broadcast
    Graphics.freeze # Last picture taken with any cam or cellphone
    @owners.clear # dispose of anything related to the owners
  end

  def update
    # The contest takes place here in this case... Any changes should go here
  end
end

Keep in mind # or pound symbol or hash symbol or whatever you wanna call it, turns anything behind it into a comment in Ruby, and Ruby ignores comments!

Edit: I also had to correct my previous reply because I misread a couple of little mistakes you made like mixing the roles > ms pacman and < pacman have in scripts. (So > is no longer reverse pacman? You made it sound like the evil Inverse Flash back then. )