27 replies to this topic

[Ascension64]

Old request

Variables in dialogue not immediately updated

-----1170 Instantly Set Dialogue Variables [M]
Dialogue actions containing SetGlobal() or SG(), including through ActionOverride(), will set the variables immediately instead of being added through the dialogue owner's action queue
This allows interactive updates to responses by dialogue transitions

Options:
-0: disabled
-1: enabled

We're almost there. I just need to implement the ActionOverride() portion, and should be good to go. Note that I have implemented this in such a way that the action queue is avoided entirely, so it does not affect the action queues of any target creatures/scriptors.

I considered giving such an action a new opcode, but I figured that having asynchronous variable setting (the vanilla behaviour) isn't actually a desirable effect. If you believe otherwise, happy to discuss.

Edited by Ascension64, 07 March 2011 - 01:59 AM.

[the bigg]

I considered giving such an action a new opcode, but I figured that having asynchronous variable setting (the vanilla behaviour) isn't actually a desirable effect. If you believe otherwise, happy to discuss.

Is vanilla's behavior consistent for the same script or is it a plain critical race? If the former, vanilla behavior must be preserved (some mod might've been written in a way that took advantage of the action delay); if the latter, there's no point to preserve a non-reliable action.

Rather than making a new OPCode, perhaps you could have SetGlobal (IncrementGlobal, SetGlobalTimer ...) take an additional integer parameter to decide whether it should use the 'old' or 'new' behavior?

Edited by the bigg, 07 March 2011 - 02:21 AM.

[Ascension64]

Is vanilla's behavior consistent for the same script or is it a plain critical race? If the former, vanilla behavior must be preserved (some mod might've been written in a way that took advantage of the action delay); if the latter, there's no point to preserve a non-reliable action.

It appears to be a thread race. The main thread sends a CMessageInsertResponse containing the Response (below). The MessageListener thread will pick up this message and insert the response by adding all the actions in the action list to the tail of the action queue. The main thread eventually will update the creature and execute the actions listed. I think the next dialogue state is loaded to the GUI in the main thread straight after sending the CMessageInsertResponse, which is processed in its own time. Obviously, if the action list is a big barrage of stuff with a SetGlobal() at the end, this will make the delay longer.

The only scenario where I can see a delay might help is for non-pausing dialogue, where things appear if a global is set. However, I think that the delay is quite variable so there is no reliability to it. Note that the variable isn't deliberately set after dialogue closes, it's set some time after the action is sent.

Reminder: this hack only applies to dialogue, not scripting in general.

struct Response {
  short probability;
  short nResponseIdx;
  short nScriptBlockIdx;
  short nScriptIdx;
  CActionList m_actions;
};

[the bigg]

Then I see no point in preserving the old behavior, since it's a critical race that can't be relied upon.

PS: Are you including IncrementGlobal() and (Real)SetGlobalTimer() in the update?

[Ascension64]

Then I see no point in preserving the old behavior, since it's a critical race that can't be relied upon.

Except for the 'I think...' bit. It could well be safer to overload the existing actions to accept a second int. I'll try to find out more first.

PS: Are you including IncrementGlobal() and (Real)SetGlobalTimer() in the update?

IncrementGlobal() probably, timers probably not, do you need to check timers immediately after setting in dialogue?

[the bigg]

Except for the 'I think...' bit. It could well be safer to overload the existing actions to accept a second int. I'll try to find out more first.

It's possibly safer to overload SetGlobal(), but (assuming that no mod "relies" on the old behavior) it'd be better to "silently" fix all dialogues (so that no dialogue will be broken if you click on 'continue' too fast).

Re: timers, you have a point about no (sane) dialogue setting and checking one in a single conversation.

[Ascension64]

I had a slightly closer look and I think I might be incorrect in my previous thought that messages were executed in a different thread. They are in fact sent and processed by the same thread. However the next state is loaded before the next round of message execution, meaning that the next state will never detect that the variable has changed in value (although the following state should, which I have tested to be the case).

So, people might like to keep this behaviour, and therefore I will prefer the method of overloading the action to allow the next state to detect a variable change by the previous state. This would allow, for example, one to have a collapsing menu of options, such as picking the right order of 3 choices, etc.

[the bigg]

The Turnabout readme mentions that some variables don't get set in time if you press 'continue' too quickly; is that caused by some other phenomenon?

[Ascension64]

Maybe I can muck around with it. Any particular dialogue mentioned?

[cmorgan]

...They are in fact sent and processed by the same thread. However the next state is loaded before the next round of message execution, meaning that the next state will never detect that the variable has changed in value (although the following state should, which I have tested to be the case).

"Real World" testing in operational mods has 1.5 to 2 dialog states passing before a dialog can be referenced from within dialog (so on the third or fourth player interaction, most times the var set in the first can be referenced successfully, though reports of flaky behavior with this are out there, too) and some mods use pass-through states to try to allow this self-referent. I have some testing posts and results hanging around somewhere at PPG, I think, and SimDing0 and Jastey both have similar posts/findings. I haven't seen any mods actually using the reverse - except my attempts to leverage it in Aran's stuff (which I will recode because it gilding the lilly anyways; getting fancy when it really is not needed). Using CHAIN to create sequences (RE stuff for Sheri) *appears* (not tested, just observational) to be more bomb-proof than regular construction, I assume since changing .dlg file allows the thread to catch up; that could be a red herring, though.

I don't think there are specific dialogs that can be pointed at in Turnabout that consistently evidence the hiccups, I think it is a global finding. Fast clicking through dialog *appears* to interrupt or delay setting variables on some machines/environments, but it might be confused with some other scripting delay, like the move-your-party-too-fast-to-an-area-exit-into-FAI-means-Imoen's-Tarnesh-dialog-will-not-get-triggered BG1NPC bug.

I think it would be great to have this functionality. I would like to be able to actually *not* have to wrap around through extra dialog states in the vain hope that the darned thing would set; even with A=set B=delay C=loop back D = A var referenced I have regular "same dialog appears even though the var has been set to block it", regardless of scope (MYAREA, C-AR01, LOCALS, GLOBAL).

[Kulyok]

There is nearly no material from Turnabout forums, but you can have this:
link - basically, same stuff in the closed forum: "the problem exists, we've tried to look into it, but, unfortunately, we've found nothing". I think it is a different problem, which comes from the structure of the pools themselves: pools at the Throne of Bhaal are not meant to work with dialogue options, so maybe it's better to use immortal invisible(?) semi-permanent creatures instead. (Although, how? It's ToB epilogue; bad timing all around, I'd say).

Anyway! I would say this modification does not seem essential for the time being, and here is why:
it is DIALOGUE. You have DIALOGUE BRANCHES. If you want to set one varaible, go through one branch, if you don't want to set it, go through another. And again, and again, and again. If you want to get the var set at the end, set it at the end. If you're too lazy to replicate multiple dialogue states(and I'm certainly lazy enough for this, which is why I re-wrote Xan's birthday dialogue - yes, I had this problem, so I shrugged and avoided it entirely), use copy and paste; a few hundred tra lines are nothing if you need the result. (Edited for typos and to make the link display correctly).

Edited by Kulyok, 09 March 2011 - 07:07 AM.

[the bigg]

Consider this dialogue:

Spoiler

BEGIN ~tb#test~
IF ~True()~ THEN 0
SAY ~0~
IF ~Global("tb#test","GLOBAL",0)~ DO ~SetGlobal("tb#test","GLOBAL",1)~ GOTO 1 
IF ~Global("tb#test","GLOBAL",1)~ DO ~SetGlobal("tb#test","GLOBAL",2)~ GOTO 2 
IF ~Global("tb#test","GLOBAL",2)~ DO ~SetGlobal("tb#test","GLOBAL",3)~ GOTO 3 
IF ~Global("tb#test","GLOBAL",3)~ DO ~SetGlobal("tb#test","GLOBAL",0)~ EXIT
END
IF ~~ THEN 1
SAY ~1~
IF ~Global("tb#test","GLOBAL",0)~ DO ~SetGlobal("tb#test","GLOBAL",1)~ GOTO 1 
IF ~Global("tb#test","GLOBAL",1)~ DO ~SetGlobal("tb#test","GLOBAL",2)~ GOTO 2 
IF ~Global("tb#test","GLOBAL",2)~ DO ~SetGlobal("tb#test","GLOBAL",3)~ GOTO 3 
IF ~Global("tb#test","GLOBAL",3)~ DO ~SetGlobal("tb#test","GLOBAL",0)~ EXIT
END
IF ~~ THEN 2
SAY ~2~
IF ~Global("tb#test","GLOBAL",0)~ DO ~SetGlobal("tb#test","GLOBAL",1)~ GOTO 1 
IF ~Global("tb#test","GLOBAL",1)~ DO ~SetGlobal("tb#test","GLOBAL",2)~ GOTO 2 
IF ~Global("tb#test","GLOBAL",2)~ DO ~SetGlobal("tb#test","GLOBAL",3)~ GOTO 3 
IF ~Global("tb#test","GLOBAL",3)~ DO ~SetGlobal("tb#test","GLOBAL",0)~ EXIT
END
IF ~~ THEN 3
SAY ~3~
IF ~Global("tb#test","GLOBAL",0)~ DO ~SetGlobal("tb#test","GLOBAL",1)~ GOTO 1 
IF ~Global("tb#test","GLOBAL",1)~ DO ~SetGlobal("tb#test","GLOBAL",2)~ GOTO 2 
IF ~Global("tb#test","GLOBAL",2)~ DO ~SetGlobal("tb#test","GLOBAL",3)~ GOTO 3 
IF ~Global("tb#test","GLOBAL",3)~ DO ~SetGlobal("tb#test","GLOBAL",0)~ EXIT
END

In an ideal world, it should print '0,1,2,3' exit. In the current implementation (both vanilla BG2 and tobex 0.20.3.6), SetGlobal() is delayed by a full state, hence it goes '0,1,1,2,2,3,3'. On top of that, if you click Continue several times per second, the SetGlobal() is delayed even more: the worse I saw was '0,1,1,2,2,2,3,3,3,3,3', which means that SetGlobal(*,2) was delayed by an extra state, while SetGlobal(*,3) was delayed by three extra states (in addition to the single state it is naturally delayed by the dialogue engine).

Edited by the bigg, 09 March 2011 - 07:27 AM.

[Kulyok]

My abstract mind has gone to sleep, I'm afraid. Can you give me a situation in context, a situation that is not solvable by branching and adding a (close to infinite, I agree) number of states to the dialogue itself? Because I really can't think of one right now, otherwise I would not have used capital letters.

[cmorgan]

The bigg's test shows why mods that want correctly self-referential materials building a conversational flow (Jastey's Ajantis, especially, in both the BG2 mod and the BG1NPC materials) have had to resort to all sorts of bouncing, or do exactly what you are saying - . It would be great to have the same logic that applies with .bcs (var evaluates in block 1 and is seen by block 2) apply to dialog.

Stuff that can be worked around by spamming lots of extra dialog state blocks? Yep - spamming solves the problem, in a way - it takes the "loop" out in favor of discrete branches of conversation, at the cost of added blocks - and the need to keep any materials you want to reference within the same dialog away from the first by at least three states. Solving this lets a modder do something like this much more efficiently, with decent flow (off the top of my head, stinky but illustrative:

[ARAN] Was killin' those deep gnomes all that important? It seems they were doin' naught in th' way o' harm.
[PC] They were harmless. But they had to be destroyed. DO SetGlobal("gnomesclobbered","LOCALS",1)
[PC] There is no denizen of Underdark that can be described as 'harmless', Aran. The most they can aspire to is 'mostly harmless'.

[ARAN] You should have told me this were to be a bloodbath.
[PC]
!Global("gnomesclobbered","LOCALS",1) [PC] It was a bloodbath because they deserved it. After all, deep gnomes are dangerous. + continue_conversation
Global("gnomesclobbered","LOCALS",1) [PC] It was a bloodbath because they deserved it. After all, deep gnomes are dangerous. + mostly_harmless_minus_babelfish

mostly_harmless_minus_babelfish
[ARAN] But you just said they were harmless...
[PC] Look, I make the decisions. Shut up and get back in formation.
[PC] etc.

Using a few variables can allow a single track of conversation to allow multiple branches, tailored to the conversational choices itself. It makes dialog much more flexible, and closely mimics regular speech.

How are you doing today?
Fine.
Anything going particularly well?
No.
So why did you say fine?
etc.

In the best of all possible world, an even better (sets after each dialog state)

[NPC] How are you doing today?
[PC] Fine. <<setglobal=1>>
[PC] Not so good. <<setglobal=2>>
[PC] Lousy. <<setglobal=3>>

[NPC] Me too. But I could do with a little less combat.
[PC] <<if global=1>> I'm darned glad you are doing fine. Me, I am not so happy about going to faculty meeting.Give me a dragon to slay any day.
[PC] <<if global=2>> So we are both a little frustrated. That is fine... we can always stop at the next inn for a drink.
[PC] <<if global=3>> So we are both in a bad mood. You may hate the combat, but I need some heads to knock together in order to improve mine.

Edited by cmorgan, 09 March 2011 - 12:23 PM.

[the bigg]

I suppose you could solve this via extensive amounts of branching and code duplication; however, since Asc has already decompiled the relevant section of code, he can fix the bug in five minutes (... and the day I manually copy-paste a hundred states in my mod is the day I'll ask Bioware to revoke my modding license).

Edited by the bigg, 09 March 2011 - 08:44 AM.

[GeN1e]

My abstract mind has gone to sleep, I'm afraid. Can you give me a situation in context, a situation that is not solvable by branching and adding a (close to infinite, I agree) number of states to the dialogue itself? Because I really can't think of one right now, otherwise I would not have used capital letters.

*Sprinkles cold water* Wake up, sleepy elf.

The situation is sitting right in front of me (not my coding, though):
1) root state with several topics available
2) each topic can be asked about but once
3) the more topics have been discussed, the more tired the speaker grows before replying
Adding extra branches is entirely out of question, I guarantee it, because otherwise the size of D is gonna reach over 9000 states.

Now, since it's not clicked through in an instant, no big deal with variables' setting, but the example is there.

Edited by GeN1e, 09 March 2011 - 12:04 PM.

[Kulyok]

All right, all right, macho men don't do long and tedious copy-pasting work, I get it. But I will remind you of three things before I withdraw without dignity:

1) requiring the users to install an exe-patching mod for a simple NPC/quest-related thingy seems a bit too much;

2) even the DA2 dialogue(and it's considered, like, top-notch now, not to mention other games like X-Files or DA or even vanilla BG2) doesn't do "disappearing" replies in a root state with several questions/topics available. It's not good. If the player wants to ask the question again, let him.

3) Try actually playing the dialogues with a root state with several topics available, and you'll find how boring they are. Take Keldorn's/Gavin's "your hobbies" or Ajantis's "tell me about Candlekeep" or Kelsey's famous ToB "hug me, kiss me, I'm pregnant, let's get married, let's dream about the future"(all in one "Darling, anything troubling you?" dialogue), or my own... wait, no, I don't do these dialogues, because they are boring(Xan's birthday conversation certainly was. Still is, maybe). They don't feel natural! Or take the quests - any DA2 quest, PC has an option to ask questions again and again; any BG2 quest, PC asks the question once and the dialogue moves to the next state, so the player feels the conversation is alive. Both options are viable, but controlling your NPC/quest dialogue with variables isn't going to make it any better, trust me. Or don't trust me and find out for yourself. Which you probably will.

*Sprinkles cold water* Wake up, sleepy elf.

You wish. I've been playing DA until half to midnight yesterday, and getting up at half past eight didn't help. Ah well. DA games only come out once in eighteen months or so, anyway.

[the bigg]

1) requiring the users to install an exe-patching mod for a simple NPC/quest-related thingy seems a bit too much;

Nowadays, you can automatically include and install ToBEx with your mod; the only people left out are pre-Intel Mac users.

[Ascension64]

I can confirm that there is some asynchronicity issue associated with going through dialogue too fast, such that my previous example isn't always guaranteed to work if the player taps through the intervening dialogue quickly. I'm struggling to find out the reason at the moment though. However, this hack seems to fix the issue.

I'll keep digging into the cause. I'm sure a second thread is involved somewhere. I can't explain it otherwise (it doesn't appear to be due to multiple keys being pressed within a single listener event).

Update: I believe I have a theory now. While all of this stuff happens in the same thread, the actions are queued on the target creature/s, but the actions aren't executed until the next AIUpdate (next tick). So if you manage to progress the dialogue before all the updates in the next tick is processed, the globals don't get updated. So I was right about the queued actions, but not about the multi-threaded part.

Edited by Ascension64, 10 March 2011 - 03:33 AM.

[GeN1e]

@Kulyok

All right, all right, macho men don't do long and tedious copy-pasting work, I get it.

Macho men indeed prefer hot-generating code over copypasting

2) even the DA2 dialogue(and it's considered, like, top-notch now, not to mention other games like X-Files or DA or even vanilla BG2) doesn't do "disappearing" replies in a root state with several questions/topics available. It's not good. If the player wants to ask the question again, let him.

I don't really advocate the ask-only-once concept either, but that's a half anyway. And, INTERJECT family also sets vars to avoid repeating.

3) Try actually playing the dialogues with a root state with several topics available, and you'll find how boring they are.

Depends on writing. Often - perhaps, always - no.

They don't feel natural! Or take the quests - any DA2 quest, PC has an option to ask questions again and again; any BG2 quest, PC asks the question once and the dialogue moves to the next state, so the player feels the conversation is alive

This contradicts what you say in 2), no? If players wish, they should be allowed to.

But I will remind you of three things before I withdraw without dignity:

Worry not, I'll lend some of mine - the example I've mentioned above is self-sufficient, for it's large enough to negate the consequences of clicking too fast. Your points apply normally to smaller cases, where the issue is relevant.


PS Playing DA2 now? I'm in awe, how there're still people around willing to play without waiting for patches.

Edited by GeN1e, 10 March 2011 - 04:24 AM.