A review of Isra 2.1 was posted on Beamdog forums

https://forums.beamd.../mod-reviews/p1

https://forums.beamd.../mod-reviews/p1

Review is adequate, however, the bug mentioned (no details given in that post) may only appear in EE, I had no trouble with her in BGT.

Pentalion just posted more information about the bug.

Pentalion just posted more information about the bug.

The issue is probably how the global is set in a chain dialogue

In Rh#quest.d

This

// 4. Jysstev Estate

CHAIN IF WEIGHT #-1 ~InParty("rh#Isra2") Global("rh#QarTalks","GLOBAL",1)~ THEN SCQAR q11
@110 /* Lady Isra, I had thought you above boorish gloating. Has your father's common blood finally run true in the end? */

DO ~SetGlobal("rh#QarTalks","GLOBAL",2)~
== RH#ISRJ @111 /* My lord, there is no cause for hostility. Alia is convinced that your cousin is innocent, and Rana... where has my sister gone? */
== SCQAR @112 /* She is currently staying with her Crytrapper relatives instead, and good riddance, I say. This house has been too crowded as it is. */
== RH#ISRJ @113 /* I see. If you know anything that might clear Quentin's name-- */
== SCQAR @114 /* We have already cooperated with the authorities as much as is required by law. There is nothing more that needs to be said. */
== SCLJYSS @115 /* Qar, if they can help, surely there is no reason not to let them? */
DO ~SetGlobal("rh#QarTalks","GLOBAL",2)~
END
    ++ @116 /* Any financial information would be useful. */ EXTERN RH#ISRJ q11.1
    ++ @117 /* A sensible suggestion if ever I've heard one. */ EXTERN RH#ISRJ q11.2
    ++ @118 /* We won't bother if all we're going to get out of it is abuse. */ EXTERN RH#ISRJ q11.3

The red indicated line should be at the green position to be set correctly.

Thanks Roxanne.  BWPFixpack'd

Edit:  better link for viewing the patches is here

Edited by agb1, 21 January 2016 - 08:17 AM.

Thanks Roxanne.  BWPFixpack'd

 

Edit:  better link for viewing the patches is here

Just a general remark with respect to this and similar issues.

The Isra code was perfectly correct.

The problem with setting globals in dialogues (or setting timers in area scripts) seem to appear randomly for specific users (there were discussions with the bigg and Vlad and Lollorion over the past years trying to trace those down). Anomalies appeared e.g. in the Carson dialogue in Watcher's Keep. The root of the problem was never found, as far as I remember, but it appears that a version of the original game exists where Infinity Engine itself has the issue. That may be the reason why one user (writing the review) had it while it works for the rest of the community.

Edited by Roxanne, 21 January 2016 - 08:49 AM.

What is the effective difference between the original position of the DO line and the revised position?  The later position is sometimes (for unknown reasons) not executed?

What is the effective difference between the original position of the DO line and the revised position?  The later position is sometimes (for unknown reasons) not executed?

Yeah, the first one is always executed if the THEN SCQAR q11 comes up... while the last is only done, if the response is ran all the way to: == SCLJYSS @115

Edited by The Imp, 21 January 2016 - 09:00 AM.

What is the effective difference between the original position of the DO line and the revised position?  The later position is sometimes (for unknown reasons) not executed?

Setting of globals inside the dialogue (this does not apply to globals at the end states, i,e, those you put into the PC's choices for answers) are set after the next state of the dialogue is executed. If it is the last (like here in Isra) they may be lost. Trying to check for a global attempted to be set this way while still in the dialogue creates a loop (like in my Carson example) unless there is at least one choice option to get you out of the dialogue.

PS just see that Imp answered while I was writing - saying the same in other words.

Edited by Roxanne, 21 January 2016 - 09:13 AM.

Could it be that the user regains control / the game un-pauses at the end of the final dialogue in the chain but before executing the DO step and so other actions or scripts then have the opportunity to interrupt it?  TobEx has an option to "pause during all dialogues" and I assume the same is implemented by default for EE, but I'm not sure what triggers that un-pause, so I am just speculating randomly here.

Could it be that the user regains control / the game un-pauses at the end of the final dialogue in the chain but before executing the DO step and so other actions or scripts then have the opportunity to interrupt it?  TobEx has an option to "pause during all dialogues" and I assume the same is implemented by default for EE, but I'm not sure what triggers that un-pause, so I am just speculating randomly here.

There is a difference between *the user regains control* and the fact that you can interact to make your choice of an answer. The game is paused until the dialogue is finally terminated, e.g. the fireball thrown at you hangs in the air until *end dialogue*.

Could it be that the user regains control / the game un-pauses at the end of the final dialogue in the chain but before executing the DO step and so other actions or scripts then have the opportunity to interrupt it?  TobEx has an option to "pause during all dialogues" and I assume the same is implemented by default for EE, but I'm not sure what triggers that un-pause, so I am just speculating randomly here.

There is a difference between *the user regains control* and the fact that you can interact to make your choice of an answer. The game is paused until the dialogue is finally terminated, e.g. the fireball thrown at you hangs in the air until *end dialogue*.

agb1 is asking: Can the DO need a small time to be executed between the lines, as the ToBEx'es pause hack could interrupt the literal chain of events before the END ? And thus not get done. Your example could be seen as a support of this, in principle. It's unlikely that we can do better than just throw our best guess at the wall and see if the spaghetti sticks on it.

Yeah, so anyways it's always best to set the DO'es far before the END, and if you can't, then just do it in another way, without the DO... as you can run a script that does the DO'es after, instead.

Edited by The Imp, 21 January 2016 - 10:09 AM.

The original code in Isra posted above is dangerous as the DO will only be executed if SCLJYSS really gets to say his/her line. I know this was pointed out by Jarno but I can only stress the importance of setting a dialogue's variable right after the first line of a CHAIN, after the NPC starting the dialogue spoke.

As it seems to be a best practice to place a DO early in a chain dialogue, does WeiDU warn (when using MODDER verbose-mode, at least) if a DO is placed later? We should probably do a grep through .d files of various mods to find other instances of this.

Do not be hasty - you can place DO in a dialogue where it suits your purpose best. The case we talked about here is where to set a Global in a chain dialogue to indicate the dialogue has run - just this case.

I can use a chain dialogue and let participant B go hostile after his last line with a DO, have participant C give you an item with DO somewhere in the talk etc and there is nothing wrong with it. It all depends on the circumstances and what I want to achieve.

For dialogues especially setting a global to indicate that the dialogue is done - so you want to assure this global is set always and you put it right after then initial talk. Everything else is flexible.

You may have another case where the resulting global may have a different value depending on the PC choice of answer - so here you will put the setting of the global to the very end.

A greb will just identify cases to look at but not do the job of analyszing every single one to see what the intend was, sorry.

That makes sense, Roxanne.