27 replies to this topic

[the bigg]

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

Why wait for patches, when you can wait for a 50% discount on Steam on the Ultimate Edition?

[Ascension64]

Here's the real answer.

Actions are processed every AIUpdate. AIUpdate doesn't actually happen every tick; by default, it happens every 2 ticks. Some variations allow AIUpdate every 1 tick, 4 ticks, or 8 ticks.

Let's say I have the following dialogue:

You[0]: Hello. How are you?
1: Good, thanks. DO ~SetGlobal("Good", "GLOBAL", 1)~ GOTO 1
2: Awful! GOTO 1

You[1]: Oh, I see (pretends to listen). GOTO 2

You[2]: Did you say you were good?
1: IF ~Global("Good", "GLOBAL", 1)~ Yes, I did. Weren't you listening? GOTO ...
2: No, I said you were a twerp! GOTO ...

Note that the response to "Good, thanks." would contain the following action block:

SetInterrupt(FALSE)
SetGlobal("Good", "GLOBAL", 1)
SetInterrupt(TRUE)

...and that one action is processed every AIUpdate.

The engine processes like one of these if I press 1 then Enter as fast as I can in order:

Scenario 1 - You AIUpdates on every even tick
Time 0 - I press the 1 key, this input is stored in the active dialogue
Time 0 - AIUpdate is run on You
Time 0 - The active dialogue input is processed and the transition is made; message sent to You; next dialogue displays
Time 1 - The message is processed and the action added to the queue of You
Time 1 - I press the Enter key, this input is stored in the active dialogue
Time 1 - The active dialogue input is processed and the transition is made; next dialogue displays (GLOBAL is not set because no AIUpdate has occurred) with only one option "No, I said you were a twerp!"
Time 2 - AIUpdate is run on You: SetInterrupt(FALSE) is executed
Time 4 - AIUpdate is run on You: SetGlobal() is executed

Scenario 2 - You AIUpdates on every odd tick
Time 0 - I press the 1 key, this input is stored in the active dialogue
Time 0 - The active dialogue input is processed and the transition is made; message sent to You; next dialogue displays
Time 1 - The message is processed and the action added to the queue of You
Time 1 - I press the Enter key, this input is stored in the active dialogue
Time 1 - AIUpdate is run on You: SetInterrupt(FALSE) is executed
Time 1 - I press the Enter key, this input is stored in the active dialogue
Time 1 - The active dialogue input is processed and the transition is made; next dialogue displays (GLOBAL is not set because SetGlobal() not executed) with only one option "No, I said you were a twerp!"
Time 3 - AIUpdate is run on You: SetGlobal() is executed

Therefore, setting the global never gets there in time if the user progresses fast enough. Not even a 1-tick update would help in this circumstance.

So the question arises again about whether an instantaneous dialogue variable setting should be incorporated directly into existing actions, or overloaded.
The first option will fix the rapid dialogue issues, and further dialogue issues when transitions have long lists of actions with the set global right at the end, but runs the risk of globals being set out of order - consequences appear pretty harmless unless one relies on a global variable where another trigger should be used. For example (rather generic),

DO ~GiveItemCreate("arow01", Player1, 1, 0, 0)
~SetGlobal("MakeArrow", "GLOBAL", 1)~ GOTO Next

//next state
IF ~~ THEN BEGIN Next
SAY ~Did you get an arrow?~

IF ~Global("MakeArrow", "GLOBAL",1)~ ~I am supposed to have an arrow, but I don't yet...~
IF ~HasItemParty("arow01")~ ~Why did you give me an arrow?~

In this case (assuming instantaneous set), the global is actually set before the GiveItemCreate() is executed and the entire action lists would take only three AIUpdates to fully complete compared to four (reminder: SetInterrupts() are added). Also, the first transition will display (assuming instantaneous set), but the second will not (because the action is still queued).

The second option I imagine allows some flexibility so that modders can choose to instantaneously update the global, but any existing dialogue with globals issues will still have such problems.

Edited by Ascension64, 11 March 2011 - 04:48 AM.

[the bigg]

I don't see much benefit to fixing race conditions with SetGlobal() and not with other actions. Perhaps you could add an extra flag to DLG transitions (E.G. bit 9), that makes all the DO actions for that transition take place before even loading the next state; for instance:

IF ~~ THEN DO ~Action()~ GOTO 1 // sets bit 2, actions added to the queue
IF ~~ THEN DO_NOW ~Action()~ GOTO 1 // sets bit 2 and 9, actions executed before loading state 1

For testing, you can manually set flags using the FLAGS D command:

IF ~~ THEN DO ~Action()~ FLAGS ~516~ GOTO 1 // 516 = BIT2 | BIT9

Edited by the bigg, 11 March 2011 - 05:02 AM.

[Ascension64]

Hmm, that's going to make me explode, because I would have to re-write every single action such that it bypasses the action queue. KABOOM!

Edit: However, what you could do with this is use an instantaneous global as a surrogate for whatever action you want to instantaneously update. So, for the arrow giving example above, you can use the MakeArrow global to act as a surrogate for knowing that Player1 will get the arrow. Note that this putting a TakePartyItem("arow01") will still work as intended, because that will go on the action queue as well. So, you could make:

DO ~GiveItemCreate("arow01", Player1, 1, 0, 0)
~SetGlobal("MakeArrow", "GLOBAL", 1)~ GOTO Next

IF ~~ THEN BEGIN Next
SAY ~Did you get an arrow?~
IF ~Global("MakeArrow", "GLOBAL",1)~ ~I know I will definitely get an arrow after a click of the fingers~ GOTO Next2 //DO NOT USE PartyHasItem("arow01") here
IF ~~ ~I did not.~ GOTO Next3

IF ~~ THEN BEGIN Next2
SAY ~When you get the arrow, I will take it off you again.~ DO ~TakePartyItem("arow01") EXIT

IF ~~ THEN BEGIN Next3
SAY ~Well that's because you will get an arrow after a click of the fingers.~ GOTO Next2

At the very least, if I incorporate this directly into the existing SetGlobal() actions, etc., it will fix issues with Turnabout and whatnot. I am just being very cautious here when thinking about whether asynchronous behaviour will break anything, and it seems we have tried very hard to think about what happens and come up with little breakage.

Edited by Ascension64, 11 March 2011 - 03:03 PM.

[GeN1e]

Hmm, that's going to make me explode, because I would have to re-write every single action such that it bypasses the action queue. KABOOM!

I probably am missing something, but... can't the dialogue itself be changed, to not advance further until all actions have been executed?

[Ascension64]

I probably am missing something, but... can't the dialogue itself be changed, to not advance further until all actions have been executed?

Tehcnically, no. The game window updates in a very specific order:

1. Outstanding messages processed (where actions are added to game objects)
2. Key buffer processed (where the keyboard input is processed)
3. Game objects updated (where the AIUpdate occurs)
4. Window is updated (where the dialogue is updated)
LOOP

It would be really tricky for me to 'hold' the dialogue state until all objects signal they are ready.

[cmorgan]

Lunchtime reading of decompiled .dlg; I just found the thing that has been ticking around my head for the past few days - why this is a very good SetGlobal() fix rather than a tweak. Check on BioWare's handling of

Global("babytalk","GLOBAL"

and it relies on only one block between setting and reading the var within the same dialog. Heh. I could have just pointed that out instead of typing a bunch of cruft.

[Ascension64]

NI is really clunky to look at this, but I did find a two-state dependency on babytalk, of which if you were to click really fast, you would end up with NO VALID RESPONSES OR DIALOG LINKS.