GML Question about flags

IncuTyph

Member
So, I'm looking at code that's ripped from Earthbound (it was more like a demo using EB's code, but wasn't finished) to try and learn some things, but I have a question regarding how something works. There's an end step event for the player object for party movement that calls upon a script called get_flag, seen here on this line:
GML:
var more;
more = get_flag(28) + 1
When I go to see what that script actually does, it simply reads:
GML:
///get_flag(flag)
return global.flag[argument0]
I'm honestly a bit confused on what's happening with this. There wasn't a list of flags that I could find, so I'm not exactly sure where the 28 is coming from, or what it does. Am I missing something that would help me understand, or am I just not 'getting it'? I was hoping to use it to help me visualize the concept of flags, since, to be frank, reading straight from a manual doesn't seem to help me understand things. The examples given in the manual don't always make it any easier to understand. I kinda have to see it in action for real to make connections in my brain to actually learn for some reason. I guess I'm a visual learner? I don't know. Anyway though, I had an idea for flags for my own project, but getting stuck on understanding the above situation, I'm not sure if what I was going to go with was going to work now. Any help or advice is appreciated though!
 

rytan451

Member
get_flag is returning the flag at index 28 in the array global.flag. In this case, 28 is a magic number, which, in better code, would be replaced with a descriptively-named variable/enum/macro.
 

Nidoking

Member
In short, there's a notebook somewhere where someone has written "28: number of times talked to Mr. Saturn 3" or something like that, and many other similar entries. The way to use this as an example of how to use flags is to use this as an example of how not to use flags. Use names or comments to explain what things do without a notebook.
 

rytan451

Member
In the above case (thank you, @Nidoking), then the code should look something like this:

GML:
// Somewhere:
enum Flags {
    // ...
    NUMBER_OF_TIMES_TALKED_TO_MR_SATURN_3 = 28,
    // ...
}

// In your first block of code:
var more;
more = get_flag(Flags.NUMBER_OF_TIMES_TALKED_TO_MR_SATURN_3) + 1;
Though the code you've shown is more compact, this above code is just as fast (any self-respecting compiler would have replaced the constants), and is much more readable, saving loads of developer time when coming back to read and understand the code. And believe me, developer time can be expensive.

Because of the compactness-readability tradeoff, I often write code with short variables (ww, wh, w, h, r, g, b, c, etc.) and then, after finishing the script, I use find+replace to change them to readable names (window_width, window_height, width, height, red, green, blue, color, etc.) When I'm programming, I'm already holding my variable meanings in my head, so it's so much better to just use a short name. But, when I want to reread my code, I never want to have to understand names like c (was that the third temporary variable or was that color?) so I find+replace right after finishing writing the code.
 

IncuTyph

Member
Ok so simply put, I was looking at a bad example from the get-go.
I was going to do something like this for my flags (which in hindsight would maybe be good for just objectives, not everything?)
GML:
global.flag[1,1] = "Flag name" //Denotes the purpose or objective, such as "Dialogue set 1" or "Examine hole in wall"
global.flag[1,2] = false //Is it completed?
global.flag[1,3] = false //Is it active?
But I see that an enum would probably be a lot better for that. To help me understand though, to make sure I actually understand, the example you're giving looks like it's essentially just tallying, is that correct? Or would the +1 on the more = expression make it go to the next flag, a "Name_of_flag = 29"?
 
So you would have a current_flag variable, or something like that. So if you have a list of checkpoints and you want it to set each checkpoint to true as you pass it, you would have something like this

Create Event:
Code:
checkpoint[0,0] = "Checkpoint 1";
checkpoint[0,1] = false; // Has it been reached
checkpoint[0,2] = 100; // X that has to be reached for the checkpoint to be reachedd
checkpoint[1,0] = "Checkpoint 2";
checkpoint[1,1] = false;
checkpoint[1,2] = 200;
checkpoint[2,0] = "Checkpoint 3";
checkpoint[2,1] = false;
checkpoint[2,2] = 300;
// etc
current_checkpoint = 0;
Then whenever you hit a new checkpoint, you would update the current_checkpoint variable

Step Event:
Code:
if (x > checkpoint[current_checkpoint,2]) { // If current_checkpoint is 0, checkpoint[0,2] is returned, which is 100, if current_checkpoint is 1, checkpoint[1,2] is returned, which is 200, etc...
   checkpoint[current_checkpoint,1] = true;
   current_checkpoint++;
}
EDIT: In addition, you can set a variable TO an enum, so something like my_var = checkpoint_enum.START and then using my_var++ would increment through the potential enums there (though you would have to error check for when it's greater than the number of enums you set).
 
Last edited:

IncuTyph

Member
Ok, so I'd have to have an object for that that handles the flags in that situation, I'm assuming. If I understand this right, if I'd want to progress a main story, I could do something like this:
GML:
checkpoint[0,0] = "Defeat 2 enemies";
checkpoint[0,1] = false; // Has it been reached
checkpoint[0,2] = 2; // x that needs to be reached for checkpoint to be complete
checkpoint[1,0] = "Talk to Charlie";
checkpoint[1,1] = false;
checkpoint[1,2] = 1;

current_checkpoint = 0;
and when 2 enemies are defeated they give a +1 to the x, have the step event as you suggested, and when the current_checkpoint is updated, talking to the right NPC (the quest-giver, Charlie in this case) can give +1 to the x which would complete that and so forth, right? It wouldn't have to have an increasing x requirement like your example, is what I'm asking.
 

Yal

🐧 *penguin noises*
GMC Elder
Flags are usually strictly boolean (either the flag is set or not) and more complex conditions handled by having multiple flags (e.g. separate flags for triggering and beating a boss, so you get to skip its introduction on rematches). A lot of flags have no "active" time, like whether you've looted a container or not, so having those separate gives you more upkeep. However, nothing stops you from having separate boolean flags and "progress counters" for linear flows, where you start at 0 and can proceed to arbitrary values - things like how far someone has moved along their questline might be easier to organize with a counter like that.

Since most flags will just refer to random one-off conversations or item containers, I'd also recommend using #macro or enum definitions to give them a name (while still being a number under the hood) - these names also show up in autocomplete and syntax highlighting, while your string names do not, so they make it easier to use the flag from elsewhere in code too.
 

IncuTyph

Member
A lot of flags have no "active" time, like whether you've looted a container or not,
What do you mean exactly by active time? Also I'll see about trying an enum. I'm using GM 1.4 so I don't know if a # function works on it (never tried it though). Thank you very much for your response.
 

Yal

🐧 *penguin noises*
GMC Elder
What do you mean exactly by active time? Also I'll see about trying an enum. I'm using GM 1.4 so I don't know if a # function works on it (never tried it though). Thank you very much for your response.
As in, flags go directly from "completely untouched" to "finished", without spending any time in the "active" state where they're reached but not complete.

And yeah, #macro doesn't exist in GMS1.4. There's a "define macros" / "define constants" menu instead (it was renamed at some point) which fills the same purpose, but is a bit more awkward to use.
 

IncuTyph

Member
As in, flags go directly from "completely untouched" to "finished", without spending any time in the "active" state where they're reached but not complete.

And yeah, #macro doesn't exist in GMS1.4. There's a "define macros" / "define constants" menu instead (it was renamed at some point) which fills the same purpose, but is a bit more awkward to use.
OOOH Ok I think I get you now. So they'd be more of a 'one-step' flag while other things like quests or storyline flags would be 'two-step'. I'm assuming I'd have to make a flag for each chest/hidden item I add to the game, and to make an object to handle the flags, is that correct?
 

Yal

🐧 *penguin noises*
GMC Elder
OOOH Ok I think I get you now. So they'd be more of a 'one-step' flag while other things like quests or storyline flags would be 'two-step'.
Yeah, basically. Except why settle for two steps when you could have a counter that goes from 0 to 1 to 2 to... any number you want? Then it's always enough with a single "number flag" for a quest, since you have 2^32 = 4,500,000,000 values to pick from.

I'm assuming I'd have to make a flag for each chest/hidden item I add to the game
Correct! :)

and to make an object to handle the flags, is that correct?
Well, not entirely correct. You don't need to make an object to store them. You could make the flags array(s) global (stick global. in front of the variable name) which makes them object-independent and also makes them carry over between rooms. Since objects need to be persistent to carry over between rooms, and can be destroyed and deactivated if you're not careful, global variables are usually a bit easier to deal with. So I'd recommend that approach.
 

IncuTyph

Member
You could make the flags array(s) global (stick global. in front of the variable name) which makes them object-independent
So make a script to handle it then, and then just call up the variables when I need them. I'd need to use global.variable every time I need the variable, if I'm not mistaken, like I did here:
GML:
global.hp = round(((2*other.bhp*global.lvl)/100)+50);
Or would I not need to add global. to the variable name after establishing it? (And for that matter, I feel like the other. might be misused, as it's not a collision event or in a with statement; it's a script, but I'm not sure now.) Sorry if I sound dumb and a bit offtopic now, it's a bit refreshing to actually talk to someone/group of someones that actually help. Been trying to learn on my own but it's nice to fact-check before I get too deep into something.
 

Yal

🐧 *penguin noises*
GMC Elder
Yeah, you need to use global every time you refer to the variable - global.hp and hp are two completely different variables, hp being an instance variable. (They should actually be color coded differently in GMS2). It might help if you think of "global" as a sort of object that's always present and can't run events, but can have variables.


(and since global.hp and hp are two different variables, this means you can e.g. give enemies their own "hp" variable and have the player use "global.hp"... but be careful doing this kind of thing, because it's easy to mix the variables up and get weird bugs where you accidentally use the wrong one)
 

IncuTyph

Member
I assume I'd put an enemy's stats in their create event if I decided to do that, though I was planning on indexing my enemies similar to how I was going to do my party:
GML:
//in scr_init
global.party_mem[1] = 0; //The player's character
global.party_mem[2] = 0; //First ally recruited
global.party_mem[3] = 0; //Second
global.party_mem[4] = 0; //Third
global.party_mem[5] = 0; //Fourth
global.party_mem[6] = 0; //Fifth

//in scr_ini_stats_1

//Player character's base stats
global.bhp[1]     = 80
global.bmp[1]     = 200
global.bstr[1]    = 70
global.bmag[1]    = 230
global.bp_def[1]  = 115
global.bm_def[1]  = 115
global.bspd[1]    = 70
I feel though that the global.hp (as well as the other stats) equation I shared earlier might not work with this though, and that I might have to rewrite it. But if it's sound, that was my plan.
 
The usual way of doing stats is not to have separate variables for all the stats, it's to use enums and an array (or list):
Code:
enum char_stats {
   IN_PARTY,
   HP,
   MP,
   STR,
   MAG,
   PHY_DEF,
   MAG_DEF,
   SPD,
   NUM // This is just an index that can be used for looping through to the end of the stats, it's not used for anything apart from that and it should always be the last position in the enum
}

for (var i=0;i<number_of_party_members;i++) {
   global.party_member[i] = array_create(char_stats.NUM);
}
Now you have an array that has a position for each party member, and then an internal array inside each position that will hold all their stats. To get at something, simply use:
Code:
var pmember = global.party_member[0] // Pmember now holds the array that has all the stats for the first character in your party
pmember[@ char_stats.HP] = 100;
pmember[@ char_stats.MP] = 100;
pmember[@ char_stats.STR] = 5;
// Etc...
It's not absolutely necessary to do it this way, but it does help in certain scenarios, for instance, if you want to loop through a players stats, or set all their stats to 0, or whatever. It's one of those things that you don't think you need until you do and then it's a pain in the arse if you've set it up wrong initially.
 

IncuTyph

Member
Either the @ sign in the pmember string you suggested or the [ bracket seems to be giving me trouble, as I'm getting an error that there's an unexpected symbol in the expression there. It's line 21 on my script, position 9. I'm using GMS 1.4 if that makes any difference. Do I need to replace the @ with something?
 
Ah, ok, it probably is the accessor breaking it. The alternative method is this:
Code:
var pmember = global.party_member[0] // Pmember now holds the array that has all the stats for the first character in your party
pmember[char_stats.HP] = 100;
pmember[char_stats.MP] = 100;
pmember[char_stats.STR] = 5;
// Etc...
global.party_member[0] = pmember; // We have to "re-store" the temporary array into the party_member list, because I'm pretty sure GMS is copy-on-write with arrays, so if we don't the changes won't be saved
 

IncuTyph

Member
I think it's the brackets, because it's still giving the same error in the same place. When I remove the brackets and the .HP, the error goes away. Weird.
 
Can you copy and paste the actual error. Removing the brackets and the .HP completely borks everything, so that's not a solution (just because it's not throwing an actual error doesn't mean the data is being stored in the way you want it to be).
 

IncuTyph

Member
When I try to run the game it says "Error in Script 'scr_ini_stats_1' at Line 21, Position 9: Unexpected symbol in expression."
GML:
//... This is in said script

enum char_stats {
   active_party, //I swapped your suggested IN_PARTY for this
   bhp, //And I'm gonna try to use separate values for calculated stats based off base stats
   bmp,
   bstr,
   bmag,
   bp_def,
   bm_def,
   bspd,
   NUM 
}

for (var i=0;i<number_of_party_members;i++) {
   global.party_member[i] = array_create(char_stats.NUM);
}

var pmember = global.party_member[0] 
pmember[char_stats.bhp]   = 80; //This is the line where the error is occurring
pmember[char_stats.bmp]   = 200;
pmember[char_stats.bstr]  = 70;
pmember[char_stats.bmag]  = 230;
pmember[char_stats.bp_def]= 115;
pmember[char_stats.bm_def]= 115;
pmember[char_stats.bspd]  = 70;

global.party_member[0] = pmember;
//...
I only removed the brackets and such to try and see what was triggering the error, and it seems to be the brackets themselves.
 
Well, one thing I notice is that you are missing a ; at the end of the line "var pmember = global.party_member[0]". Add a semi-colon there, when I ran that code in GMS1.4 that's what was causing the error:
Code:
var pmemeber = global.party_member[0];
pmember[char_stats.bhp]   = 80; //This is the line where the error is occurring
pmember[char_stats.bmp]   = 200;
pmember[char_stats.bstr]  = 70;
pmember[char_stats.bmag]  = 230;
pmember[char_stats.bp_def]= 115;
pmember[char_stats.bm_def]= 115;
pmember[char_stats.bspd]  = 70;
 

IncuTyph

Member
Well, one thing I notice is that you are missing a ; at the end of the line "var pmember = global.party_member[0]". Add a semi-colon there, when I ran that code in GMS1.4 that's what was causing the error:
Well then, that solves that I guess. Honestly would have missed that for another week, with how scatterbrained I can get. Alright, so would I do the same for each party member (total of 6) after the first one? Or would I need to make a new variable since party_member[0] is pmember? Was planning to have 3 active members against enemies (think FF), with the other 3 in reserve. I probably should also ask if the var pmember expressions should go in the specific character's create event instead of in a script. I currently have it in the script where I was going to store stats/weaknesses/etc for the party, which would probably warrant more variables, but if I stick them in the characters' create events the variable pmember would be localised, if I'm not mistaken.
 
Ok, so pmember is not any particular member and it's not something that is kept around (hence why it is a local variable, which gets deleted once the event/script/codeblock that it's running in is finished. That codeblock that I gave you is ONLY the setup of the character stats. You would need to set it up using the same method (just incrementing global.party_member[0] to global.party_member[1] and then global.party_member[2], etc) for all the party members you want. The point is that you will then have an array global.party_member, which holds all the info for all your party members. Any time you need to get some info from it, you run a version of the "pmember" section of code, just updating which party member you are targeting like this:
Code:
var pmember = global.party_member[0] // This is your first party member (array indices begin at 0, so first party member is 0, second is 1, etc
var pmember = global.party_member[1] // Pmember now holds the data for your second party member
If you always plan on having the same party members in the same order, you can enum the party_member number and then use those enums to get the member you want like this:
Code:
enum member {
   JOHN, // Enums count up from 0 if you don't assign a value, so member.JOHN is the same as typing 0, it's just easier to understand what it means as text rather than an integer
   SALLY, // Sally is the same as 1, etc
   BOB,
   HUGO
}
var pmember = global.party_member[member.JOHN]; // Now holds the member information from position 0, which in this example is John
So one thing you can do is write some scripts to pull data out from the array, something like this:

get_strength() script:
Code:
///@function get_strength(member_number);
///@description Returns the strength of the member at position "member_number" in global.party_member
///@param {int} member_number The position in global.party_member that you want to access

var member_number = argument0;
var pmember = global.party_member[member_number];
return pmember[char_stats.bstr];
You would run that script like this:
Code:
// With enums for each character setup:
var str = get_strength(member.JOHN);
// Without enums setup:
var str = get_strength(0);
// Now the local variable str holds the bstr value for whichever member is at position 0, you would then go on to use that for a specific calculation, i.e.:
enemy_inst.hp -= str;
So now you can write all sorts of scripts adjusting or returning the different values for the party members. The reason to use an array for this type of thing, just as an example, is say that your party gets cursed and everyone's strength is set to 0, you would simply do this:
Code:
for (var i=0;i<array_length_1d(global.party_member);i++) { // Loop through all your party members
   var pmember = global.party_member[i]; // Store each member into any local variable, I'm using pmember here
   pmember[char_stats.bstr] = 0; // Set the strength to 0
   global.party_member[i] = pmember; // Store the pmember array back into the global.party_member array
}
 

Sabnock

Member
Love a flag, Yes, no? doesn't get more binary than that.

The if statement and flags are the most powerful advancements in human history :D
 

Yal

🐧 *penguin noises*
GMC Elder
Well then, that solves that I guess. Honestly would have missed that for another week, with how scatterbrained I can get.
Which version of 1.4 are you using, more specifically? In 1.4.1773, semicolons are optional on var declarations... I just use them anyway since I'm so used to them being one of the few places where you need them, though :p Build 9999 has a bunch of issues (color constants broken, the new audio system, etc) but 1773 is pretty stable, so if you're using a much older version it could be worth at least considering updating to it.
 

IncuTyph

Member
Which version of 1.4 are you using, more specifically? In 1.4.1773, semicolons are optional on var declarations... I just use them anyway since I'm so used to them being one of the few places where you need them, though :p Build 9999 has a bunch of issues (color constants broken, the new audio system, etc) but 1773 is pretty stable, so if you're using a much older version it could be worth at least considering updating to it.
I'm using 1.4.9999 the professional edition. I got it in a Humble Bundle forever ago.

As for party members being 'in the same position' I was planning to have swappable party members, like there's the 6 you use, but only 3 fight at a time, and you can rearrange the party outside of battle or during. But you'd always play as the MC, who is the first character in the overworld, if that makes sense. I don't know if that would change anything though.
 
Yeah, that's why I said if you wanted to have specific characters in a slot, you could use enums, otherwise just refer to the character with whatever number slot they are. Typically, you wouldn't just have character stats as enums, you would have additional information as well, like char_stats.NAME and char_stats.DESCRIPTION, possibly even other things like char_stats.SPRITE. And when you acquire that party member, you would fill out a new slot in the global.party_member list with an array containing all that information, and then you would cycle through the characters as they become active. So depending on your combat mechanics. For instance, if it's a turn based game with turn order being based on speed, you would do something like this at the start of a "round":
Code:
turn_order = ds_priority_create();
for (var i=0;i<ds_list_size(global.party_member);i++) {
   var pmember = global.party_member[| i];
   ds_priority_add(turn_order,i,pmember[char_stats.BSPD]);
}
Now you have a priority list that contains the indexes (the number that refers to what slot in global.party_member the character is in) of the characters, sorted by their char_stats.BSPD. Then when you want to know which character has their turn next, you would use:
Code:
var member_index = ds_priority_find_max(turn_order);
ds_priority_delete_max(turn_order);
current_member = global.party_member[member_index];
current_member now holds the array containing all the character data for whoever had the highest speed when the priority list turn_order was created. If you call the exact same thing again, you'll get the second highest speed member stored in current_member (this is because we are also deleting the max priority from turn_order after finding out who is max).

I'll just say, creating RPGs that have all these features (optional acquirable characters, a bunch of stats, etc) is going to be relatively complex and involve a lot of tracking of data. Brushing up on how all the different data structures work is a very good idea as they are extremely useful in simplifying complex tasks. You can, of course, create games like this without going down this route, but it's going to be way harder and more convoluted to code.

I mean, sometimes you see massive:
Code:
if (this) {
   if (that) {
      if (this_as_well) {
         if (and_if_that) {
            if (those) {
               if (and_this) {
                  // Do the thing
               }
            }
         }
      }
   }
}
Statements in amateur games and it causes a shudder. Doesn't mean things can't be done that way, just that if you do it that way, you're inviting a world of pain on yourself.
 
Last edited:

Yal

🐧 *penguin noises*
GMC Elder
I mean, sometimes you see massive: Statements in amateur games and it causes a shudder
Case in point:
1590104020378.png

To quote the guy I stole this screenshot from: "this is a perfect example of when to not use an if statement".
 

IncuTyph

Member
I think I can count myself lucky I haven't made an if statement chain that terrifying yet. I'm trying to take notes of what you guys have said/suggested so far, and wording it in a way I can remember, and hopefully this stuff sticks so I can utilize them as needed. Frankly I know I'm probably biting more than I can chew by doing an RPG as a first project, but I feel there's no better way than to just learn by doing, so here I am. Another question I have though is the concept of a finite state machine, specifically for a combat game loop. I'm under the impression that I'd need various scripts that go in a specific order, like one that determines turn order, then one for idling, one for selecting an action, one for executing, and one that either sends you back to the turn order script or ends the battle. Like, that's the general idea, if I'm not mistaken. I think my biggest concern would be the actual entering/exiting battle, putting the world on pause for battles to occur. I would probably have to make a variable for storing current x/y positions for every instance that can move (other overworld enemies, NPCs), and then recall that at the end of the battle. Would that be the general idea? I know this isn't really flag-related anymore, but you guys have been so helpful and I appreciate it.
 

IncuTyph

Member
Ok, so pmember is not any particular member and it's not something that is kept around (hence why it is a local variable, which gets deleted once the event/script/codeblock that it's running in is finished. That codeblock that I gave you is ONLY the setup of the character stats. You would need to set it up using the same method (just incrementing global.party_member[0] to global.party_member[1] and then global.party_member[2], etc) for all the party members you want. The point is that you will then have an array global.party_member, which holds all the info for all your party members. Any time you need to get some info from it, you run a version of the "pmember" section of code, just updating which party member you are targeting like this:
Code:
var pmember = global.party_member[0] // This is your first party member (array indices begin at 0, so first party member is 0, second is 1, etc
var pmember = global.party_member[1] // Pmember now holds the data for your second party member
If you always plan on having the same party members in the same order, you can enum the party_member number and then use those enums to get the member you want like this:
Code:
enum member {
   JOHN, // Enums count up from 0 if you don't assign a value, so member.JOHN is the same as typing 0, it's just easier to understand what it means as text rather than an integer
   SALLY, // Sally is the same as 1, etc
   BOB,
   HUGO
}
var pmember = global.party_member[member.JOHN]; // Now holds the member information from position 0, which in this example is John
So one thing you can do is write some scripts to pull data out from the array, something like this:

get_strength() script:
Code:
///@function get_strength(member_number);
///@description Returns the strength of the member at position "member_number" in global.party_member
///@param {int} member_number The position in global.party_member that you want to access

var member_number = argument0;
var pmember = global.party_member[member_number];
return pmember[char_stats.bstr];
You would run that script like this:
Code:
// With enums for each character setup:
var str = get_strength(member.JOHN);
// Without enums setup:
var str = get_strength(0);
// Now the local variable str holds the bstr value for whichever member is at position 0, you would then go on to use that for a specific calculation, i.e.:
enemy_inst.hp -= str;
So now you can write all sorts of scripts adjusting or returning the different values for the party members. The reason to use an array for this type of thing, just as an example, is say that your party gets cursed and everyone's strength is set to 0, you would simply do this:
Code:
for (var i=0;i<array_length_1d(global.party_member);i++) { // Loop through all your party members
   var pmember = global.party_member[i]; // Store each member into any local variable, I'm using pmember here
   pmember[char_stats.bstr] = 0; // Set the strength to 0
   global.party_member[i] = pmember; // Store the pmember array back into the global.party_member array
}
So, I was thinking about this the last few days, could I set up enemies the same way? I'd probably enum them by name so it would be a lot easier than trying to remember what enemy = what number, but I'm thinking I could set them up that way. Also, the get_str script you suggested; you think it would be possible to use something similar to that to calculate 'actual stats'? My party members (and enemies) have a base stat that's kind of like their growth trend, and an actual stat that scales their stats as they level, similar to Pokemon (which is what I'm basing my formula off of until I can test how OP these values wind up so I can properly adjust), and that formula would be this:
GML:
hp = round((((2*bhp)*lvl)/100)+lvl+10); //This would be the same for mp as well
str = round((((2*bstr)*lvl)/100)+50); // This applies to def-spd as well
and then attacks, etc would be based of those values. For example, if a character's base HP is 100 and their level is 50, their HP would be 160.

EDIT: I decided I was gonna swap out my global.party_member[number] with global.party_member[name] with an enum, so should I do that on a separate script, or can I have 2 enums in the same script? I added it in the same script, but the names of my party don't highlight like a valid variable does, though the stat enum does. If I do need a second script for the second set of enum, do I need to call the other script or have them call each other to 'connect' them?
EDIT 2: Does placement within the script matter? Like, if I had the enum to establish names before the enum that establishes stats, and then the var pmember arrays, should that work? That was how I had them before noticing the names weren't becoming 'valid' variables.
 
Last edited:
Top