I'm starting scripting ^^

[element]

yeah, i tougth it would make no sense.
Ill start reading some more code tomorrow.

[Calintz]

Alright, since this is an active thread I'll ask this question here.
What is the importance of knowing real RUBY programming as opposed to RGSS?

@ALL RGSS Scripters on CP:
Would you personally advise learning as much about the father language as possible before beginning with RGSS, or do you believe that connection is unimportant? Do you feel personally that people would be wasting time with RUBY? Is RGSS easy enough to pick up on without a proper understanding of RUBY?

[Blizzard]

RGSS is not really a language. RGSS is a system that can be used with Ruby. The way the scripts are organized in RMXP is just an internal way of arranging them. When you learn RMXP's Ruby and RGSS, you are learning Ruby anyway. Of course, it will be easier to work with RMXP's scripts if you already know Ruby, but you will still have to figure out how RGSS works.

[Ryex]

don't bother learning ruby specific programing first in order to use RGSS you need to know its structure and once you have learned RGSS you have learned Ruby
it is the same language RGSS just hase some extra built in classes that are game specific.

[Calintz]

Well alright then.
Thank you guys. I have spent an hour or so just looking at default scripts.

Things are still a blur to me. I get pieces here and there. This is gonna take me forever, and I really don't think I'll get to the point where I can build scripts from the ground up. I think I'll be able to edit at best, Lol.

[Blizzard]

Right, I said a bunch of things, but actually didn't give a direct answer.
Pretty much what Ryex said. Don't bother with Ruby, go straight for RGSS. You will learn Ruby with RGSS faster that you would be if you first learned some Ruby and then had to learn RGSS again.

Yeah, the default scripts are quite big. Best you take just one of the simpler scripts and try to understand a bit what is going on. Then try to add edits and see what happens. If you understood things right and the changes you made were what you wanted, the right thing should happen and you will figure out something in the scripts. Then you can go from there and keep experimenting.

[Calintz]

That worked for me in the past, and it seems to be working now. Like, I have made some simple edits to the title screen, and some simple edits to the default menu system and like you said ... the edits are what I want and so pieces of the puzzle are beginning to fall into place, but will this method really take me to the top?

A constant help for me has been the Help Text file in the editor believe it or not.

[Ryex]

yes it will take you to the top, and yes the help file is awesome. I'm still using it, and will likely keep using it. its not like a person can completely memorize an entire code base.

[Calintz]

*points to Blizzard* (with both hands muthaf*****) LMFAO.

At any rate this is good news. Thank you Ryexander.
Continuing to look at default scripts I've realized that the scripts use two main thingy majigs. def initialize and def main.
Am I correct in assuming that def initialize is used when establishes an item's properties, and that def main is used for the declaration of processing of those items?

[Blizzard]

Exactly. "initialize" is called when you create a new object, a new instance of a class.

[ForeverZer0]

well to call it on the map you would edit scene maps main method but as is your code won't work. Bitmaps alone aren't drawn to the screen you need to create a sprite and attach the bitmap to it btw the Bitmap.new(50, 50) create an empty bitmap and won't do anything and the Bitmap.new(189-Down01) won't work because first off it take a string and second the path to the image is wrong

You need something like this:

class Test_test

  def initialize
    @sprite = Sprite.new # Sprites display the bitmaps
    @sprite.bitmap = Bitmap.new("FILENAME") # Sets a bitmap to the sprite
    @sprite.x, @sprite.y = X, Y # Sets the location, in pixels, of the sprite on the screen
  end

  # Now the sprite will not update without calling an update method and the game will
  # crash if the sprite is not disposed and called again, but I hope this can at least
  # point you in the right direction.
end

[Ryex]

ya def initialize is an inbuilt ruby method that is called when .new is called in order to create the object and "initialize" object data

def main is only uses in scene classes.

a scene class is a class that process a scene and is something you set the $scene object too

it you look at the main script you will notice that that it loops indefinitely and calls $scene.main
a def main method contains another loop that dose updating
first it calls Input.update to update input information form the system and make it available to in game processing
then it calls the scene update method which updates displayed windows, and then it calls Graphics.update which refreshes what is drawn on the screen.
then you will notice that in the loop in the main method there is a condition
if $sceen != self
  break
this means that if $scene has chanced to something that is not the same object that the loop is running it breaks the loop.
you will notice that after the loop there is objects disposed. this makes sure the all the sprites drawn in that scene are disposed so that they don't carry over and stay when the next scene is called.
at this point the code jumps back to the main loop again and calls $scene.main again. so the main method of the new scene is called.

are you starting to understand the flow now?
understanding program flow is key to understanding RGSS

[Calintz]

That is the answer I was looking for Blizzard. Thank you!
Knowing that def initialize is called when I create a new class will be a much more logical way for me to remember its purpose than simply saying it's used to define the characteristics of a class (even though that's what it's for).

@Ryexander:
This conversation between Blizzard and me was a perfect example of that gap we talked about. I understood that "def initialize" held the base characteristics of a new class by looking at default code, but now knowing that it absolutely needs to be called and defined and when I need to do that helped me cross that gap of application. Now I know how and when to apply that syntax. If that's the case with 'def initialize' ...

@Scripters:
Then the same goes for 'def main' right? If you create a new class then "def main" NEEDS to be defined somewhere after def initialize, right? Because 'def initialize' sets up the new class, but something has to tell those properties what to do? That is what 'def main' is for, right? Well...maybe "def main" doesn't technically tell that class what to do, but it tells all the attributes defined in the new class' 'def initialize' method how to properly process the way you want without failing, right!? That's the purpose of 'def main'?

Then, you take it one step further by creating a new scene.
Calling new scenes is how you actually tell that new class what to do, right appear on screen?

Edit:
@Ryexander:
yea. I really do believe I'm understanding this a bit now. This order...it will always be the same for all new classes and scenes, etc...? Like, it doesn't matter if I'm making a time and climate system that doesn't use graphical enhancements as opposed to a CMS. The process of writing the code needs to be the same, right?

[element]

Ok I learned Reall ymuch more now.
So now I'll try to make a class that stops the bgm.
Nothing more than that.
I learned that

$Class_name

is used to call a class and

$Class_name.Thing_in_class

is used to call

def Thing_in_class

True?

Also can someone explain me how scripts are built up? and explain some more things like the previous explaination of def initialize, cuz that helped me alot 

[Blizzard]

Pretty much, yeah.

@Calintz: def main is a slightly different concept. Scenes define main as a sort of entry and exit for a main update loop. Other classes don't need a main. In fact, initialize isn't needed either. If it's not defined, it will not be called. So if you have a utility class with no attributes, there is no need to define initialize.

[Calintz]

@Blizzard:
I think I understand that concept. By default you are on the map. This is a scene in itself. It contains all of the information needed to play the game, and only updates that information accordingly. Viewing your menu however, has a completely different set of requirements and information of its own, therefore you need to make a transition through those scenes. It's that transition from updating one set of information to a whole new set that requires the 'def main' to be used?

This is why windows don't have a 'def main' right? Their information is established through the 'def initialize' process. That process builds the window itself and its update information, but no actual change from one update to another is required. This is why windows don't have 'def main' in the code, but scenes do? The scenes(which is where 'def main' is used, because of the transition) simply pulls that information by calling it's class. (Scene_Menu.new)

Is that right?

[element]

Anybody can help me with wat i'm doin wrong.

##################################################
#                                                #
#              stop the bgm test                 #
#                                                #
##################################################

module MUSIC
  def initialize
    @Stopthemusic = false
  end
  class Stop_music
    def music_stop
    
      if @Stopthemusic == true
        $game_system.bgm_stop
      end
    end
  end
end

I'm calling the stop the bgm in an event with : MUSIC.@Stopthemusic = true

It gives me a syntax error that leads me to game_temp first line

[Ryex]

ya that would fail... for one. @Stopthemusic isn't public, and ya there is just a lot wrong with that.

ok first off modules are completely different than class in terms of what they are user for. think of a module as a static namespace that can't be instanced.
in other words MUSIC.new would raise a NoMethod error. so no def initialize for modules.
modules can contain methods and classes but in order to call a modules method out side the module they have to be defined as
def self.methodname
this format allows a method to be called with out the class (or module) being instanced
def method name can only be called by a method inside the module

take this for example

##################################################
#                                                #
#              stop the bgm test                 #
#                                                #
##################################################

module Music
  class Stop_music
    def self.music_stop
      stop_music_internal
    end
    def stop_music_internal
      $game_system.bgm_stop
    end
  end
  def self.music_stop
    stop_music_internal
  end
  def stop_music_internal
    Stop_music.music_stop
  end
end

Module and Class names MUST be capitalized other wise they are not constants and they can't be called correctly
method names by convention are not capitalized, there is no reason two and it confuses people, also i think it might have some side effects I don't know about.

Music.music_stop  #> stops the music
Music::Stop_music.music_stop  #> stops the music
Music.stop_music_internal  #> NoMethod Error
Music.Stop_music.stop_music_internal  #>  NoMethod Error

[Blizzard]

@Calintz: Yes, you got it. Windows usually have a refresh method that updates the display. That method should only be called when the information has changed because calling it every frame would heavily increase CPU load and it would start to lag. Windows also have an update method that updates other additional information such as user input to move the cursor around (or even constantly checking whether the displayed data has changed so it can be refreshed).

When calling a new scene, you need to use "$scene = Scene_X.new" When the current update loop ends, the current scene will exit and the new scene will be started.

[Calintz]

@Element:
We're getting there bud. A step at a time.

@Blizzard:
I've noticed the use of the refresh method in the Gold window, Steps window, and the Playtime window, and so that was my initial thought: The refresh method is used because that information is always changing during gameplay. The Playtime clock even runs during Menu processing.

Actually, because the Playtime clock is always running isn't that why there is an additional 'Frame Update' method in the standard Playtime script? It looks like the code is saying "if the frame count divided by the frame rate changes by the second, then refresh. Either that, or if the frame count divided by the frame rate is no longer equal to the current playtime, then refresh. This is what my brain interprets from that line. Does the '/' even mean divided by in that line, or am I missing something?