IWD2 : User script execution

[Gimble]

In IWD2, my user scripts seemed to take a while to execute when enemies were first sighted. To simplify things, I ultimately reduced my script to the following:

IF
Exists(Myself)
THEN
RESPONSE #100
	FloatMessage(Myself,1983) // ::Yawn::
END

A little experimentation seems to indicate the following:

• (User) scripts are not executed while the character is moving via click.
  
• (User) scripts are not resumed for some period of time ( 0-6 seconds ) after the character stops moving. In short, I'm guessing they don't get another script cycle until the next round.
  

Is this consistent with other games? And is there any way to get around this?

[cirerrek]

Gimble,

 

This is mostly conjecture but, perhaps it will be useful to you.

 

I believe the phenomena that you are describing are unique to IWD2 (or perhaps the IWD version of the IE engine).

 

I actually hadn't considered that there might be 2 different things going on as you have suggested.

 

It drove me nuts working with the iSeries for IWD2.

 

I thought it might be a problem with Visual Range, but SetVisualRange(I:Range*) in IWD2 sets the Visual Range for every creature in the area to the assigned value.

 

It may be that in IWD2, moving is not interruptable without using the GUI.

 

I also wondered if you could use ChangeAIScript or the IWD2 equivalent to push the script to one of the higher slots (say override) and if the scripts would react faster.

 

Thanks,

[Smoketest]

In BG2 I always use ActionListEmpty() before letting a character attack because I got tired of them interrupting their traveling to attack something. Often I use travel to position them strategically so I need them to do what I tell them to do first, then they can follow scripted actions.

 

Perhaps IWD2's designers felt the same way and built this into their script system, although the delay at the end is unnecessary. In BG2 my characters attack/cast immediately upon reaching their destination.

[Gimble]

I believe the phenomena that you are describing are unique to IWD2 (or perhaps the IWD version of the IE engine).

Good to know. I didn't remember this behavior from BG2, so I would agree that IWD2's engine rework probably added this as some kind of optimization.

It drove me nuts working with the iSeries for IWD2.

Since I don't have the years of scripting experience you legendary scripters have, I haven't been nearly as bothered. Some of the omissions are extremely painful ( for example, the inability to see if an item is equipped ), but some of the newer scripting functions are very, very nice ( MyTarget, and XEquipItem as two examples ).

I also wondered if you could use ChangeAIScript or the IWD2 equivalent to push the script to one of the higher slots (say override) and if the scripts would react faster.

Good idea, but same behavior occurs in override. My best thought to provide a workaround is to have the lead character stealth-capable (or invisible). That way, they could stop moving, and their script can execute before the enemy has a chance to see them.

 

Not a particularly good solution, but better than nothing. I also got a sample for weapon switching working again, so I'm making progress on my own scripting series ( poorly named i2, not realizing there was a pre-existing iSeries ). Unfortunately, weapon switching requires exact knowledge of weapon names ( "00FLAL97" ), so I'm trying to decide how to make it easier to generate the information I will need to build weapon-switching scripts.

[Gimble]

Perhaps IWD2's designers felt the same way and built this into their script system, although the delay at the end is unnecessary.

That's a good theory. The IWD2 'official' user scripts are definitely more complete than the other IE games' official scripts, but they also have some errors and omissions... showing yet again that IWD2 had some good design but extremely rushed implementation.

 

It's not a big leap to assume that their user scripters noticed the same behavior, but elected to 'fix' it by disabling scripting execution in the engine during character movement (and until the next following round ).

[Smoketest]

Hmm, you did mention that the delay after moving was variable, something like 0-6.

 

It could be that Black Isle calculated distance moved on a per round basis. Thus if your character moved a distance that left them somewhere within a round, that round would have to finish before further actions were allowed. Or something like that. I'm not up to date on D&D 3.0 movement rules.