Talking about the short timers

[berelinde]

We've been seeing lots of cases where the short timer is failing, causing the global to fail to advance. We were making it longer, but that results in additional oddities when playing in a game with the optional "Force all dialogues to pause game" feature.

 

If the short timer has not yet expired, and the player initiates PID with the npc, they'll get the lovetalk or friendtalk that just fired, because the variable is not yet closed.

 

I originally had 10 second timers, to allow slower computers to catch up. Like I said, Gavin is script-heavy. But on a faster computer, I'm getting reports that PID after a talk or flirt results in getting the talk or flirt all over again. Some of those talks/flirts are kind of long. I'd hate to have to put someone through it twice.

 

Doing it the way Jastey did, closing the variable as part of the dialogue itself, is the fix.

[cmorgan]

Except that if you have a CHAIN fail on you, or something hiccups and does not allow the dialogue to fire, you get hanging. So it sounds like the combination approach is needed...

 

use a short timer of 5 or 10 with a closing block, close the variable again in the dialogue, and then create an "if it was missed close it" block like we put on for Imoen' Diamond - Imoen's script runs a bloack that looks for the "open" variable, and if the variable is open but the AreaCheck fails, it closes the variable so that she can't fire it instead of the Tarnesh scene.

[Kulyok]

Except that if you have a CHAIN fail on you, or something hiccups and does not allow the dialogue to fire, you get hanging.

 

That sounds nasty. What exactly do you mean here, could you please give examples? I've been playing BG2... well, certainly more than a hundred times, and I'm not sure I've ever encountered this.

[cmorgan]

In our current setup, we have moved all of the Phase1 materials to J file triggered events instead of relying on the banter engine. One of two things seems to happen on some installs-

 

a player who moves quickly enough interrupts the start of the expected dialogue (for example, something else happens or the player gets out of town before the Diamond interjection fires) and the BCS call hiccups, not starting the StatrtDialogueNoSet. This causes the variable to hang open, and the dialogue to "stack up". Imoen responds to Tarnesh's death, trying to call on the spellbook talk, and instead fires her diamond interjection. Over the course of play, some of these can stack up quite a bit. The answer currently is to use the PID option (whether installed or not, force-talk the NPCs) every so often, to clear the backlog.

 

In the CHAIN situation, several things seem to be possible culprits. Meira (and berelinde ) have run into situations where imoen's Banter file fails, chopping off the sequence. One time it was even a Jfile interaction, because we used an ActionOverride in the middle of the chain, doing some very odd things (this was Gorion's Burial, which is documented in the workroom); now it is both BGT and Tutu having troubles with imoen. berelinde can replicate this by installing or uninstalling mods after The BG1 NPC Project; we just don't know why it is happening. On a recent BGT install, it was another mod overwriting BIMOEN2.DLG instead of adding to the existing one. In either case, if something interrups the CHAIN, the variable is not set, and hangs open.

[berelinde]

He means that the variable was never closed, so that talk will fire instead of PID or instead of the next interjection dialogue call.

 

However, given that we're using this to close the variable for lovetalks or friendtalks, I don't think anybody is going to mind if that fires and completes instead of a scenery interjection. But then the scenery interjection is going to back up.

 

If the chain fails and the variable doesn't close, no big deal. Initiate PID or wait for an interjection and close it. Annoying, but not tragic.

 

If the script fails to advance the variable, the romance or friendship just stops dead and the player is left wondering why NPC stopped talking. If the variable never closed when it was even, they'll be able to troubleshoot the problem quickly, because PID will continue to produce the LT. But if the variable never advanced while it was odd, it's going to be messy.

 

It seems to me that it would be safest to err on the side of allowing the talk to fire instead of a PID/interjection.

[Kulyok]

I guess. I take it BG2 install is much more stable than TUTU one, because I think I had only one time when J banters stacked in BG2 - and I had Imoen Romance mod installed at the time(um... okay, deleted it long ago, never mind).

[berelinde]

I think it's just that we're placing a lot more conditions on things than BioWare ever did with BG2.

[Grand_Dracolich]

I think it's just that we're placing a lot more conditions on things than BioWare ever did with BG2.

 

Isn't that just the way it goes?

[Kulyok]

Here is the cure I am going to use for Xan:

 

For a friendship(romance) path:

IF
InParty(Myself)
RealGlobalTimerExpired("O#XanToBFriendTimer","GLOBAL")
Global("O#XanFriendship","GLOBAL",1)
!AreaType(DUNGEON)
See(Player1)
!StateCheck(Player1,CD_STATE_NOTVALID) 
!StateCheck(Myself,CD_STATE_NOTVALID)
CombatCounter(0)
!See([ENEMY])
OR(4)
Global("O#XanComTalk","GLOBAL",1)
Global("O#XanComTalk","GLOBAL",3)
Global("O#XanComTalk","GLOBAL",5)
Global("O#XanComTalk","GLOBAL",7)
THEN
RESPONSE #100
IncrementGlobal("O#XanComTalk","GLOBAL",1)
SetGlobal("O#XanCheckToBF","GLOBAL",1)
Interact(Player1)
END

IF
InParty(Myself)
Global("O#XanCheckToBF","GLOBAL",1)
Global("O#XanFriendship","GLOBAL",1)
!AreaType(DUNGEON)
See(Player1)
!StateCheck(Player1,CD_STATE_NOTVALID) 
!StateCheck(Myself,CD_STATE_NOTVALID)
CombatCounter(0)
!See([ENEMY])
OR(5)
Global("O#XanComTalk","GLOBAL",2)
Global("O#XanComTalk","GLOBAL",4)
Global("O#XanComTalk","GLOBAL",6)
Global("O#XanComTalk","GLOBAL",8)
Global("O#XanComTalk","GLOBAL",10)
THEN
RESPONSE #100
Interact(Player1)
END

IF ~Global("O#XanFriendship","GLOBAL",1) Global("O#XanComTalk","GLOBAL",2)~ O#XanCT1
SAY @273 
++ @274 DO ~Global("O#XanCheckToBF","GLOBAL",0) SetGlobal("O#XanComTalk","GLOBAL",3) RealSetGlobalTimer("O#XanToBFriendTimer","GLOBAL",3000)~ + O#XanCT1.3
...

 

For a scripted banter:

IF
InParty(Myself)
Dead("yaga01")
AreaCheck("AR5203")
See(Player1)
!StateCheck(Player1,CD_STATE_NOTVALID) 
!StateCheck(Myself,CD_STATE_NOTVALID)
CombatCounter(0)
!See([ENEMY])
Global("O#XanOtherTalk1","GLOBAL",0)
THEN
RESPONSE #100
SetGlobal("O#XanOtherTalk1","GLOBAL",1)
END

IF
InParty(Myself)
See(Player1)
!StateCheck(Player1,CD_STATE_NOTVALID) 
!StateCheck(Myself,CD_STATE_NOTVALID)
CombatCounter(0)
!See([ENEMY])
Global("O#XanOtherTalk1","GLOBAL",1)
THEN
RESPONSE #100
Interact(Player1)
END

IF ~Global("O#XanOtherTalk1","GLOBAL",1)~ O#XanOT1
SAY @500 
++ @501 DO ~SetGlobal("O#XanOtherTalk1","GLOBAL",2)~ + O#XanOT1.1A
...

 

Seems to work so far, without any stuttering and any "missed" talks. Foolproof.