adding innate abilities from a dialogue

[agb1]

I think you can simplify to StartDialogueNoSet(LastSummonerOf(Myself)) if the invisicre has d5_psyph.dlg assigned to it. But if you make that change, the identity of "Myself" will probably switch from the player to invisicre, meaning you also will need to use ActionOverride for the AddSpecialAbility and RemoveSpellRES and change Myself in the ApplySpellRES to LastSummonerOf(Myself).

That bold text would replace this line: ActionOverride(LastSummonerOf(Myself),StartDialogOverride("d5_psyph",Myself))

 

In the .d file, you are correct that it will compile to D5_PSYPH.DLG, but that is not because the file is named D5_PSYPH.D -- the filename doesn't matter to WeiDU. The BEGIN ~D5_PSYPH~ tells WeiDU that the following lines should be compiled into D5_PSYPH.DLG. You could somewhere in that same .D file write BEGIN ~subtle~ and everything following that would be compiled into SUBTLE.DLG. In other words, one .D file can contain new states for multiple DLG files.

 

In your first state, is it possible that the global D5_PS102 ever could be greater than 1? (Can anything outside of this dialogue increase it?) You have no reply condition that would be available in that case. If it's not possible, no problem.

 

Either way, since the reply conditions in that first state can't both be true at the same time (you used GlobalLT and Global for the same variable D5_PS102, which cannot be both 1 and less than 1 at the same time), the first state will never offer a choice as the "SAY" line implies. Only one of those reply lines will be available.

 

In your second state (d5_psyph_1), the ApplySpellRES needs quotes around the "D5_PSA2", doesn't it? I assume that is referencing a file D5_PSA2.SPL, not an IDS name in SPELL.IDS, since you used the RESource form of the action.

[subtledoctor]

In your second state (d5_psyph_1), the ApplySpellRES needs quotes around the "D5_PSA2", doesn't it? I assume that is referencing a file D5_PSA2.SPL, not an IDS name in SPELL.IDS, since you used the RESource form of the action.

It can handle not having quotes, but there really ought to be quotes and I have since added them. Good eye.

 

since the reply conditions in that first state can't both be true at the same time (you used GlobalLT and Global for the same variable D5_PS102, which cannot be both 1 and less than 1 at the same time), the first state will never offer a choice as the "SAY" line implies. Only one of those reply lines will be available.

That's not how it works for me. The first time the dialog runs, that local variable is 0, so the GlobalLT,1 returns true and gives me the reply option to go to d5_psyph_1 and choose Id Insinuation, which sets that variable to 1. The next time the dialog runs, the GlobalLT,1 returns false but the Global,1 returns true, and it gives me the reply option to go to d5_psyph_2 and choose Mental Domination. So that much is working okay.

 

This concerns me more:

 

Some note, (multiple blocks of) queued up actions won't be executed in the dialog, so make sure you exit the dialog after the actionoverride.

I don't quite understand what this means. Is it a problem to have "DO ~AddSpecialAbility()~ DO ~RemoveSpellRES()~ EXIT" together in one line? In my testing the older innate abilities seemed to be removed correctly in-game, but when inspecting the .cre file in NI they still appeared as "known spells."

[agb1]

Avenger would know more, but if you look here you will see a list of Actions that execute immediately if they occur during a dialogue. Actions that are not on that list are placed in an action queue that will be processed after the dialogue ends (reaches an EXIT). I think Avenger is saying that the action queue is limited and if you DO ~something~ and then proceed in the same dialogue to another DO ~something else~ then the first ~something~ will be forgotten (except any Actions that already happened because they are listed in instant.2da).

[Roxanne]

Avenger would know more, but if you look here you will see a list of Actions that execute immediately if they occur during a dialogue. Actions that are not on that list are placed in an action queue that will be processed after the dialogue ends (reaches an EXIT). I think Avenger is saying that the action queue is limited and if you DO ~something~ and then proceed in the same dialogue to another DO ~something else~ then the first ~something~ will be forgotten (except any Actions that already happened because they are listed in instant.2da).

This is a bit more subtle, it mostly refers to actions that are set AND read within in a (longer) dialogue , e.g you want to mark an answer as already given (per DO SetGlobal) and exclude some dialogue path a bit later (by reading the Global) - if that global is coded in a way that it is just set upon EXIT, then the second check will fail and your dialogue may end in a loop (famous bug with the mad mechanic mage Lum in WK).

Those comments are thus more related as to when globals are set in dialogues and when they can be assessed by the same dialogue or a script. Also for some DO you will see that they are executed after the next state only, e.g. you get an item or XP during a dialogue, the *Party Has Gained Item* message appears with a delay (instant IDS and dialogues can be topic for an epic thread on its own...)

Generally - DO actions in a dialogue are executed correctly if coded right. You may even have several DO-blocks within the same dialogue, e.g. one to control the execution of the dialogue itself by increasing a global, and several others depending on choices in the dialogue. Anyway, within one Do action block you will use DO~ All actions to be performed~ EXIT or move on.

There is also the issue of how to order actions within one DO and how to use stuff like Wait(2 or whatever) but this is not different from how you do it in scripts.

[Avenger]

So, i think i have to clear things up, because agb1 understood me perfectly, but it was not correct.

 

1. the block of actions are executed after the selection + displaying the new options has been done. This causes the 'lum machine effect'. So, effectively, even instants are delayed by one more pick. (Interestingly, this effect isn't in PST, it executes the instants of a dialog right after selection.)

2. non instants are not executed during a dialog. This still holds, and it is the main concern i wanted to mention earlier.

3. various things can disturb the already queued up actions if there is a non-instant. So, you can only be sure that your actions up until the first non-instant will be executed.

 

What was not correct, is that i remembered (wrongly) about the engine clearing the queue before queueing up the new dialog action block.

[agb1]

Thanks for the additional detail, Avenger.

 

#3 could be interpreted to mean that any action, even an instant action (listed in instant.2da) might not be executed after the first non-instant.

 

I think you probably mean that non-instant actions after the first non-instant action might not be executed (so instants after a non-instant are still reliable)?

 

Even in that case, #3 still seems to imply that it is never reliable to have more than one non-instant action occur (either within the same transition or through traversal of multiple states) in a single dialogue before exiting?

 

Is that limitation (non-instants after the first might not be executed) true even for multiple non-instants within a single DO ~NonInstant1(will execute) Instant1(will execute) NonInstant2(might not execute) Instant2(will execute)~ block, or only when you chain more than one DO block across transitions and states within the same dialogue session?

[Avenger]

Having more than one non-instant is the only problem, it isn't affected by having them spread out in different action blocks. Also the fact that your non instants will freeze every instants coming after it. Your dialog won't be able to set any variables (except at the end of the dialog if you are lucky).

Some other stuff like joinparty/leaveparty can also mess the dialog up (because they change the dialog).

 

So, yeah, with #3 i meant, anything after a non-instant in a dialog is in jeopardy Regardless if it is in a new block or the same block.

[agb1]

Thanks, it's clear now. Wisp, if you happen to read this, any chance we could have the WeiDU compiler warn if it sees any actions (whether instant or not) after a non-instant in a dialogue? Extra credit if it "scans ahead" and looks at downstream dialogue states for potential problems.

 

Edit: and now to go memorize instant.2da ... instant.IDS (oops)

 

Edit 2: I see that ApplySpell is instant but ApplySpellRES is not. What happens if we add actions to instant.IDS?

[subtledoctor]

From which I gather that

DO ~IncrementGlobal()~ DO ~AddSpecialAbility()~ DO ~RemoveSpellRES()~

... is not safe, because neither of those last two execute instantly. It's been working fine for me in testing, but I guess a single test character in the tavern in Easthaven might not reflect more chaotic game conditions you face later. So:

 

1) ActionOverride executes instantly. Can I 'cheat' by wrapping those actions inside an ActionOverride action?

 

2) ...or should I just bite the bullet and make 20 spells with 171/172 effects, and use ApplySpellRES?

[agb1]

http://gibberlings3.net/forums/index.php?showtopic=27592 seems highly relevant to this discussion. Notably, TobEx introduced a new action DialogueSetGlobal but it appears that has not been ported to Enhanced Edition.

[Roxanne]

http://gibberlings3.net/forums/index.php?showtopic=27592 seems highly relevant to this discussion. Notably, TobEx introduced a new action DialogueSetGlobal but it appears that has not been ported to Enhanced Edition.

Do NOT PANIC

This is exactly the reference I had in mind when I made the post above http://gibberlings3.net/forums/index.php?showtopic=28340&page=3&do=findComment&comment=248926.

 

Your discussion makes it appear like a big (negative) issue instead of a feature.

The point actually is that knowing about it makes this an enormously powerful tool. You can make use of it in your dialogues (especially when using CHAIN) to give them capabilities that otherwise would require cutscenes. You can do a lot with DO in dialogues (if you have the time, just study the Irenicus dialogue sequences in Spellhold to see the power of it.)

 

...yes, and like every powerful tool it can create havok when in the wrong hands...

 

Like said earlier - there are cases however, when the better method is to just set a global via dialogue and have a script do the actions afterwards, something to decide on a case to case basis. (Study the old BGT sequence from CtB for the transition from BG1 to BG2 and you will see what I mean.)

[agb1]

I acknowledge your point that delayed execution can be useful.

 

Avenger is saying that there is no guarantee that any action after the first non-instant will be executed, which I interpret to mean that as a general rule, we should assume that none of those actions will be executed. It seems from subtledoctor's testing that it often does work, but Avenger warns us that sometimes it won't. Is there a way to know when it will work, without testing?

 

If a particular combinations of actions (including some following a non-instant action) in a dialogue works as expected in isolated testing, does that mean it will continue to work in a future constellation with other mods?

 

If the answer is yes ... as long as no other mod changes your dialogue sequence (which isn't your problem as the original modder), then it's really not a problem, just something to be aware of. As a general rule, you should test all of your dialogue, but when there is uncertainty about execution (you can't predict the effects of the code just by reading it), you need to be more rigorous in your testing (normally, seeing a particular dialogue line might be enough to verify that the associated actions have been taken, but due to this uncertainty you need to explicitly check each global and confirm that each action had the expected effect). The guideline would be that if you have actions following non-instants in a dialogue, you need to be extra careful to verify (by testing) that those following actions are actually executed, but if it works as expected then you can assume it's safe for that particular usage.

 

Is that the right conclusion?

 

Edit: I'm still curious about adding actions to instant.ids. Can you make more actions instant in that way? Is that safe to do from an engine perspective (won't cause crashes or other bad things)? I guess it could break other mods that depend on delayed execution, so it would be compatibility-unfriendly regardless.

[Roxanne]

I acknowledge your point that delayed execution can be useful.

 

Avenger is saying that there is no guarantee that any action after the first non-instant will be executed, which I interpret to mean that as a general rule, we should assume that none of those actions will be executed. It seems from subtledoctor's testing that it often does work, but Avenger warns us that sometimes it won't. Is there a way to know when it will work, without testing?

 

If a particular combinations of actions (including some following a non-instant action) in a dialogue works as expected in isolated testing, does that mean it will continue to work in a future constellation with other mods?

 

If the answer is yes ... as long as no other mod changes your dialogue sequence (which isn't your problem as the original modder), then it's really not a problem, just something to be aware of. As a general rule, you should test all of your dialogue, but when there is uncertainty about execution (you can't predict the effects of the code just by reading it), you need to be more rigorous in your testing (normally, seeing a particular dialogue line might be enough to verify that the associated actions have been taken, but due to this uncertainty you need to explicitly check each global and confirm that each action had the expected effect). The guideline would be that if you have actions following non-instants in a dialogue, you need to be extra careful to verify (by testing) that those following actions are actually executed, but if it works as expected then you can assume it's safe for that particular usage.

 

Is that the right conclusion?

 

Edit: I'm still curious about adding actions to instant.ids. Can you make more actions instant in that way? Is that safe to do from an engine perspective (won't cause crashes or other bad things)? I guess it could break other mods that depend on delayed execution, so it would be compatibility-unfriendly regardless.

Usually you should be able to find this by testing your code, just like you say. And it is not restricted to dialogues. Just look at cutscenes or some other scripts that need to be very careful with timing (e.g. transport party to another location, sequence of spells to cast etc), Look at those scripts and you will find Wait or SmallWait at specific points or even when you expect that an action to be executed may otherwise interfere with the next. Examples are everywhere.

 

I'm still curious about adding actions to instant.ids.

First of all you would need a very good reason to justify such a change.

[lynx]

It seems to work at least in ees — check the recent monk kit mod presented on this forum. Of course, it could cause problems in other scripts, if any rely on side effects from the queueing madness.

[Avenger]

Adding a non instant to instant.ids then using it in dialog? Well, i didn't check this, but i imagine it will either cause a freeze, or nothing visible.