Question re: .CRE Scripts

[erebusant]

In the .CRE files you have your override, class, race, general, and default scripts in that order. Is there a good writeup of specifically what the purpose of each script slot is for, and if more than one is used, are they processed in a particular order of importance, etc, etc?

[devSin]

They're processed top-down (see SCRLEV or similar IDS for the order). The only purpose of the slots is to have different "levels" for scripts; they're all basically handled the same.

 

When a character joins the party, only the OVERRIDE slot is preserved (the other slots are reassigned).

[aVENGER_(RR)]

While we're at it, what is the intended purpose of the SPECIFICS script slot?

[devSin]

ARE override. Something to attach to a specific instance of a CRE in a particular ARE; stored in the CRE header in the ARE.

[aVENGER_(RR)]

Ahh yes, that makes perfect sense, I've always wondered why the SPECIFICS slot doesn't show up in the CRE file. Thanks a bunch for clarifying this!

 

BTW, I think I've actually seen a few instances where such scripts were used (mostly in IWD1) but I wasn't aware of all the implications involved. Very intriguing. I wonder what happens if the creature in question leaves the area where its SPECIFICS script was assigned? Also, would using ChangeAIScript("somescript",SPECIFICS) permanently modify the current ARE in the savegame?

[devSin]

A) If the creature leaves, the header might be purged (SPECIFICS won't be preserved)*

B) If you set SPECIFICS, the header should be updated

 

*untested -- moving between areas is complex; the header might be carried along with the CRE (which moves in an inactive fashion with the party to every new master area until the destination ARE is visited) and might actually be used, meaning the SPECIFICS slot would be preserved. You could modify AR0602 to give Malaaq a SPECIFICS script and start a new game (where he'll MoveBetweenAreas() AR0601); visiting and saving in AR0601 will give the answer (opening in NI, his header will either have the script or not).

 

SPECIFICS is used plenty in BG2 -- if you want a particular character in a particular area to do something special (but don't want to make a new CRE with different scripts and don't want to override any of the normal 5 slots from the CRE file), the SPECIFICS slot is the easiest way to get it running.

 

Note that the character headers in the ARE don't have the same slot order as in the CRE file; IESDP may have been updated already with the correct order, and there'll be a thread around here somewhere where I listed it (scripts are still processed in the same order, but the header has them defined in a different order).

[aVENGER_(RR)]

SPECIFICS is used plenty in BG2 -- if you want a particular character in a particular area to do something special (but don't want to make a new CRE with different scripts and don't want to override any of the normal 5 slots from the CRE file), the SPECIFICS slot is the easiest way to get it running.

 

Nifty! I think this is very useful info and should probably be mentioned somewhere in the IESDP if it's not in there already. Global AI enhancing mods such as SCSII would probably benefit from it the most.

 

Note that the character headers in the ARE don't have the same slot order as in the CRE file; IESDP may have been updated already with the correct order, and there'll be a thread around here somewhere where I listed it (scripts are still processed in the same order, but the header has them defined in a different order).

 

I guess the correct order the one which DLTCEP and NI list? BTW, that reminds me, where can I get your updated version of NI?

[erebusant]

So basically then, if you have 1 script running in the override slot, and another running in the class slot, they'll both run and perform the functions they call out, but if they both happen to be huge like some of the BP scripts along with some of the SCSII scripts you could run into some serious lagging issues?

[devSin]

They don't run concurrently; the game starts with the first slot, and if it doesn't find anything to do there, it'll move on to the next, and so on.

 

You can get some slowdown with overlarge scripts, but it's more a feature of poorly written scripts (or scripts that are more complex than the engine really likes to handle) than size -- the engine can cut through scripts like Baldur.bcs, a big area script like Ar4500.bcs, and a complex creature script like Jaheir.bcs, all running at the same time, without breaking a sweat. Note that every single creature runs its own instance of a script (so if you've got 50 CREs with Shout.bcs, the engine is running 50 copies of the script independently), which can get a little laggy with large AI scripts and large numbers of creatures.

[DavidW]

You can get some slowdown with overlarge scripts, but it's more a feature of poorly written scripts (or scripts that are more complex than the engine really likes to handle) than size -- the engine can cut through scripts like Baldur.bcs, a big area script like Ar4500.bcs, and a complex creature script like Jaheir.bcs, all running at the same time, without breaking a sweat. Note that every single creature runs its own instance of a script (so if you've got 50 CREs with Shout.bcs, the engine is running 50 copies of the script independently), which can get a little laggy with large AI scripts and large numbers of creatures.

 

I'd be interested in advice on this - I think SCSII's longest scripts are about 18,000 lines, and while they don't run slow on my computer, I've had some reports of them doing so on older computers. Is this likely to be because of a flaw in the writing or just because it's so long? (I've attempted to optimise it in various ways, how successfully I don't know...)

[devSin]

At that size, you're probably not going to be able to make things too much faster (in this case, you're likely hitting the complexity wall).

 

Shuffling of triggers could help, and some condition that may be true in the majority of time spent in the script (similar to the !Allegiance(Myself,255) THEN NoAction() blocks of certain scripts) could be used to keep the engine from continuously evaluating the whole thing; with the former, though, you're probably looking at shaving fractions of seconds off evaluation time, and the latter might lead to other issues within the script or with other scripts the character has at different levels.

[DavidW]

At that size, you're probably not going to be able to make things too much faster (in this case, you're likely hitting the complexity wall).

 

Shuffling of triggers could help, and some condition that may be true in the majority of time spent in the script (similar to the !Allegiance(Myself,255) THEN NoAction() blocks of certain scripts) could be used to keep the engine from continuously evaluating the whole thing; with the former, though, you're probably looking at shaving fractions of seconds off evaluation time, and the latter might lead to other issues within the script or with other scripts the character has at different levels.

 

Thanks. I make some attempt to do the former and quite a lot of attempt to do the latter (in fact, this requires quite a bit of shuffling of some creatures' script lists, because it means any script lower-priority than my script is blocked from running. I eventually ended up writing some code to automatically list all creatures with this issue.)

[devSin]

I guess the correct order the one which DLTCEP and NI list? BTW, that reminds me, where can I get your updated version of NI?

Sorry. I was going to update the build to my very latest for you, but I completely forgot. I've updated the build and spent the last 10 minutes trying to find this post, so I guess that makes us even.

 

The latest version of Near Infinity (v1.33b19) can be obtained here. It contains several modifications to the "official" 1.33b19 sources, all of which should be functioning correctly.

 

The source code for this build can be obtained here. Be sure to read the license if you want to redistribute or publish any further modifications.

 

This will truly be my final build (it contains only a few small changes over the last build, which was like a year or so ago, so you can tell that I'm not actively maintaining it or even thinking about it more than a single day each year). You can post anywhere on the forums here if you encounter any issues; it's unlikely that a problem will be my fault, but if it is, I'll make every effort to fix it.

[Gabrielle]

Not on topic but I just downloaded that since its a newer version from your link and I get an error saying could not find main class.

[aVENGER_(RR)]

I'm getting the same error.

 

Perhaps a different version of Java is required?