Is there any way to find the size of an array through a trigger? I tried making a custom script of:
gv_array.size()
but it didn't work. :( I'm basically trying to do this for future debugging concerns with "catching" exception and also to get remove some of magic numbers, so I'd prefer not making a variable if I can get away with it, otherwise, magic numbers and strange looking default error messages it is.
Galaxy is not object orientated, so .size() wouldn't work anyway..
There's no way to get the size of an array just by having the array, but in programming Constants are often used to keep track of that.
E.g. when I make a make dialog screens for my 12-player map I might need
1x Dialog for everyone
5x Dialog Items for everyone
2x Some integers for everyone
So I set my Players constant to 12 and then make sure I declare the dialog variable size as 1x12, the dialog item variable size as 5x12 and the integer variable size as 2x12.
Not only do you get rid of magic numbers (somehow), but you can get the max size of that array by knowing the players constant (12) and the number of things you store in that array (1,2,5, etc).
I was figuring I'd need to resort to what you've said, but I figure if it were possible to do a [].size() or similar, it wouldn't hurt. The magic numbers that I'd get rid of are in for loops, ex:
for (i=0; i+=1; i<12). The magic number, obviously, being 12 that could be replaced with MAX_PLAYERS.
this is really possible? cause in gui its impossible to create an array with size of an int variable, there you must enter specific values, what really sucks.
this is really possible? cause in gui its impossible to create an array with size of an int variable, there you must enter specific values, what really sucks.
Yeah, as long as you're using a const int, it can be referenced for an array size in raw galaxy
@Nevir24:
I tried using a const int inside of my a record variable and errors popped up. -.-' The error was something like "The variable is not a record type". I swear, there are so many bugs with records. It works fine when const isn't checked, you just have to remember to never change the value anywhere.
@Mille25:
Yeah, it's possible inside of galaxy script. I'm considering doing it this way so that if someone changes the value of MAX_PLAYERS, the array size is automatically updated and you don't have to change both the array size and the constant value. I assume that it's not allowed in the GUI because the declarations of variables, triggers, and actions are non-linear. Adding this feature would add some form on linearity to it (you must set the constant before you set the array size). There's no way for the compiler to know at what point the constant is declared (at initialization or within a trigger or wherever). I agree though, it'd be nice to allow array sizes to be declared with a variable.
You can't just tick the "Constant" checkbox on a record variable. It would not make the integer constant but the record itself. That will give you a bug of course - constant records would be so totally useless xD.
In GUI there doesn't seem to be ANY way of using a constant to declare the array size.
..And they told us we could do everything with GUI that we could do with Galaxy ... ^.^
PS: About the linearity of GUI - if you make some triggers, variables etc in GUI and look at the custom script you'll see that it's very linear! It will always load in this order: Libraries, Globals, Triggers, Map Init.
It'd be so totally easy for the editor programmers to just add all the constants infront of the normal variables. And PeNG no problemo.
Here's exactly what I have so you can see what I meant:
BaseSettings<Record>MAX_BASES=10<Integer>MAX_DRONES=18<Integer>DEBUG_ON=false<Boolean>waveGroup=NoUnitGroup<UnitGroup>defenseGroup=NoUnitGroup<UnitGroup>waypoint=NoPoint<Point>...setting<BaseSettings>bases[10] = No Region <Region> //Thread is about this variable.
I was trying to set the MAX_BASES, MAX_DRONES, and DEBUG_ON variables to constants when the errors were popping up. The setting variable is the only instance of the Base Settings record. Really, the only reason I made the 'base settings' record was because I have about a dozen variables (and constants) that I don't want to see every time I open up the list of variables. I'm not sure I get the reasoning why constants should be disabled within a record if the user wants it that way. Yeah, you create a new copy of the same constant each time the record is declared, but if the user wants it that way, what's the problem? While I haven't tested it, I'd assume setting <Base Settings> wouldn't cause an error if you set it to a constant so that you can make a record of constants, now that I think about it... Scratch that, I just looked at the Galaxy code, so this isn't possible either.
And about the linearity of the triggers, variables, ect, yeah, they're declared linearly, but what I meant is that Blizzard added some restrictions to it so that there's nothing you can do to make the order of them make a difference in game. I'd be all for removing those restrictions, however. In essence, Blizzard made it more noob-friendly by adding these limitations.
Is there any way to find the size of an array through a trigger? I tried making a custom script of:
gv_array.size()
but it didn't work. :( I'm basically trying to do this for future debugging concerns with "catching" exception and also to get remove some of magic numbers, so I'd prefer not making a variable if I can get away with it, otherwise, magic numbers and strange looking default error messages it is.
Galaxy is not object orientated, so .size() wouldn't work anyway..
There's no way to get the size of an array just by having the array, but in programming Constants are often used to keep track of that.
E.g. when I make a make dialog screens for my 12-player map I might need
1x Dialog for everyone
5x Dialog Items for everyone
2x Some integers for everyone
So I set my Players constant to 12 and then make sure I declare the dialog variable size as 1x12, the dialog item variable size as 5x12 and the integer variable size as 2x12.
Not only do you get rid of magic numbers (somehow), but you can get the max size of that array by knowing the players constant (12) and the number of things you store in that array (1,2,5, etc).
In pure custom script you can conveniently write:
Doh, hope that helped somehow :P
I was figuring I'd need to resort to what you've said, but I figure if it were possible to do a [].size() or similar, it wouldn't hurt. The magic numbers that I'd get rid of are in for loops, ex:
for (i=0; i+=1; i<12). The magic number, obviously, being 12 that could be replaced with MAX_PLAYERS.
edit: The "+ +" (no space) markup is annoying.
@s3rius: Go
this is really possible? cause in gui its impossible to create an array with size of an int variable, there you must enter specific values, what really sucks.
Yeah, as long as you're using a const int, it can be referenced for an array size in raw galaxy
thats cool, but then they should add this to gui.
@Nevir24: I tried using a const int inside of my a record variable and errors popped up. -.-' The error was something like "The variable is not a record type". I swear, there are so many bugs with records. It works fine when const isn't checked, you just have to remember to never change the value anywhere.
@Mille25: Yeah, it's possible inside of galaxy script. I'm considering doing it this way so that if someone changes the value of MAX_PLAYERS, the array size is automatically updated and you don't have to change both the array size and the constant value. I assume that it's not allowed in the GUI because the declarations of variables, triggers, and actions are non-linear. Adding this feature would add some form on linearity to it (you must set the constant before you set the array size). There's no way for the compiler to know at what point the constant is declared (at initialization or within a trigger or wherever). I agree though, it'd be nice to allow array sizes to be declared with a variable.
@Azkit: Go
You can't just tick the "Constant" checkbox on a record variable. It would not make the integer constant but the record itself. That will give you a bug of course - constant records would be so totally useless xD.
In GUI there doesn't seem to be ANY way of using a constant to declare the array size.
..And they told us we could do everything with GUI that we could do with Galaxy ... ^.^
PS: About the linearity of GUI - if you make some triggers, variables etc in GUI and look at the custom script you'll see that it's very linear! It will always load in this order: Libraries, Globals, Triggers, Map Init.
It'd be so totally easy for the editor programmers to just add all the constants infront of the normal variables. And PeNG no problemo.
@s3rius:
Here's exactly what I have so you can see what I meant:
I was trying to set the MAX_BASES, MAX_DRONES, and DEBUG_ON variables to constants when the errors were popping up. The setting variable is the only instance of the Base Settings record. Really, the only reason I made the 'base settings' record was because I have about a dozen variables (and constants) that I don't want to see every time I open up the list of variables. I'm not sure I get the reasoning why constants should be disabled within a record if the user wants it that way. Yeah, you create a new copy of the same constant each time the record is declared, but if the user wants it that way, what's the problem?
While I haven't tested it, I'd assume setting <Base Settings> wouldn't cause an error if you set it to a constant so that you can make a record of constants, now that I think about it...Scratch that, I just looked at the Galaxy code, so this isn't possible either.And about the linearity of the triggers, variables, ect, yeah, they're declared linearly, but what I meant is that Blizzard added some restrictions to it so that there's nothing you can do to make the order of them make a difference in game. I'd be all for removing those restrictions, however. In essence, Blizzard made it more noob-friendly by adding these limitations.