Jump to content

Home

Local variables


Xcom

Recommended Posts

(This is not to derail T7's thread.)

I just have a few questions regarding local variables after stoffe posted:

 

Originally posted by stoffe -mkb- in the other thread

Agreed, you have to check if they are not already used for something else. Local booleans below 30 and above 65 are used by the Creature AI, and is best not messed with on creatures (unless you are altering the AI of course).

 

Those between 30-64 are in the "designer range" which means they should be used for this kind of thing. But they may (or may not) be in use to keep track of other things already, so you'll need to check the object in question.

 

For example 57 is used on containers to keep track of if random loot has been generated for it, so it would be a bad idea to use that for anything else on objects with an inventory.

 

I used 40 in my example since it seems to be used by many triggers to keep track of if their onenter script has been fired once.

 

Useful to know. Local vars are something I can't get much info on.

 

So a few additional question, stoffe (or anyone else who knows :) )

 

Firstly, are these values being saved when you save the game? If so, where..?

 

What are the ranges for local numbers?

For example, would this affect the same variable:

 

SetLocalBoolean(object, 40, TRUE);

SetLocalNumber(object,40,1);

 

or.. not?

 

Lastly, does every object have the same number of available indices for these variables? Like for instance, creatures and area objects?

Link to comment
Share on other sites

Originally posted by Xcom

Firstly, are these values being saved when you save the game? If so, where..?

 

I'm by no means an expert on this kind of thing so I may be wrong, but this is how I understand it...

 

Locals work much like globals, but unlike the globals which are saved on a "per game" basis, locals are saved on a "per object" basis. Objects can be creatures, placeables, triggers or even Areas or the Module itself.

 

As such, any locals are set on an object and hold their value only for that object. The values are saved when you save the game, as long as the object itself remains in the savegame. The game clears out areas you can't return to continually to reduce savegame size.

 

If you mean where more physically in the GFF-file I believe it's under the category "SWVarTable" for each object. Objects are stored in the GIT file for each area present in the save game (except party members and the PC who are saved separately). Locals set on the Area are stored in the "SWVarTable" directly under the top-level of the GIT, while Locals set on the module are stored in the module.ifo.

 

Originally posted by Xcom

What are the ranges for local numbers?

For example, would this affect the same variable:

 

SetLocalBoolean(object, 40, TRUE);

SetLocalNumber(object,40,1);

 

Don't know what the upper range is. The Creature AI uses local booleans up to 99 or so (with the gap of vars reserved for designer use mentioned before). Probably 128 or 255, but that's just a guess.

 

Local numbers and booleans are handled separately. The two 40s in your example would be two unique values.

Link to comment
Share on other sites

Good post stoffe. There are around 30 local numbers and 100 local Booleans. Be careful with local variables, because the game will let you use higher index numbers even though they are invalid. But it will not actually store anything.

 

So the command: SetLocalNumber(OBJECT_SELF, 50, 10) will compile and run but the command GetLocalNumber(OBJECT_SELF, 50) will not return 10. It will return either 0 or a random number.

Link to comment
Share on other sites

Originally posted by Darkkender

Wow, this information is actually very handy to have.

 

 

No kidding? :p

 

Thanks all.

 

So, I went and reverse-engineered several save games to look at the git files. Indeed, they have SVarTables and most of them have defined ByteArray for 0 to 31 (or something). I think this is what beancounter was talking about, in regard of having about 30 local numbers.

 

However, there is also a BitArray defined, and the values are of the type DWORD. There are only 5 or 6 of those thhough. Is this used for booleans?

Link to comment
Share on other sites

Originally posted by beancounter

I am really not sure.

 

Try looking at this document:

 

http://nwn.bioware.com/developers/Bioware_Aurora_CommonGFFStructs.doc

 

Check out section 3.

 

The Local Booleans should be stores in the game as an int data type.

 

The best way to find out is to test it out. It should be fairly easy to do.

 

That document probably describes how it works for Neverwinter Nights though, which is slightly different from KotOR/TSL.

 

In NWN you don't use a fixed number of indexes for Locals, but rather a string identifier instead, like with Globals in KotOR (but unlike KotOR Globals those string identifiers aren't defined in a 2da file but are freely set in the scripts themselves). NWN also didn't have a dedicated boolean type of Locals, normal Ints were used for those purposes.

 

Where in KotOR you'd say, for example:

 

SetLocalBoolean(OBJECT_SELF, 57, TRUE);

 

..the NWN Way would be:

 

SetLocalInt(OBJECT_SELF, "RandomLootGenerated", TRUE);

Link to comment
Share on other sites

Originally posted by beancounter

The best way to find out is to test it out. It should be fairly easy to do.

 

Not as easy as one would think.

 

I just found out that, apparently, you can't manipulate locals on a freshly made object. For example, the following will not work (as the number won't be set).

 



void main()
{
  object oObj = CreateObject(OBJECT_TYPE_PLACEABLE, "someplc",GetLocation(GetFirstPC()));

  SetLocalNumber(oObj, 30, 99);

}

 

However, if you call CreateObject, then save your game, then assign local, then it WILL work. :giveup:

I guess this means that locals can only be used on objects that are defined within the module files. I don't know if it only applies to placeables or all objects, but I was testing with a placeable.

 

Btw, local number ranges seem to be up to 30 (maybe 31, not sure exactly). Beyond that, there appears to be a gap.. and I don't know if it's infinite.

Link to comment
Share on other sites

Originally posted by Xcom

Not as easy as one would think.

 

I just found out that, apparently, you can't manipulate locals on a freshly made object. For example, the following will not work (as the number won't be set).

 



void main()
{
  object oObj = CreateObject(OBJECT_TYPE_PLACEABLE, "someplc",GetLocation(GetFirstPC()));

  SetLocalNumber(oObj, 30, 99);

}

 

However, if you call CreateObject, then save your game, then assign local, then it WILL work. :giveup:

I guess this means that locals can only be used on objects that are defined within the module files. I don't know if it only applies to placeables or all objects, but I was testing with a placeable.

 

Btw, local number ranges seem to be up to 30 (maybe 31, not sure exactly). Beyond that, there appears to be a gap.. and I don't know if it's infinite.

 

XCom, try creating a custom creature utc and modify the spawn in script to set the local number. Then create that custom creature.

Link to comment
Share on other sites

XCom, try creating a custom creature utc and modify the spawn in script to set the local number. Then create that custom creature.

 

Hmm, it worked that way. :confused:

 

So, where does that leave us? The locals can be set in OnSpawn script for creatures even if thet are not pre-defined in the GIT file - so much is clear. But, placeables don't have spawn event, do they?

I sure hope that different object types don't have their *own* way of handling the locals.

Link to comment
Share on other sites

Originally posted by Xcom

Hmm, it worked that way. :confused:

 

So, where does that leave us? The locals can be set in OnSpawn script for creatures even if thet are not pre-defined in the GIT file - so much is clear. But, placeables don't have spawn event, do they?

I sure hope that different object types don't have their *own* way of handling the locals.

 

The only way to find out is to test it out. So get busy:D

 

Edit-I think placeables have a spawn in script

Link to comment
Share on other sites

Another test to try -- splitting the CreateObject from the SetLocalNumber function:

 

// spawn_utp.nss
void main()
{
  object oObj = CreateObject(OBJECT_TYPE_PLACEABLE, "someplc",GetLocation(GetFirstPC()));
ExecuteScript ("script2",oObj);
}

// script2.nss
void main ()
{
  SetLocalNumber(OBJECT_SELF, 30, 99);
}

 

From the results of your previous test, it seems the game engine needs a moment or two to initialize the local variable tables for recently created objects... (?)

 

Perhaps a simple DelayCommand function would do the trick:

void main()
{
  object oObj = CreateObject(OBJECT_TYPE_PLACEABLE, "someplc",GetLocation(GetFirstPC()));
 DelayCommand(2.0,   SetLocalNumber(oObj, 30, 99));
}
Link to comment
Share on other sites

Originally posted by tk102

Perhaps a simple DelayCommand function would do the trick:

 

 

No, I don't think so. I wasn't testing with exactly the same script as I posted above.

 

I was using a band to spawn placeable (first usage), and second usage would assign and retrieve the number:

 


void main()
{
object oBj = GetObjectByTag("plc_tag");

if (GetIsObjectValid(oBj))
{
	SetLocalNumber(oBj, 30, 99);
	SendMessageToPC(GetFirstPC(), "Local 30="+IntToString(GetLocalNumber(oBj,30)));
	return;
}

oBj = CreateObject(OBJECT_TYPE_PLACEABLE,"someplc",GetLocation(GetFirstPC()));
}

 

That didn't work.

Perhaps, the delay is needed between assigning the value and retrieving it, but I can't imagine that to be the case.

 

Another curious detail...

 

In the example above,

 

SetLocalBoolean(oBj, 64, TRUE);

SetLocalBoolean(oBj, 128, TRUE);

 

seemed to work! The GetLocalBoolean returned correct values (the values I specified).. but only at those indices 64 and 128. I really can't explain it. All other indices for booleans seemed to return random nonsense values.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...