Declare a NEW global variable (RGSS3)

[TheCaliMack 22]

How do you go about declaring a new global variable for a script to be Above Main and Below Materials?

I'm working on a script and felt like the best way to go about it was using a global variable, but I'm not sure if I should set up like a pre-set value like...

$SAMPLE = 0

module Something
   etc etc
end

or if I can declare it while in a module like....

module SOMETHING

   $SAMPLE = $game_actors[1].exp

end

I mean, I'm well aware of how to point to actors and all that, since they're practically variables, but you can't help but worry over simple things if you're deviating, right?

[TheoAllen 830]

The second one is a bad idea. Because $game_actors isn't defined yet.

There're some design rule you might need to consider.

 

In default script, all global variables are created within create_game_objects and load_database (i.e, inside rgss_main).

It means that if you press reset button (F12), the variable will be reset back.

 

If you declare the global variable outside the methods, the variable wont be reset even if you press reset button

correct me if I'm wrong.

[TheCaliMack 22]

So declaring a global variable of my own is generally a bad idea?
Damn, I thought that would help my Single Party EXP Script.

[TheoAllen 830]

Not really. Oh well, as long as you don't really have a real issue, you could try anything. Don't hesitate if I told you. You will learn something new eventually.

[Kayzee 4,033]

The thing about global variables is that they are part of the program state not the game state. Which means they are not necessarily saved in saved games, or reset on a new game. You will notice that in the DataManager module it explicitly creates, loads, and saves objects that are stored in particular global variables. Those variables and only those variables work correctly for what you want to do.

 

Honestly if I were you I would modify the Game_Party class and add a party_exp attribute to that. A object of that class is automatically created in the $game_party global variable and saved and loaded properly so you don't have to add to the list of global variables that are created saved and loaded.

[TheCaliMack 22]

Game Party.... That actually sounds like it could work. I'll give it a go.

[+ TBWCS 953]

The second one is terrible. Reasons:

 

• Uninitialized yet after being run through in game.
• You already created a module that can access a variable, you can instead create an instance that calls that as the value.
• It's already a global variable, why place it in a module?

There's already a part in Game_Party called the members:

  def members
    in_battle ? battle_members : all_members
  end

where you can always access the values of the experience of whoever is in your party. If it'd be me, I'll do this on a script call:

$game_party.members[x].exp

where x is the number of that actor in your party. Of course, there's also the battle_members and all. It'd be easy to run a simple check later on if you want a specific actor to change experience or whatever you want.

[AeghtyAteKees 11]

Does this mean that (in the editor, not necessarily in a script)  I should always modify variables with the control variables command, rather than using the script command and typing $variablewhatever = 6?

[Kayzee 4,033]

Does this mean that (in the editor, not necessarily in a script)  I should always modify variables with the control variables command, rather than using the script command and typing $variablewhatever = 6?

 

Unless you are temporarily setting a value somewhere for later in the event at least, or otherwise don't care about remembering the value later. Like I said, global variables aren't saved across play sessions, so the program will forget them. Actually, the opposite is a problem too come to think of it, the program will remember the value if you quit to the tittle screen and start a new game. So long story short, anything not explicitly set as part of the saved game will be in an inconsistent state across playsessions.

Edited July 5, 2015 by KilloZapit

[AeghtyAteKees 11]

Alrighty. To clarify, I SHOULD use the control variables command, and that the $game_variables array IS the best way to store values across different saves/loads? I had just wondered if there was a way to make lots of variables that didn't clutter that array and didn't need to use the event command, but I can definitely manage otherwise. Thanks!

[Kayzee 4,033]

You can, you just either have to attach it to an object that is saved or modify the lists of saved objects yourself. Look in the data manager module in the default scripts to see how saved games are done and you can just alias it like any other method and add stuff to the saved game if you want.

[Tsukihime 1,489]

It's a good way if you simply want to store a simple value that will be retrieved later, without having to worry about adding scripts.

 

$game_variables[12] = "some value"

As long as you always access variable 12 as a string you should be fine.

[Kayzee 4,033]

I guess you could even store an array or a hash there, or anything you want... but events dealing with that variable are likely to crash I guess, but you can just not have events access that one. Also $game_variables[0] is free to use because events can't access it at all.

Edited July 6, 2015 by KilloZapit

[Tsukihime 1,489]

Logical errors are likely going to occur if you use a single variable for multiple purposes anyways, so there isn't much harm as long as you're consistent.

[AeghtyAteKees 11]

Well I'm working in the event editor on this one, so I definitely need events to access the variables. Heck, here's what I'm doing, if I may elaborate here: I have many many NPCs, and I've created a Fable-esque/Sims-ish player personality system and I wanted every NPC to have a disposition toward the player, and thus I need many variables, I believe. I wasn't very inclined to have possibly hundreds of NPC disposition variables scattered throughout the $game_variables array and cluttering the control variables window, especially if I'll need to add more as I go. So I wondered if I could just declare variables in script calls, not using $game_variables and keeping them separate from the control variables event command. Unless someone has a more practical approach, or some other advice.

 

Also (if it even matters), nearly every NPC is a common event that map events call, to keep things consistent across maps and NPC movement.

Edited July 6, 2015 by AeghtyAteKees

[Kayzee 4,033]

I think you are better off modifying the saved game for that... It's actually more simple to do then you might think... if I recall correctly it's just one big hash. It would be better though to organize everything in one $game_* object or a module and use a hash though. That way you can just add keys to the hash but everything would be contained in one object. Look at my simple database system I wrote a while ago for example. I alias DataManager's create_game_objects, make_save_contents, and extract_save_contents to add the data I want to saved games and use a module with a hash to do everything else. You can also create a class and put it under a global variable if you would like, that might be easier.

Edited July 6, 2015 by KilloZapit

[AeghtyAteKees 11]

I looked at your database script and I see what you did with the aliases, though if you're suggesting I use that information to help me code something, I'm not sure if I could. I'm not a strong scripter (I mainly modify and break things until I 'customize'  a script to my need, haha). But if your last tip about creating a class under a global variable will work for me, could you elaborate? Or help me make that work? Thanks for all your help so far, by the way.

 

Or I could just get over myself and use the damned event editor. 

Edited July 6, 2015 by AeghtyAteKees

[Kayzee 4,033]

You would have to do pretty much what I do in my database script, alias the DataManager's create_game_objects, make_save_contents, and extract_save_contents to add stuff to the saved game's hash. Only difference is what you would add. You could add anything you like, even a bunch of simple things if you needed to... I don't know if I could help much with the details though. But as an example:
 

module DataManager
 
  #--------------------------------------------------------------------------
  # * Create Game Objects
  #--------------------------------------------------------------------------
  class << self
    alias create_game_objects_tablelist_base create_game_objects
  end
  def self.create_game_objects
    create_game_objects_tablelist_base
    $game_testhash = {}
  end
  #--------------------------------------------------------------------------
  # * Create Save Contents
  #--------------------------------------------------------------------------
  class << self
    alias make_save_contents_tablelist_base make_save_contents
  end
  def self.make_save_contents
    contents = make_save_contents_tablelist_base
    contents[:testhash] = $game_testhash
    contents
  end
  #--------------------------------------------------------------------------
  # * Extract Save Contents
  #--------------------------------------------------------------------------
  class << self
    alias extract_save_contents_tablelist_base extract_save_contents
  end
  def self.extract_save_contents(contents)
    extract_save_contents_tablelist_base(contents)
    $game_testhash = contents[:testhash]
  end

end

would let you save a $game_testhash global variable. Though if you are asking more about how Ruby classes work, you might want to read some general Ruby tutorials. I recommend this one, it has cartoon foxes!
 

[AeghtyAteKees 11]

Okay, I may be following. So would it be possible to use $game_testhash like the $game_variables array, so I wouldn't need to dive into the script constantly? Like this: $game_testhash[3] = "WhyIsThisHard?"

 

Is an array not a variable anyway? I just don't know if the size of it needs to be set up in the script or how that works at all.

 

EDIT. This Ruby guide has to be far too amusing to be educational, according to college textbook standards. Or maybe college has it all wrong. This book is amazing.

 

NEW EDIT. I have since learned the definition of a hash, and that a hash is not an array. Excuse me.

Edited July 7, 2015 by AeghtyAteKees

[Kayzee 4,033]

Okay, I may be following. So would it be possible to use $game_testhash like the $game_variables array, so I wouldn't need to dive into the script constantly? Like this: $game_testhash[3] = "WhyIsThisHard?"

 

Is an array not a variable anyway? I just don't know if the size of it needs to be set up in the script or how that works at all.

 

EDIT. This Ruby guide has to be far too amusing to be educational, according to college textbook standards. Or maybe college has it all wrong. This book is amazing.

 

NEW EDIT. I have since learned the definition of a hash, and that a hash is not an array. Excuse me.

 

Hashes are neat because you can use anything as a index, not just numbers! I prefer using symbols myself... but yes you can use $game_testhash[3] = "WhyIsThisHard?", and arrays automatically grow to use the highest index they use so you don't need to set the size (hashes grow too, you can add keys whenever you want). Also to be fair, what Ruby calls a "hash" is often called an "associative array" in other languages. It's kinda just an array that uses something other then numbers to index it (though you CAN use numbers, you can use pretty much anything, I have even done it with classes before).

 

Also: In Ruby, an array is not a variable, it's an object that a variable references. For example $game_variables is a variable, $game_variables[1] is not. Rather $game_variables[1] is a statement that says to look up index 1 in the array referenced by the variable $game_variables. It's sort of confusing because you see statements like $game_variables[1] = 1 and assume $game_variables[1] is a variable, but it's not. Ruby has a few tricky statements like that that try and hide what is really going on (mostly as an attempt to look a bit like C or C++ even if it behaves vastly differently).

 

If you want to be even more confused, the object referenced by $game_variables isn't actually an array it's a class that defines a [] method to look up from an array that it references in an instance variable and a []= method to set it to the same array. You can do lots of really weird and clever stuff like that, making objects act like other objects.

Edited July 7, 2015 by KilloZapit

[AeghtyAteKees 11]

Actually, to my surprise, I'm not all that confused. Thanks for referencing this Ruby guide; I haven't been able to stop reading it.

 

So on the topic of hashes, I should be able to reference a value in some other way than $game_testhast[3], because then I would need some convenient list of what index is what to keep the numbers straight, much like the Control Variables event command has.

Edited July 7, 2015 by AeghtyAteKees

[Kayzee 4,033]

Well I use symbols for hashes like $game_testhast[:this_value] and lots of people use strings like $game_testhast["this value"]. I think symbols may be slightly faster but I am not sure.

[AeghtyAteKees 11]

So without altering anything from the tiny script you posted, I should be able to use the script command

 

$game_testhash[:testsymbol] = 5

 

and it essentially creates this

 

$game_testhash = {:testsymbol => 5}

Edited July 7, 2015 by AeghtyAteKees

[Kayzee 4,033]

Well yeah, except $game_testhash[:testsymbol] = 5 would add to the hash and $game_testhash = {:testsymbol => 5} would overwrite it, but I assume you knew that.

[AeghtyAteKees 11]

Thanks for all the knowledge! You've been very helpful.