timing of application of script actions in .DLG

[subtledoctor]

I have a dialogue which, if you select a certain response, does this:

 IF ~~ THEN REPLY @2011 DO ~AddKit(THIS_KIT)~ DO ~ApplySpellRes("the_spl")~ EXIT 

the_spl.spl has opcode 177 effects which filter by kit. With the above line, would the newly-added kit be applied in time to register in the spell's opcode 177 effects? Or does there need to be a delay there, or something?

[subtledoctor]

Okay, after some more testing, I can say the above will NOT work. It may be possible to add a Delay script action, I forget whether/how it can be done. In my case the spell to be cast in turn casts a subspell with the opcode 177 effect. So I just set the subspell to be cast on a 1-second delay, and it works correctly.

[CamDawg]

Unless listed in instant.ids, actions in dialogues get queued for execution.

[jastey]

You have two times "DO" in your example above. Is this a syntax error or something I'm not aware of?

[subtledoctor]

1 hour ago, jastey said:

You have two times "DO" in your example above. Is this a syntax error or something I'm not aware of?

Syntax was just borrowed from other dialogues I saw. Don’t you need a ‘DO’ for each action? In any event this syntax compiles with no errors or warnings, and it works correctly in-game...

[CamDawg]

You can use multiple actions in a single DO; they all get compiled as actions to the same reply regardless. I remember WeiDU throwing a warning (but still compiling) with DOs, but I think it was for an empty call (DO ~~ essentially).

[jastey]

As far as I know, it's only one DO and all actions in one ~~. It's well possible the second "DO ~something~" was swallowed when compiled.

[subtledoctor]

2 hours ago, jastey said:

As far as I know, it's only one DO and all actions in one ~~.

You mean like this?

IF ~~ THEN REPLY @2011 DO ~AddKit(THIS_KIT) ApplySpellRes("the_spl")~ EXIT

Interesting. Looks a bit odd to me, but I guess only because I'm used to seeing it the other way.  Is this documented anywhere? LIke I say, I copied this formulation from... some other mod (who knows which one) and I'm not aware of any actual instruction on the proper syntax. Both the IESDP and the Weidu readme seem silent about it.

FWIW I have several dialogues in several mods that use multiple DOs in a single reply, and it works just fine. Like I say, no warnings when compiling, NI sees it as valid, and everything works properly in-game.

[jastey]

9 hours ago, subtledoctor said:

FWIW I have several dialogues in several mods that use multiple DOs in a single reply, and it works just fine. Like I say, no warnings when compiling, NI sees it as valid, and everything works properly in-game.

And I never knew that would work, I always use all actions in one DO and for the rare cases that it was doubled I believe to recall it gave an install error.

[argent77]

  According to the WeiDU documentation the syntax used by subtledoctor should work correctly. There is nothing that indicates that transition features have to be defined in a certain order or cannot be added multiple times. For instance, it is perfectly legal to add the UNSOLVED_JOURNAL entry or DO block before the reply string.

However, it looks like WeiDU processes DO blocks in reversed order. In your case

DO ~AddKit(THIS_KIT)~ DO ~ApplySpellRes("the_spl")~

results in

ApplySpellRes("the_spl")
AddKit(THIS_KIT)

That's probably the reason why your original code example didn't work.

Btw, it's even legal to add multiple REPLY entries without causing a compile error. However, only the last instance is used in this case.

[jastey]

Thanks @argent77, that's interesting!

To my defence, I couldn't have known that, I'm only into modding for, like, three months or so.

[subtledoctor]

3 hours ago, argent77 said:

However, it looks like WeiDU processes DO blocks in reversed order. In your case

That's probably the reason why your original code example didn't work.

Yes, I noticed that when I looked at it in NI. But it is not what caused the failure. I tried it in two dialogues, identical except one of them with reversed DO blocks. The 177 effect filtering by kit failed in both instances. I think the blocks are just too close together in time. When I set the spell to timing mode 4/duration 1, both versions worked. 

[argent77]

Have you tried adding a SmallWait() between the two actions?

[subtledoctor]

50 minutes ago, argent77 said:

Have you tried adding a SmallWait() between the two actions?

This is more or less what I was looking for to answer the question.   I've got console commands from different game engines rattling around in my head, I didn't know if it was "Wait()," or "Delay()," or something like that.

That would probably end up working fine, as long as they are executed in the correct order. As I say, in my case I ended up adding a delay to the spell itself, which serves the same purpose.