Some questions about scripts

[jastey]

Maybe it's the "PartyRested()" trigger which gives only true right after the rest ends so if it's at the beginning of the baldur.bcs it gives true but if it's at the end of the script the time passed might be too long already - or something.

Keep in mind that other mods might add to the top after yours, so there might be a risk that the script block might not get executed in a mega mod install.

[Luke]

Maybe it's the "PartyRested()" trigger which gives only true right after the rest ends so if it's at the beginning of the baldur.bcs it gives true but if it's at the end of the script the time passed might be too long already - or something.

Keep in mind that other mods might add to the top after yours, so there might be a risk that the script block might not get executed in a mega mod install.

What do you mean by the time passed might be too long already? Edited November 1, 2018 by Luke

[jastey]

I meant the "PartyRested()" trigger only gives true if the script block is called the moment after the party rested, but not some instances later.

[Jarno Mikkola]

... trigger only gives true if the script block is called the immediate moment after ...

Fixed tht for you.

So if the script has any true statement before this one and that one doesn't have a CONTINUE() in it, then the rest of the script is not "read", nor can it interact with the rest of the game. That's how the games scripts work.

[subtledoctor]

What do you mean by the time passed might be too long already?

Scripts take a nonzero amount of time to process. BCS is not very efficient code, it's a bunch of IF->THEN scripting that has to run sequentially. Scripts can be triggered once per second (e.g. baldur.bcs) or triggered by external circumstances (e.g. creatures being created) etc. If a script is triggered before that last instance of it has finished processing, it can simply skip arguments at the end.

 

Example, code up a bunch of stat bonuses that operate by script with the CheckStat trigger. The bonuses can end up blinking in and out of existence as the game tries and fails to keep up with all the triggers. That's why nobody ever modded stat bonuses in the last 20 years.

 

This is why I'm constantly advising people to avoiding relying on scripts when it's possible to use spell effects instead.

[Jarno Mikkola]

Scripts take a nonzero amount of time to process.

This is not true. One script can run 15 timer per second(half the frames per second infact). What's not nonzero taking is the THEN --- END process, that can very well take several rounds of effect time to complete, where the effected user of .bcs does nothing else, ever, as it's action list is occupied.

 

The IF part of a script does 1 thing, checks if variable x is true, from RAM... this is what your computer does all the time. That's why it's fast.

Edited November 2, 2018 by Jarno Mikkola

[DavidW]

No, sufficiently many IF blocks evaluated 15 times per second can slow the game to a crawl (at least on vanilla BG2) even if none of them actually fire. Avoiding that problem is a significant design constraint on SCS mage scripts, which are 10,000 to 20,000 lines long; I did fairly extensive testing on it back in the early days of SCS.

[subtledoctor]

EDIT - stated better than I could.

Edited November 2, 2018 by subtledoctor

[Jarno Mikkola]

I did fairly extensive testing on it back in the early days of SCS.

Yeah, and how much of ram did you have by then ? In allowed usage. 16Gb's ? Cause the entire game didn't take 16 Gb's. Did you even make notes on your memory parameters etc when you tested the thing by then ? + OS, .exe etc related to memory utilization. Remember, the non-EE game ran on a Windows 95. Which is why the game files can only be 8 characters long(+3 characters in the extension). And the .bif's are copied to the cache folder if it has enought allowed space.

Now, there's no doubt that heavy script load put the non-EE game to it's knees, but that shouldn't be much of a problem today with EE, as the game can use the extended write space and all(Physical Address Extension).. this mean also that the game doesn't need biffing. If you have a 64 bit x86 processor.

@std: As your Leopard is one.

[DavidW]

Im not going to waste my time with this.

[Luke]

No difference that I'm aware of.

So they both remove the active CRE from the GAM file, right?

[Luke]

@DavidW

I need your help: I'd like my CRE to spam a certain SPL every (say) two rounds only if there is at least one humanoid (but RACE != mephit) in weapon range. The target of that SPL must be one of those humanoids.

How can I do this?

EDIT: Solved (hopefully...)

Edited December 30, 2018 by Luke

[Luke]

@Wisp

It seems WeiDU (version 246) cannot parse things like this:

!StateCheck(NearestAllyOf(Myself),STATE_STUNNED | STATE_HELPLESS)

Are you aware of this bug?

Edited January 9, 2019 by Luke

[Jarno Mikkola]

1 hour ago, Luke said:

@Wisp

It seems WeiDU (version 246) cannot parse things like this:

!StateCheck(NearestAllyOf(Myself),STATE_STUNNED | STATE_HELPLESS)

Are you aware of this bug?

Yeah, that's not a scripts IF-THEN clause that can be parsed, but this is:

OR(2)
!StateCheck(NearestAllyOf(Myself),STATE_STUNNED)
!StateCheck(NearestAllyOf(Myself),STATE_HELPLESS)

You might be associating a different type of script making algorithm to the weidu's actual one, where it just takes a text coded .baf file and compiles it as a .bcs, which is the games actual script file.

Edited January 9, 2019 by Jarno Mikkola

[CamDawg]

6 hours ago, Luke said:

@Wisp

It seems WeiDU (version 246) cannot parse things like this:

!StateCheck(NearestAllyOf(Myself),STATE_STUNNED | STATE_HELPLESS)

Are you aware of this bug?

In this case you're better off just directly using the numeric values here; I believe this construction is from NI's parser. STUNNED is 0x8, HELPLESS is 0x20, so you can safely use

!StateCheck(NearestAllyOf(Myself),0x28)

If you're going to be using it often it might be worthwhile to add it as a custom entry to state.ids.