I wasn't sure if this was known or not, but since it isn't in current IESDP, I thought I'd mention that in BG1: TotSC, the names of your Globals shouldn't be longer than 32 bytes.
The script will still be compiled (and can be properly decompiled), but the game will ignore the trigger/action that uses the global.

The following script block uses a global which name is exactly 32 characters long. The creatures appear in the game normally.


In this block the variable's name is longer than 32 characters. The creatures start to appear in the game in an infinite loop.

This was with 33 characters, and my tests proved that the same happens with more characters as well.

Normally it's pointless to use so long variable names, but I think it is important to know that there is such limit.

As I've said, I'm not sure if this has been already known or not.
Additionally, I am wondering if the same variable length limit applies for BG2 / other IE games...

According to what you are saying the game does not ignore the action but will ignore the setting of the global variable.

If the creatures appear in the game but will not stop spawning it means the script action has run but is still True...ergo the global was not incremented.

yes?

It's noted in the format descriptions for ARE and GAM (and possibly EFF, since LOCALS are all internal EFF data to the creature object). The fields to store the variable name are all 32 bytes in length. I don't know if anybody has checked the behavior to see if it's just truncated on set (only the first 32 characters will be written), or if it doesn't get set at all, though.

If you check the IESDP, you'll see that the baldur.gam structure has finite bytes for a variable name (32 for global and area, 24 for locals). Hence, the second script was incrementing tha variable BW05_CreaturesSummonedinMagicTra and checking for BW05_CreaturesSummonedinMagicTrap, hence the loop.

Right, I was incorrect in my statement. (I actually meant that the action didn't work properly.)


Checking the structure of baldur.gam would have been a good idea. Anyway, I think that in the next version of IESDP these length limits could be mentioned in the Variables section.

Why does only one global get truncated?

If both are over 32 should they both not get truncated or does the trigger portion ignore the length?

Does that make sense?

the global name is stored in a 32 byte space, so only 32 characters in memory (the SetGlobal part).
However, I'd wager that the devs at bioware used the strcmp functions to scan the variable listing (searching the entries in baldur.gam until you find one equal to the one you're searching for).
So, when parsing the script you'll never find a value for BW05_CreaturesSummonedinMagicTrap, since the only variable which was set is BW05_CreaturesSummonedinMagicTra.

Of course, we might have Weimer limit the lenght of the variable names to 32 bytes to hide similar problems

Yeah I thought about the weidu thing last night too.

That could be a helpful Feature for those who likereallylongvariablenames.

Actually not, since one could use the variables
1234567890123456789012345678901234567890 (40 chars) and 123456789012345678901234567890123456789 (39 chars)

and the game will think they are the same.

Much better if WeiDU chocked (or gave warnings) about these things.

That's what I meant: if weidu didn't accept long variable names the modder would be forced to work in the correct way 32 bytes or less.

If the length is limited in weidu to 32 bytes it could provide a warning/error as to why!

Maybe my post wasn't particularly clear...sorry.

I do know this, and, as has been noted, it is in the IESDP.

It may not be in the right place in the IESDP, but .. thats.. umm.. to encourage people to read the entire thing.
Obviously

There's also a limit as to how high you can set variables, which I don't think is listed in the IESDP though.

Lemme guess... 4 signed bytes?

Well, actually, I'm not sure.
I think I recall a conversation with Avenger, where he stated the maximum value was lower than this. I also think I remember my testing showing a maximum value significantly higher than this (and when the max limit was passed, there value was not set to the max, or wrapped around, it just entered a pattern I don't remember).

Testing would be welcome. 4 signed bytes would be a good place to start

This means that you will mention the size limits in the Variable section too in the next release, right?
Remember, IESDP is for (starter) modders as well, and not for programmers.

That's a tricky question, since most compilers won't let you get away with values larger than 2^32. Since the variable value is signed, it should give a range from -2^31 to 2^31 - 1 (if that's indeed the maximum size). Conveniently, this range also applies to STATEs and whatnot.

If the size can be larger, it wouldn't really make much difference as the current compilers will do funky things once you get too large (IIRC, NI will use the unsigned value, and WeiDU will fail).

Variables (globals/locals) are signed dwords (4 bytes)
Some stats are unsigned.