Longer variable names: bad or okay?

[Creepin]

I remember reading in an ancient times that the longer variable names are the more they slow down script parsing by game engine and thus slow down the game, so I have made my best ever since to stick with 8 symbols variable names even though SetGlobal("GOBLIN_QUEST_DID_DOG_SMELLED_MEDALLION","GLOBAL",1) is much more obvious and easy to track than SetGlobal("CRVAR034","GLOBAL",1). I believed it without doubt for many years but finally decided to ask around, was this idea regarding length of variable names any valid or there's no real reason to stick to shorter names?

[argent77]

I don't know about slowdown effects (which would be rather insignificant compared to checks like PartyHasItem("xyz")). However, for technical reasons variable names can't be longer than 32 characters.

[Roxanne]

I don't know about slowdown effects (which would be rather insignificant compared to checks like PartyHasItem("xyz")). However, for technical reasons variable names can't be longer than 32 characters.

The rumour persists for a long time...even though there always existed those SetGlobal("SPRITE_IS_DEADcvfist21","global",0).which are pretty long even in old vanilla games.

 

At least in vanilla BG2EE, longer variables are used throughout, e.g. IncrementGlobal("bd_poison_dsc_supplies","global",1).

In my mods I have always used globals that were (at least for myself) meaningful enough to get an idea what they stand for - never any issues even in the very big BGT or EET installations I used that could be assigned to names of a global.

Slowdown effects always had other reasons, yes, inventory checks being the most common, followed by animation issues, not removed invisible creatures from spells and some others.

[Jarno Mikkola]

The rumour persists for a long time...even though there always existed those SetGlobal("SPRITE_IS_DEADcvfist21","global",0).which are pretty long even in old vanilla games.

erhm, you do understand that the characters before the ...cvfist21 is 14 characters... so there's plenty to have as the death variable... as 32-14 = 18 ... math.

[Creepin]

Thank you for your prompt replies!

I don't know about slowdown effects (which would be rather insignificant compared to checks like PartyHasItem("xyz")). However, for technical reasons variable names can't be longer than 32 characters.

Even though variable name effect (if any) can't be nearly as ruinous as PartyHasItem's carelessly crammed in baldur.bcs & co. (grrrr!), the more reasons to try to help IE to cope with all that added joy. BTW I didn't knew about 32 symbols limitation, thank you for bringing that up.

The rumour persists for a long time...even though there always existed those SetGlobal("SPRITE_IS_DEADcvfist21","global",0).which are pretty long even in old vanilla games.

At least in vanilla BG2EE, longer variables are used throughout, e.g. IncrementGlobal("bd_poison_dsc_supplies","global",1).
In my mods I have always used globals that were (at least for myself) meaningful enough to get an idea what they stand for - never any issues even in the very big BGT or EET installations I used that could be assigned to names of a global.
Slowdown effects always had other reasons, yes, inventory checks being the most common, followed by animation issues, not removed invisible creatures from spells and some others.

So you heard that rumour too, that's good, at least now I'm sure that wasn't the figment of my imagination! I thought of vanilla variables but these were honestly used with no need to consider BG being bloated up to 40Gb and having checks over checks over checks in its scripts. Thanks for the sharing field experience though - this might be the closest to full-fledged study I could have asked for, and considering the size of your mod this holds quite some credibility.

erhm, you do understand that the characters before the ...cvfist21 is 14 characters... so there's plenty to have as the death variable... as 32-14 = 18 ... math.

Jarno, the point was not whether DV will fit into the rest of 32 symbols or not but whether it's ok to use variable names longer than 8 symbols, and at that I believe SPRITE_IS_DEADcvfist21 served as a good example by being x2,5 longer.

[Ardanis]

SPRITE_IS_DEADscritpname global is automatically set each time a creature with scriptname dies and can be later checked with Dead("scriptname") shorthand. So no, it's not an example of SetGlobal("very_long_var_name_here","global",1) case, but simply a scripting hack to adjust the death counter without actually killing/resurrecting someone.

[Avenger]

So, the only reason to ever use 8 chars or shorter variables is that some v1 effects cannot store longer variable names.

 

32 is the theoretical maximum for any variable name. 24 is the maximum if you want to set a variable via effects, like opcode 265. 18 is the maximum length of a scriptname (thus making a 32 max. "death variable"). And 8 is the maximum length of a variable if you don't want to use opcode 265 as external effect. (You can use only v1 effects in items/spells, but you can always call an external .eff).

 

 

 

And finally, 10 is the maximum length of a 'script name' if you want to hack its "death variable" from an effect (24-14) Obviously, you will have to resort to external effects :D

 

 

[Creepin]

Wow that is whole another level of the issues to consider I wasn't even aware about! Thank you for your analysis Avenger!

[Ardanis]

By the way, this is only half true:

stick with 8 symbols variable names even though SetGlobal("GOBLIN_QUEST_DID_DOG_SMELLED_MEDALLION","GLOBAL",1) is much more obvious and easy to track than SetGlobal("CRVAR034","GLOBAL",1)

 

If you got a very big quest (or even several ones) with a lot of events and stages to track, you're better off with systemic naming to keep it organized and maintainable. The SoD's bd_poison_dsc_supplies is actually a poor example of naming, compared to e.g. subquest variables that use quest ID label as a prefix and follow with a brief one-word description. Of course, this is only relevant if you work on something comparable in size and need to search in files often.