Imoen is talking, but Gavin (the PC) is asleep

[berelinde]

I know there is no conditions for Player 1 to be awake for interjections, but maybe there should be.

 

Or not. That would be a heck of a lot of work at this late date.

 

There's Imoen, having a nice little chat with Gavin (the PC, just taking the stats out for a test drive, since I still don't have the tp2 written up with the new files), who is sound asleep on the steps of the Friendly Arm Inn.

[cmorgan]

What do people think? It would mean adding a condition to each Banter

!StateCheck(Player1,CD_STATE_NOTVALID)

 

and the same on the JFiles (both BAF call and DLG).

 

Problems: could mean skipped or hanging dialogue when conditions are met as materials stack up; could mean banters firing the standard 'talk' stuff or in some cases perhaps a PID firing instead on the J unless we put the same condition ( ~IsGabber(Player1) !StateCheck(Player1,CD_STATE_NOTVALID)~ )

 

Until I began messing with stuff last summer, many dialogues outside of Coran's, Dynaheir's, and Ajanis' Romances had no conditions on inclusion of NPCs on most banters and interjections beyond "InParty". Most CHAIN construction outside of the PID had straight InParty("myNPC") conditions. Doing this is relatively straightforward, if a trifle time consuming, but I just did the equivalent for the BGT side with the ~!Global("EndofBG1","GLOBAL",2)~ condition, so it could be done.

 

What I don't know here is the same as the "can NPCs participate in banters/dialogues when they are invisible"... what does author intent put as higher priority, more banters/participation, or more in-game "reality"? If we go by the code, emphasis was to be on "more banters". Any changes I have made with CC(0), CD_STATE_NOTVALID, etc. have been just following up on Domi's worklog. Project team folks, please take a look and make a decision

[Gorilym]

To be honest, I doubt it would be worth the effort - especially at this point of development. Marginal gain, at a likely cost of introducing new quirks if not outright bugs.

[berelinde]

After careful consideration, I am starting to think that the frustration induced by hanging dialog would outweigh the benefits of added realism.

 

That's a lot of files, and we're already seeing instances of hanging dialog.

 

How likely is PC to be asleep, anyway?

 

Sorry I brought it up.

[jastey]

Having "!StateCheck(Player1,CD_STATE_NOTVALID)" as condition in the script block, not in the dialogue state trigger, would not lead to problems. Assuming the dialogue would be triggered by the trigger variable that was set by the script block, of course. Adding the statecheck would only reduce the times where the script block could fire, why do you expect any hang-up dialogues and similar problems?

 

My opinion: If the PC gets answer options, having the CD_STATE_NOTVALID check on her would be nice. In general having the CD_STATE_NOTVALID check on anyone who is going to talk would be appropriate. If the PC does not have to say anything I don't care whether she would be able to listen; Sometimes I feel the NPC banters are meant for the player, anyway.

 

Invisibility: I'd assume the team members still know the other NPC is there.

EDIT: I am not too enthousiastic to say this has to be done (no volunteering from my side!), though.

[Smoketest]

I vote for realism, as usual. The challenge lies in finding the creative solution to the problem of providing realism without sacrificing content.

 

Given that there can be times when Charname or another party member is out of action, it's always good to check for such a thing. If necessary, set a flag so that dialog can try again later. If there is hanging, it's most likely due to insufficient or improper coding.

 

As to invisibility, I'm perfectly okay with party members chatting to each other even while invisible. In this case a range check is in order to ensure the party member is at least close enough to hear the conversation and be able to respond to it. Again, it's a matter of creative coding to solve the problem of realism.

[cmorgan]

I think the introduction of CD_STATE_NOTVALID on Player1 is a good realism call, and since some of the code uses the Player1 STATE_SLEEPING perhaps we should just standardize the behavior by using it across the board for CHAIN NPC work and in all SDNS blocks. After all, the player has to wake up in order for the game to proceed, and suposedly the block would fire immediately on waking.

 

Assuming the dialogue would be triggered by the trigger variable that was set by the script block, of course. Adding the statecheck would only reduce the times where the script block could fire, why do you expect any hang-up dialogues and similar problems?

Here is where we get the Legacy Code issue! I agree with Smoketest that tightening the code would help in these situations. As an example, I started a new game under Beta3, and had everything work fine on the first area getting Gorion's stuff, returning to Candlekeep, then reentering. I had all Jfile talks work fine, but did not get the "are you ok?" talk at all, because it is a timered dialogue based on ImFriendTalk, and I rushed through and CLUA'd to FAI. I killed Tarnesh, and... the "are you ok" talk fired. Force talk Imoen... and we could not clear the dialogue. No PID. Since the friend talk had become available and was triggered outside of its normal SDNS, the short timer was not set, and the variable did not increment.

 

Here is what I think happens;

ImFriendTalk timer expires while Player1 is in combat, or moving, or doing any number of things. During the combat, we clobber Tarnesh. In both cases, and multiple other ways this can happen, especially when there are See("myNPC") as a BCS trigger and a constantly moving, hiding, and/or invisible myNPC, now we have two BCS calls to SDNS. The one that fires picks up the last in queue, and since we are now out of sequence, cannot close.

 

I'm not quite sure the best way to approach this, but I know that we need even more overhauling to make it less likely that we can have J-file calls "stacking up" and firing at the wrong time. It only takes one to hang, and a whole game is off; we can beg players to clear PIDs regularly, but we are not addressing the underlying problem. For some reason, some area script triggered calls don't always fire, and players who keep their parties on the move can stop stuff from happening.

 

 

As for the invisibility thing, I think we can leave the check at replacing

 

== _myNPCJ IF ~InParty("myNPC') !Dead("myNPC")~ THEN ~dialog~

 

with

 

== _myNPCJ ~InParty("myNPC") !StateCheck("myNPC",CD_STATE_NOTVALID)~ THEN ~dialog~

 

and we should be ok. I know CamDawg has reservations and annoyances with the invisible talks, but many are forestalled by BCS conditions which include ~See("myNPC") CombatCounter(0) !See(ENEMY)~. I am up for opinions, of course. I will do the work, I just want it to advance the project not mess it up!!!

 

Side note: is !Dead("myNPC") exactly the same as StateCheck("myNPC",STATE_DEAD) ? If it is, I can remove a bunch of duplicate entries where I have both !Dead() and SC("dv",CD_S_NV).

 

As long as the BCS blocks get standardized at

~InParty("myNPC') 
!StateCheck("myNPC",CD_STATE_NOTVALID)
!StateCheck(Player1,CD_STATE_NOTVALID)
See("myNPC")
CombatCounter(0)
!See(ENEMY)
additional conditions here~

 

and dialogue respsonses by NPCS (I can add these to I_C_Ts, right???) with

== _myNPCJ ~InParty("myNPC") !StateCheck("myNPC",CD_STATE_NOTVALID)~ THEN ~dialog~

 

does anyone see a problem (other than the fact that a constantly hiding or invisible "myNPC" will never get a chance to trigger lots of the dialogues, leading to the conditions for any number of dialogues ready to trigger, as we discussed above)?

 

Note: I already replaced all relevant StateCheck calls in BAF and D in the project with CD_STATE_NOTVALID this summer. This is taking about standardizing the behavior across all dialogues and adding a check for Player1 being valid for dialogue in the initiating BCS for joined-file SDNS, and in the participation side of things for any banter file calls (Interact()) which reference PLAYER1 as a respondent. Do I need to tackle the BioWare ones too?

[berelinde]

Actually, implementing this might not be as grisly as you'd imagine.

 

Most, if not all of the banters and/or interjections use some form of CD_STATE_NOTVALID.

 

You could do a find and replace:

 

!StateCheck("imoen",CD_STATE_NOTVALID) => !StateCheck("imoen",CD_STATE_NOTVALID) !StateCheck(Player1,CD_STATE_NOTVALID)

[cmorgan]

yep... I moved almost everything I could see as I went along. There are significant portions of the mod that have no checks at all, though, just straight InParty (or even just

 

== ~_imoen2~ ~hjhgkjhgkjh~

== ~_minscJ~ ~jhglkjdiu~

 

etc. - and we need to be careful on the mass find/replace, because there are some talks that check for specific states (for example, Jastey's work on Ajantis' PIDs).

 

Of course, we are talking about only adding the !StateCheck(Player1,CD_STATE_NOTVALID) to the conditions on the BCS triggering, not on each individual line. I could work up a regexp using CamDawg's template to use TextEdit to do the replacing, too.

[cmorgan]

Update: as of this past weekend, most dialogue files in the latest Beta now standardize trigger conditions for interjections, J-file calls, and banters to

 

~InParty("myNPC") !StateCheck("myNPC",CD_STATE_NOTVALID)~

 

This replaces the following variants:

== banterfile IF ~InParty("myNPC")~

~InParty("myNPC") !Dead("myNPC")~

~InParty("myNPC") !Dead("myNPC") !StateCheck("myNPC",CD_STATE_NOTVALID)~

 

Any straight calls with conditions set beyond the triggering condition block were left alone.

Next weekend will have to be a recheck of the BCS blocks, as that really cannot be done with out careful manual additions; too many variations. At that time, any banters or StartDialogueNoSet materials will have

!StateCheck(Player1,CD_STATE_NOTVALID)

added. I am checking to see how standardized I managed to make this during the summer, as I did a good deal of work stripping the trigger blocks so that only SDNS had

See("myNPC")
CombatCounter(0)
!See(ENEMY)

; if so, I may be able to do a series of mass find/replaces for

!StateCheck(Player1,CD_STATE_NOTVALID)
See("myNPC")
CombatCounter(0)
!See(ENEMY)

[jastey]

Update: as of this past weekend, most dialogue files in the latest Beta now standardize trigger conditions for interjections, J-file calls, and banters to

 

~InParty("myNPC") !StateCheck("myNPC",CD_STATE_NOTVALID)~

I don't understand the motivation to exclude "!Dead("myNPC") " ?

[cmorgan]

I can't find the post, but I clipped it for the Workroom "Collected Wisdom" thread -

 

From CamDawg:

InParty is needed. Otherwise, CD_STATE_NOTVALID is simply the combination of these states:

 

CODE0x80000000 STATE_CONFUSED

0x00100000 STATE_FEEBLEMINDED

0x00001000 STATE_SILENCED

0x00000800 STATE_DEAD

0x00000400 STATE_ACID_DEATH

0x00000200 STATE_FLAME_DEATH

0x00000100 STATE_EXPLODING_DEATH

0x00000080 STATE_STONE_DEATH

0x00000040 STATE_FROZEN_DEATH

0x00000020 STATE_HELPLESS

0x00000008 STATE_STUNNED

0x00000004 STATE_PANIC

0x00000002 STATE_BERSERK

0x00000001 STATE_SLEEPING

 

Add all those states and you get 0x80101fef, the value of CD_STATE_NOTVALID. You may want to throw in a See("foo") trigger since STATE_INVISIBLE is not on this list. STATE_CHARMED is also not on the list as charmed creatures can't speak in the BG2 engine.

 

0x00000800 STATE_DEAD <<< I assume this means we don't need !Dead("dv") as part of the validity check. Or as I asked above, does a Master Modder have info as to whether or not !Dead=!StateCheck("dv",STATE_DEAD) ?

[jastey]

Oops, that would be good to know, yes.

 

STATE_CHARMED is also not on the list as charmed creatures can't speak in the BG2 engine.

But doesn't this mean theoretically that an NPC would try to start a dialogue with a charmed person, if CD_STATE_NOTVALID was checked on the person? What happens then?

[cmorgan]

I am not sure about the "charmed", but like the invisibility, if we skip this check we are still relatively ok for "realism". We filter out many participants in the triggering BCS (and most of the Project is now SDNS from BCS as opposed to Interact() from Banter file) by using See(). I think we are pretty tight on the conditions.

 

I do have confirmation from Grim Squeaker - !Dead() is not as stringent as !StateCheck("myNPC",STATE_DEAD) as !Dead() works with the script name and !SC("x",S_D) can work with the object (so you can't use !Dead(Myself), but you can use !StateCheck(Myself,STATE_DEAD) ). That means we can replace the !D() with !SC("x",S_D) in all cases and tighten up the conditins on all dialogue conditios relatively simply by using the pairing listed above.

 

The hardest step left to do is checking on the multiple options/conditions combinations. The replacements above went relatively (!!) quickly; it is now a manual find of things like

 

~InParty("minsc") !InParty("dynaheir")~

 

which would escape my multiple mass find/replace/rechecks.

[Guest Guest]

Speaking of Imoen (sorry, I didn't want to start a new thread over something so small), in every dialogue with her, she starts the "So how are you doing?" talk. Whats the Global I can set to stop that?