[(BG2) Bug] IfValidForPartyDialogue flakiness

CamDawg

Since @AndreaColombo is posting @devSin's laundry list of trigger/action fixes, I'd add one of my own: IfValidForPartyDialogue. The trigger seems to randomly fail, seemingly due to line-of-sight issues.

The classic issue most people experience with it is Irenicus' reveal at Spellhold, when he fails to recognize Yoshimo in the party due to IVFPD failing.

Sorry I can't be more specific, as there doesn't seem to be a consistent way to replicate this. A lot of modders just avoid the trigger by using InParty+InMyArea instead.

Cuv

Why are four of them listed in the Trigger.ids at the same address? I believe only the first one actually works reliably: IsValidForPartyDialog

   
0x40A8 IsValidForPartyDialog(O:Object*)
0x40A8 IfValidForPartyDialog(O:Object*)
0x40A8 IsValidForPartyDialogue(O:Object*)
0x40A8 IfValidForPartyDialogue(O:Object*)

CamDawg

They all resolve to the same trigger, though. The claim that one of them actually works while the other three variants don't is not one I've seen tested.

Cuv

@CamDawg LOL... well I love to make claims of many things:P Lemme rephrase... I have used IsValidForPartyDialog reliably, but then I don't use such things very often. Combat or cutscenes rarely rely on such things.

Avenger_teambg

Yeah, this is an all or nothing case

cmorgan

Current workaround is to use a combination of InParty/InMyArea (or See() or Detect() coupled with CamDawg's CD_STATE_NOTVALID check. But there are plenty of mods out there that would benefit from this being fixed.

SethDavis

at the moment, the check does the following:
check that the target sprite exists
check that it's not dead
checks for target distance (squared) is less than visual range (squared)
checks for line of sight
checks that the target is in the same area
checks that the target is not sleeping
checks that the sprite is a party member
checks that the target is not the last person you talked to

other than fixing up the mess made of the logic a bit, the fix would perhaps be to remove the line of sight (as this is probably triggered by a see call anyway(?)) ?

Avenger_teambg

The line of sight and the 'not the last person you talked to' part may be causing the problem.

CamDawg

Yeah, I'd dump the LoS check. I'd rather get a few banters with an interjection from the other side of a door or around a corner than the current behavior. IVFPD is sometimes paired with See() in a script file to initiate dialogues, but it's more commonly used by itself in dialogues to handle interjections.

Checking against the custom CD_STATE_NOTVALID* instead of STATE_SLEEPING that @cmorgan references might be an improvement, but may be beyond the scope of a fix. It's really only going to affect original BG/BG2 IVFPD dialogue, because modders will probably write multi-purpose code for BGEE/BG1/Tutu/BGT and won't be able to rely on fixed IVFPD behavior.

* CD_STATE_NOTVALID (0x80101FEF) was something added to state.ids to create a quick way to StateCheck() for dialogues--it returns true if any of these are present: STATE_CONFUSED, STATE_FEEBLEMINDED, STATE_SILENCED, STATE_HELPLESS, STATE_STUNNED, STATE_PANIC, STATE_BERSERK, STATE_SLEEPING, and the various dead states.

SethDavis

Ok, other than checking that the sprite is not not valid it looks much better now. Should be fixed.

Avenger_teambg

CamDawg said:

Checking against the custom CD_STATE_NOTVALID* instead of STATE_SLEEPING that @cmorgan references might be an improvement...

Well, i thought the problem is that IVFPD is filtering too much, not that it filters too few. So, using just SLEEPING (and DEAD) is probably not causing a problem. So, while i agree it would be an improvement, it would result in fewer interjections.

CamDawg

Avenger_teambg said:

Well, i thought the problem is that IVFPD is filtering too much, not that it filters too few. So, using just SLEEPING (and DEAD) is probably not causing a problem. So, while i agree it would be an improvement, it would result in fewer interjections.

It's not that it's filtering too much, it's that it's filtering stupidly. Irenicus missing Yoshimo in Spellhold because there's a low couch in the way is silly. Passing an interjection to a confused/panicking/feebleminded party member is also silly, but also unlikely to occur.

Or going by the forum conventions, LoS is B, state check improvements a D.

jcompton

Fixing IsValidFPD would be awesome.

Avenger_teambg said:

'not the last person you talked to' part may be causing the problem.

Maybe we're using different terminology for the same thing, but I agree that this check is unnecessary and should be removed. Might be hazy memory but I also seem to recall that IVFPD would evaluate false if you ask about the gabber, which leads to the unintuitive consequence that someone who starts a conversation isn't considered eligible to interject in it.

CamDawg

jcompton said:

Fixing IsValidFPD would be awesome.

Avenger_teambg said:

'not the last person you talked to' part may be causing the problem.

Maybe we're using different terminology for the same thing, but I agree that this check is unnecessary and should be removed. Might be hazy memory but I also seem to recall that IVFPD would evaluate false if you ask about the gabber, which leads to the unintuitive consequence that someone who starts a conversation isn't considered eligible to interject in it.

Now that you mention it, yes, I do remember that.

Bhryaen

Doesn't removing the LoS requirement make it possible for the dialogue to initiate with stealthed or Inviso party members?

SethDavis

@Bhryaen @CamDawg - It doesn't look like the new define takes invisibility as meaning invalid. Should it be added in or should we expect party members to kind of know where everyone is (or am I missing some endianness with the define)?

CamDawg

As popular as party banter is, I think most players would prefer an invisible/stealthed member chime in rather than missing dialogue.

Bhryaen

I'd prefer it more realistic and with both LoS and Inviso status taken into account, but I'm really not used to party banter anyway, so I'll defer to @CamDawg on it. If it means that it never happens while soloing, but if there's a party and Player1 starts talking and Player2 is inviso, and suddenly Player2 is in the conversation, that seems... ok... odd, but ok...

cmorgan

@Bhryaen, you are right - there are pages and pages of debate on this point. Some modders use See() as a condition and others use Detect(), and there is definitely a suspension of logic. But from a troubleshooting standpoint, I have seen "hey, Jaheira was supposed to make a banter line or interjection at point A, and she didn't! BUG!!!!". I have never seen "Good job. Imoen was hiding in the shadows, and a banter happened all around her, and she didn't speak even once!".

Personally, I let invisible/hidden characters talk. If it were me, and we were all walking in the dark and someone asked me a qwuestion, I'd answer. Unless Smaug was sleeping 10 feet away...

Cuv

@cmorgan I agree. I use both See() and Detect() ... but you can also use a state check Invisible(or improved). Depends:P Sometimes even Exists().

Bhryaen

Not sure how to test this in BG1EE... Would it apply in DYNAHE's dialog if Minsc is inviso? The Skie entry dialog initiates even if Eldoth is improved inviso. I don't see the IfValidForPartyDialogue trigger in either DLG though...

Tanthalas

I think we'd need someone to make a mini-mod with this script for testing.

Bhryaen

@Tanthalas
I was going to try to add that script to a couple Mulahey copies, make him look for Imoen and then have Imoen be invisible... but, yeah, maybe better for @cmorgan to put together if he's got the time.

Tanthalas

@Bhryaen
Yeah, I have no idea how to test it either.

And I'm not sure if that's not just a in-party banter anyway.

Avenger_teambg

You need a more sophisticated test for that.
Like Imoen is behind a wall.

Tanthalas

Ok, I moved this one back to Unconfirmed.

@Cuv, could you repeat the test but with people behind a wall of something like that?

Cuv

@Tanthalas Confirmed NOT fixed! Hehe, sorry about that. If Imoen moves to another area... then she isnt valid. But simply hidden in shadows or behind walls in other rooms, she still returns valid. The scripts can be used to test if it does get fixed.

Tanthalas

@Cuv

But I think the fix is for characters to still be detected even if they're behind walls, in which case you proved that its working.

Bhryaen

I believe... Confirmed Fixed:

Created this script:

IF
	See(Player1)
	!IsValidForPartyDialog("CORAN")
THEN
	RESPONSE #100
		DisplayStringHead(Myself,4429) // No! Now die scum!
END

IF
	See(Player1)
	IsValidForPartyDialog("CORAN")
THEN
	RESPONSE #100
		DisplayStringHead(Myself,2035) // Lovely day for a walk.
END

Then I created a CRE with that script... a flind. I like flinds... And I used my Improved Inviso Ring.

I CLUAd in Coran behind a wall out of sight but didn't recruit him.

Then I CLUAd in the flind where he wouldn't see Coran.


Then I picked up a ring on the ground so I'd be seen by the Flind. He said something mean and nasty and wicked.


So I went back to fully ImpInviso again and went around back to talk to Coran and get him in the party.


Then I went back round the corner to that mean flind and picked up the ring again. He could smell Coran was in my party now... and tried to make polite conversation. :-)



NOTES:
Now... was LoS the only thing that was changed here? @Avenger_teambg suggested getting rid of the LastTalkedToBy, but I'm not sure if @SethDavis removed anything but LoS.

Avenger_teambg

@Cuv @Tanthalas Yes, the fix was for Imoen chiming in when she is BEHIND a wall. So, this is actually confirmed fixed. LOL

Avenger_teambg

Actually, one cannot create a perfect function with so many things to check on.
The original programmer should have provided an options bitfield in which the scriptor could select what they want to check. Then the responsibility would have been transferred from programmer to scriptor