RGSS scripting dissections and explinations

[kyonides]

I was talking about Evil Pod Pod not ordinary Pod Pod

The following is based on a method you may find in my KWork module, part of my KWorkshop XP Kustom Version script.

Code:

def lift_equip_curse(caster, level, thing)
    return if thing == nil
    thing.cursed = cursed = case caster
    when :priest, :clerigo then thing.curse_level > level
    when :smith, :herrero then thing.curse_level + 1 > level
    when :tech, :tecnico then thing.curse_level + 2 > level
    end
    return !cursed
  end

lift_equip_curse is a module specific method so you can only call it by mentioning its owner, the KWork module.

KWork.lift_equip_curse

As it is it should pop up an error message because that methods asks for 3 kind of specific arguments or values or stuff to put in.

KWork.lift_equip_curse(caster, level, thing)

What are caster, level and thing? Well, they're variables it needs to receive to lift a curse found either on a weapon or armor, that's what thing is doing there, to represent a weapon or armor. Then caster would be a symbol, those that start with colon : like :priest or :smith or :tech, and level would be some integer number (1, 2, 3 or any other you can think off).

return if thing == nil

It will make the KWork module stop processing the lift curse request, returning to the place it was before it was called, if thing is no real weapon or armor but just nothing instead or nil.

thing.cursed = cursed = case caster

In my script all weapons and armors have a class method named cursed that represents what the word itself stands for. case caster starts a complex comparison where every single possible result you will include in the following lines will be tested thoroughly. I already told what caster is.

when :priest, :clerigo then thing.curse_level > level

So it means that whenever the caster is :priest or :clerigo and nothing else (I do speak English and Spanish so I sometimes add Spanish terms as well, the German term is the same as in English so I did not need to add anything) the weapon or armor's curse_level is higher than the caster's level named level, then the equipment will be cursed automatically or will remain so, if it already was.

return !cursed

It will deliver the opposite value of the curse the weapon may or may not have on it. If it's cursed it will tell you the lifting process failed (false). It'd be a different story if it's not cursed, then the process was successful (true). Both true and false are normally called boolean or boolean values, you would need to learn some programming story to find out why, the long story short would be they were created to tell people if an evaluation, a test, ended as expected. being accurate (true) or inaccurate (false), perfect match (true) or a bad one (false), a good person (true) or a bad one (false), depending on what were you asking awhile before.

! there means not, the opposite of cursed in the case found above.

Recall I told you level could be an integer number, it does not mean you always need to type a number like 10, it could also be a class method like...

$game_actors[7].priest_level

...which would also return an integer, namely 0, Gloria's current priest level, she has not learned anything as how to sell her healing skills to people, including her fellow party members Remember she is the seventh actor or heroine in the database.

level = $game_actors[7].priest_level
KWork.lift_equip_curse(:priest, level, thing)

That's how the script call would look like then... but we better come up with a thing replacement!

Let's say her weapon is a mace so it could be...

gloria_weapon = $data_weapons[21].dup

I used dup that stands for duplicate or copy, a copy if the weakest mace available there. $data_weapons is the list of all weapins available in the maker.

The final and useful version of the script call would be...

gloria_level = $game_actots[7].priest_level
gloria_weapon = $data_weapons[21].dup
KWork.lift_equip_curse(:priest, gloria_level, gloria_weapon)

[DerVVulfman]

I think something needs to be added towards kyonides' description of the Game_Actor class, and that there is something missing in his basic example as shown below:

Code:

Class Game_Actor
  attr_reader :age, :height, :weight, :hunger
  def max_age
    100
  end
end
$game_actors[50] = Game_Actor.new(50)
$game_actors[50].name = "Evil Pod Pod"
$game_actors[50].age = 0

Within RPGMaker, there is a Game_Actor class, and a separate class called Game_Actors. Game_Actor is basically the structure or skeleton for each of your heroes, having a placeholder for your hero's name, his or her age, weight, height and ... hunger? But the Game_Actors class is a your list of actors when they've been made. It's like saying the Game_Actor class is a blank form to fill out. Each time you make a hero, you xerox the form, fill in the blanks and shove it into the Game_Actors 3-ring binder. Your original Game_Actor class is just the solid form with all the instructions.

So kyonides made a new actor, taking a copy of the 'Game_Actor' class, and filling in the fields for hero #50 being Pod... er ... Evil Pod Pod. After that, Evil Pod Pod can then be found in the Game_Actors class using $game_actors[50]. And it's not a coincidence that he uses the same number (50) between both the Game_Actor and Game_Actors class. Both numbers are meant to be the same, the ID of your hero from the database. So when Aluxes is introduced, it's much like saying $game_actors[1] = Game_Actor.new(1)

[Siletrea]

been a long time since I posted here...but I think I'm finally ready to seriously try scripting again!
re-reading through this old post I realized something...I remember none of it and none of it makes any sense anymore

SO!
I'm starting again...from scratch and I'm going to try and do simple things that I can accomplish through scripting to give myself a chance to learn it!

firstly! I want to make a script that makes a window popup in the screen with text telling me to hit a button and when that button is pressed the entire game window shuts down

so I'd need to learn how to make a window
then put text in the window and position the text where I want it
then get the game to shut down via button press

what do I need to essentially "know" in coding in order to pull this off

do note that any and all explanations should be explained as though your talking to a 6 year old as I have horrid times with terminology

I have a faint idea of what would need to happen to get it to work but no coding knowledge of whats really needed to pull it off

*when game opens make window
*the size of the window must be set and the position of the window set using right/left up/down coordinates
*the window will have text inside it
*make text for it to say
*the size of the text must be set and its position using right/left up/down coordinates
*a button must be chosen to act as the kill switch
*the game must know that only when that button is pressed ONCE can it shut down
*a kill command must be put in

I believe this is the right "structure" for it explained in steps
if theirs anything I've missed in the steps do let me know!

again just to stress this

any and all explanations should be explained as though your talking to a 6 year old as I have horrid times with terminology

[DerVVulfman]

Did we talk about Inheritance before? (checking....) Oh, wow! I did, at the beginning of Page 2! Lemme recap:

The Recap

Now there is another thing SIMILAR to the include system, and that is called INHERITANCE, but it is not called by any phrase like
Inherit Dancing.

Nope nope nope. It might be easier for you to see it.

Go and look at the 'Window_Selectable' class in your editor, and you may see this:
class Window_Selectable < Window_Base

Looks odd, no? The '< Window_Base' thingie says 'WE CHEATED!!!' We just made a whole class called Window_Selectable, and we're re-using material from Window_Base without needing to retype it!!!

So the Window_Selectable class is not just what you see there, but it also 'inherits' every method found in Window_Base.

And if that doesn't blow ya away, look at Window_Command!
class Window_Command < Window_Selectable

OMG, that's right! Not only is Window_Command everything you read in that script, but everything from Windows_Selectable 'AND' from Window_Base. That is a HELL of a shortcut.

But that does explain why Window_Command refers to 'normal_color' which was defined as a method in Window_Base. Window_Command 'inherited' the method and is using it.

.... Now before you ask, I know. The Window_Base class begins with
class Window_Base < Window

Window_Base is actually inheriting special 'hidden' methods from the hidden WINDOW class. The Window class is a special hidden class that deals with things like reading the individual chunks from the windowskin and how to draw them, the borders, etc. WE don't have access to the actual code for the Window class itself, and it might not even be in Ruby but C++. BUT, the Window_Base class can still access the methods and use them.

Did you read that again? Yes? Goodie! Cause I'm going to start using SOME terms here. You do have to learn them too, right?

When I said.....

Go and look at the 'Window_Selectable' class in your editor, and you may see this:
class Window_Selectable < Window_Base

Looks odd, no? The '< Window_Base' thingie says 'WE CHEATED!!!' We just made a whole class called Window_Selectable, and we're re-using material from Window_Base without needing to retype it!!!

Now I will talk about some terms: The Parent Class and the Child class. They probably came up with those names when they also decided to call this thingie 'Inheritance'

When I said that the Window_Selectable class is reusing material from Window_Base, it is 'inheriting' the material.... Just as a baby inherits its eyes from its mother. The Windows_Selectable class is what we call a Child class, and the Window_Base class is its parent. But just the same, the hidden Windows class is a parent class to the Windows_Base class... with Window Base being the child class.

Yeah, so whenever you have one class based on another, that new class is a child of the older parent.

So what the heck is a SUPERCLASS?????

Wait? Where did that come from? Krypton?

Nope. It's sorta just another way to refer to a Parent class. If you look at some of the default scripts like Game_Battler, they refer to themselves as being Superior to the other... a superclass:

Code:

#==============================================================================
# ** Game_Battler (part 1)
#------------------------------------------------------------------------------
#  This class deals with battlers. It's used as a superclass for the Game_Actor
#  and Game_Enemy classes.
#==============================================================================

class Game_Battler

Of course, you'll see that the Child classes have that goofy < Game_Battler after the class's name is defined:

Code:

class Game_Actor < Game_Battler

So saying that the Game_Battler class is a Parent class to the Game_Actor class, you could also say that the Game_Battler class is a superclass to the Game_Actor class.

Got it so far??????

[Siletrea]

Did we talk about Inheritance before?  (checking....)  Oh, wow!  I did, at the beginning of Page 2!  Lemme recap:

The Recap

Now there is another thing SIMILAR to the include system, and that is called INHERITANCE, but it is not called by any phrase like
Inherit Dancing.

Nope nope nope.     It might be easier for you to see it.

Go and look at the 'Window_Selectable' class in your editor, and you may see this:
class Window_Selectable < Window_Base

Looks odd, no?   The '< Window_Base' thingie says 'WE CHEATED!!!'   We just made a whole class called Window_Selectable, and we're re-using material from Window_Base without needing to retype it!!!

So the Window_Selectable class is not just what you see there, but it also 'inherits' every method found in Window_Base.

And if that doesn't blow ya away, look at Window_Command!
class Window_Command < Window_Selectable

OMG, that's right!   Not only is Window_Command everything you read in that script, but everything from Windows_Selectable 'AND' from Window_Base.   That is a HELL of a shortcut.

But that does explain why Window_Command refers to 'normal_color' which was defined as a method in Window_Base.  Window_Command 'inherited' the method and is using it.

.... Now before you ask, I know.  The Window_Base class begins with
class Window_Base < Window

Window_Base is actually inheriting special 'hidden' methods from the hidden WINDOW class.  The Window class is a  special hidden class that deals with things like reading the individual chunks from the windowskin and how to draw them, the borders, etc.  WE don't have access to the actual code for the Window class itself, and it might not even be in Ruby but C++.  BUT, the Window_Base class can still access the methods and use them.

Did you read that again?  Yes?  Goodie!   Cause I'm going to start using SOME terms here.  You do have to learn them too, right?

When I said.....

Go and look at the 'Window_Selectable' class in your editor, and you may see this:
class Window_Selectable < Window_Base

Looks odd, no?   The '< Window_Base' thingie says 'WE CHEATED!!!'   We just made a whole class called Window_Selectable, and we're re-using material from Window_Base without needing to retype it!!!

Now I will talk about some terms:  The Parent Class and the Child class.    They probably came up with those names when they also decided to call this thingie 'Inheritance'  

When I said that the Window_Selectable class is reusing material from Window_Base, it is 'inheriting' the material....   Just as a baby inherits its eyes from its mother.  The Windows_Selectable class is what we call a Child class, and the Window_Base class is its parent.  But just the same, the hidden Windows class is a parent class to the Windows_Base class... with Window Base being the child class.

Yeah, so whenever you have one class based on another, that new class is a child of the older parent.

So what the heck is a SUPERCLASS?????

Wait?  Where did that come from?  Krypton?

Nope.   It's sorta just another way to refer to a Parent class.  If you look at some of the default scripts like Game_Battler, they refer to themselves as being Superior to the other...  a superclass:

Code:

#==============================================================================
# ** Game_Battler (part 1)
#------------------------------------------------------------------------------
#  This class deals with battlers. It's used as a superclass for the Game_Actor
#  and Game_Enemy classes.
#==============================================================================

class Game_Battler

Of course, you'll see that the Child classes have that goofy < Game_Battler after the class's name is defined:

Code:

class Game_Actor < Game_Battler

So saying that the Game_Battler class is a Parent class to the Game_Actor class, you could also say that the Game_Battler class is a superclass to the Game_Actor class.  

Got it so far??????  

soo essentially its like a tree...inheritance is similar to a tree...starting at one point and then using the initial script as a building block to continue without having to constantly rebuild the same thing over and over....like a tree...the hidden "Window" class is the roots with "Window_Base" as the trunk "Window_Selectable" as branches and anything else that uses the scripts pertaining to the usage of windows becomes its leaves and "Pacman" < is a way of showing that its using the previously established script as a base to work from so its not as much too type
am I getting that right? because your explanation made oodles of sense if I got that right!

[DerVVulfman]

I love that you call em Pacman and Reverse Pacman. Its like saying... (My New Class) < (The Old class)



So yeah. The Parent class could be the ROOT class. Technically, your PC's hard drive has a ROOT Directory, right? And everything 'branches' out from that. In PC terms, you DO have a directory TREE too!!!

So rest on this first.... I'll think of something about Inheritance and the Super class tomorrow.

[DerVVulfman]

I wanted you to know about Inheritance and remind you about the Parent and Child Classes. At the same time, I needed you to understand that a Parent Class wears blue tights and a red cape.... er... a UPERCLASS.

Now to talk about how one class 'inherits' and what may happen

As you may have guessed, when you decide to make a class based on another class, crafting a CHILD class, that child class carries over methods from the Parent class. It inherited 'all' the methods from the previous class. And we also say that the Parent class is the Superclass to the new class you're writing.

So let's assume you have an existing class... And ... yeah... there's not much to it.

Code:

class Pops_Class
  
  def initialize
    @name = 'pops'
  end
  
  def my_name
    return @name
  end
  
end

The initialize method creates a goofy value called @name. And the @name value is holding the name 'pops'. The my_name value just returns the data of the @name value. So calling (or using) my_name just supplies you with the name in there.

If we made a class called Kid_Class like THIS:

Code:

class Kid_Class < Pops_Class
end

And it will actually inherit both the initialize and my_name methods!!!

BUT, what happens if you ... perform a change within the Kid_Class????

Code:

class Kid_Class < Pops_Class
  
  def initialize
    @name = 'Brat'
  end
  
end

Ooooh.... This one does not inherit the initialize method. It destroys it and creates its own initialize method. This new initialize method creates a new initialize method and new @name value storing the name 'Brat' this class does inherit the my_name method just as its parent class, so it will return the value of the @name value... returning 'Brat' instead of 'pops'

And...

Code:

class Kid_Class < Pops_Class
  
  def initialize
    @name2 = 'Brat'
  end
  
end

This likewise rewrites the initialize method, this time not even creating a @name variable but a @name2 variable instead. Yes, this version has a my_name call, but running it might go and *CRASH* as this class doesn't have a @name variable.

So, now let's introduce something new....

Code:

class Kid_Class < Pops_Class
  
  def initialize
    super()
    @name2 = 'Brat'
  end
  
end

What's that super() statement?????

As stated some time earlier, a Parent class is also called a superclass to the class. The super() allows you to create a new method, but include all the material and statements from the original within. So the above version with the super() statement acts like this!

Code:

class Kid_Class < Pops_Class
  
  def initialize
    @name = 'pops'
    @name2 = 'Brat'
  end
  
end

Everything from the first statement is replicated, pasted, SHOVED into where the super() statement is!!!! So this version with the super() statement creates both a @name and @name2 value.

So now let's try something practical and already existing.......

Let's look at the initialize method of the Game_Event class.

Code:

def initialize(map_id, event)
    super()
    @map_id = map_id
    @event = event
    @id = @event.id
    @erased = false
    @starting = false
    @through = true
    # Move to starting position
    moveto(@event.x, @event.y)
    refresh
  end

Oh, wow. First, this class is a child class of the Game_Character class. but it also has a super() statement, which means this class not only inherits methods from Game_Character, but this totally rewritten 'initialize' class has some of Game_Character's initialize method thrown in!

Here is the Initialize method from Game_Character

Code:

def initialize
    @id = 0
    @x = 0
    @y = 0
    @real_x = 0
    @real_y = 0
    @tile_id = 0
    @character_name = ""
    @character_hue = 0
    @opacity = 255
    @blend_type = 0
    @direction = 2
    @pattern = 0
    @move_route_forcing = false
    @through = false
    @animation_id = 0
    @transparent = false
    @original_direction = 2
    @original_pattern = 0
    @move_type = 0
    @move_speed = 4
    @move_frequency = 6
    @move_route = nil
    @move_route_index = 0
    @original_move_route = nil
    @original_move_route_index = 0
    @walk_anime = true
    @step_anime = false
    @direction_fix = false
    @always_on_top = false
    @anime_count = 0
    @stop_count = 0
    @jump_count = 0
    @jump_peak = 0
    @wait_count = 0
    @locked = false
    @prelock_direction = 0
  end

So essentially, what the Game_Event class really does is it replaces the super() statement with all the stuff from Game_Character... like this:

Code:

def initialize
    @id = 0
    @x = 0
    @y = 0
    @real_x = 0
    @real_y = 0
    @tile_id = 0
    @character_name = ""
    @character_hue = 0
    @opacity = 255
    @blend_type = 0
    @direction = 2
    @pattern = 0
    @move_route_forcing = false
    @through = false
    @animation_id = 0
    @transparent = false
    @original_direction = 2
    @original_pattern = 0
    @move_type = 0
    @move_speed = 4
    @move_frequency = 6
    @move_route = nil
    @move_route_index = 0
    @original_move_route = nil
    @original_move_route_index = 0
    @walk_anime = true
    @step_anime = false
    @direction_fix = false
    @always_on_top = false
    @anime_count = 0
    @stop_count = 0
    @jump_count = 0
    @jump_peak = 0
    @wait_count = 0
    @locked = false
    @prelock_direction = 0
    @map_id = map_id
    @event = event
    @id = @event.id
    @erased = false
    @starting = false
    @through = true
    # Move to starting position
    moveto(@event.x, @event.y)
    refresh
  end

That's sorta the BASICS of the super() statement. However, there's more to it. But I do want you to understand this before I cover something called parameters or arguments.

NO ARGUMENTS FROM THE AUDIENCE, PLEASE!!!!

[kyonides]

Ah... But you know I love to argue!

Plus I do think you can stil elaborate the the cub -> adult relationship even further here, especially when talking about calling super. Even so, I do think you should go ahead and add new stuff to that brattish / animalistic description no matter if one single drake does not fully grasp it, yet. I wanna read more "original" terminology in future posts that might make my "night"

I wonder if a certain individual is ready for loops, conditional statements, blocks, nested arrays and hashes, determining the player's opposite direction, recursion, including modules, extending classes or individual objects, metaprogramming, undefining inherited methods, determining if a value is even or just odd, getting a random number between 1 and 6 only just like one you would get after throwing a die, selecting or excluding actors, weapons, armors or items... Yeah, there is lots of stuff to be covered here or anywhere else.

[Siletrea]

Hmm so in inheritance if a “child” makes a name change over what the “parent” originally had set up (like ownership of a old duffel bag being passed down) it would permanently erase the “parents” name... so a child class can act as whiteout?

The superclass thing I find very confusing... as far as I know the @ is used to pretty much summon different elements from connected scripts using a Pac-Man or from other areas in the same script... but a @ is like a novice mage and isent very reliable so it’s better to use a $ as its like a warlock and does a much better job... so I’m wondering why your using @ if a $ is apparently better

I’m also pretty sure that “def” means “define” but I question why defining has to be done so frequently... can you elaborate more on that

And to the Fox I must remind that in order to fly one must have full understanding what wings are ... what type of wings they have... how the feathers/skin moves and reacts to different sensations...how the joints coordinate with each other to allow movement...and how they overall function as a means of transportation before even attempting to open them let alone flap them... aka don’t rush me... while your coding wings may be fully developed and have been working more then fine for you for probably over 20+years...mine are completely underdeveloped.... maybe 2 wiggly feathers at the moment... give me time... I’ll be fluttering around the programmers sky when I’m good and ready and not a moment sooner

[DerVVulfman]

Full understanding of what wings are, type of wings... joint coordinate with each other????

OMG! I think Siletrea read the Frank Herbert novel 'Children of Dune' as she basically creating her own version of the Bene Gesserit summation of the 'The Union of Opposites'.


And yes, when you make a Child class, you can essentially 'whiteout' a method copied over from the Parent class. But you do that by making your own version of that method. If the parent class has a 'get_silly' method, the child must too have a 'get_silly' method.

Okay, the Superclass thing...

Like I just said, your Child class must have the same methods as the Parent class, even if the Child rewrites the Parent's methods. But that doesn't give you much flexibility. That would only ensure that your child is a literal XEROX of the parent without any new features.

The whole thing about the Superclass is that you can create a new method in the Child class and quickly copy the stuff from the old method into it. Basically, the use of the super() statement is a shortcut so you don't have to manually enter every single item from the parent's version. It does that work for you.

If the parent class has a method called 'punch_freddy' and it looks like this:

Code:

def punch_freddy
  @target = @freddy
  @target.hp -= 20
  @target.damage = 20
  @target.flash = white
  @target.falls = true
end

You can use the super() statement in your child class to make a new 'punch_freddy' method like this:

Code:

def punch_freddy
  super()
  @target.woozy = true
  @target.screams = true
end

This saves some space in your code, so your child class doesn't have to rewrite everything like this:

Code:

def punch_freddy
  @target = @freddy
  @target.hp -= 20
  @target.damage = 20
  @target.flash = white
  @target.falls = true
  @target.woozy = true
  @target.screams = true
end

Looks like the new code with the super() statement only has three lines including the super() statement. Certainly seems better than remaking the method with seven lines, right?

And let's face it, this is a small example. Some methods you might be inheriting are HUMONGOUS! WHO WANTS TO REWRITE A 30-LINE METHOD WHEN THROWING A super() IN ITS PLACE CAN BE DONE?

YES, def means define. It is a statement that defines the start of a method. You use the 'class' statement to define the start of a class, and a 'module' statement to define the start of a module. You use the def statement so frequently because you make a lot of methods when writing code.

Again, it's heiarchy: A module can hold multiple classes, and classes can hold multiple methods... all a tree of sorts. Or a shrub if the guy writing the code is a total mess. ^_^

Now why use the ampersand (@) to define a variable rather than the dollar sign ($)... First, let's talk about what we call them.

The variables with the $ symbol are called 'global' values. They work throughout the whole system. Not just one code, but could be referenced throughout your entire SCRIPT LIBRARY!!!! WOOO! POWER. But it has drawbacks. It's a memory hog, using more resources than instance variables (next on the agenda). Also, it's riskier. If one script uses a $global variable of a particular name and another script uses a $global variable of the same name, they could wipe each other out!

The variables with the @ symbol are called 'instance' variables. They are defined to work specifically within their class. And because they are class specific, you can have two classes with instance variables of the same name. So if two different classes have a @my_name variable, they each can have different values set to each of them. One won't overwrite the other. Well, not without effort on the scripter's part. And they use less memory resources.

So while the $global variable has more reach, the @instance variable allows better coding.