Trouble with INTERJECT_COPY_TRANS

[TotalMilk90]

I've been adding interjections into my Gorgon's Eye mod, but for some reason Imoen's are the only ones that are actually triggering. I went back to this test block with other companions after noticing they weren't working. It's just a simple one-liner said to a mod-added creature in the middle of their dialog.

This will work:

INTERJECT_COPY_TRANS h_yumild 1 imotoyum1
  == IMOEN2 IF ~IsValidForPartyDialogue("Imoen")~ THEN
    ~I've always loved a good ghost story.~
END

This will not work:

INTERJECT_COPY_TRANS h_yumild 1 imotoyum1
  == AJANTI IF ~IsValidForPartyDialogue("Ajantis")~ THEN
    ~I've always loved a good ghost story.~
END

For all non-Imoen companions, I can see that their interjections are being added to their dialog file, but not only do they not trigger, they also force the conversation to close instead of continuing to the next dialog block.

Seems weird, but maybe I'm missing something? Anything insight would be appreciated.

[Guest]

Maybe it's a dumb idea, but I think everytime I see INTERJECT_COPY_TRANS in this context it was used with the Joined dialog : AJANTJ, ALORAJ, BRANWJ...

Until someone who knows their stuff answers, it could perhaps maybe be worth a try.

Edited September 25, 2023 by JohnBob

[TotalMilk90]

Actually, thanks! That worked on my test block.
 

I was using Lava’s White Queen mod as reference which uses the J, but I assumed that was just a bg2 thing so it never crossed my mind to try it.

[jmerry]

Right. Joinable characters always have several different dialogue files, depending on their party status.

- Initial file: typically just the character's name or an abbreviation. This is the character's dialogue when first met, before ever joining the party.

- Joined file: typically adds a J to the end. This is the character's dialogue file when in the party.

- Post file: typically adds a P to the end. This is the character's dialogue file after they have been dismissed from the party.

- Banter file: typically adds a B to the front. This is an alternate dialogue file for the character in the party, accessible through the Interact() script action.

These are assigned to the characters through 2DA files; PDIALOG.2DA for the initial/joined/post transitions, and INTERDIA.2DA for the banters. Plus sometimes alternate versions of those 2DAs in different campaigns; SoD has BDDIALOG.2DA, for example. The 2DAs also serve as a convenient lookup table for the filenames to use.

If you try to jump to a file that doesn't apply right now, like using the initial file while the character is in the party, then the game looks around, finds nobody with the target dialogue file, and terminates out of the conversation.

[jastey]

@TotalMilk90 I can only recommend you have a look at the "Crossing the great divide" modding tutorial - not so that you can consider Tutu and BGT, but to see the principle of how to consider BG:EE and EET in one set of files.

That said, what you'd do is read in the cpmvars.tpa files with the definition of the NPCs' joined dialogue files, and then just use %AJANTIS_JOINED% for his dlg.

And another thing, if you want to see what the dlgs for the NPCs are, they are listed in the pdialog, 2da for BG1 & BGII / bpdialog.2da for SoD (POST_DIALOG_FILE; JOIN_DIALOG_FILE; DREAM_SCRIPT_FILE) and  interdia.2da (Banter dialogue file). They might differ for the games, that is why we use the cpmvar.tpa definitions. You can find those in almost all BG1 mods under "lib"; the ones for EET are included in the EET package itself.

[TotalMilk90]

@jmerry @jastey

Thanks for the lessons. My understanding of dialog was not at that level. The 2da files look really convenient and I wasn't aware of those at all. Also thanks for the link, I am interested in reading through it today.

Regarding the cpmvar, are you saying use its joined dialog file line in lieu of the "J"?
For instance, monty in the cpmvar list:  OUTER_SPRINT "MONTARON_JOINED" "MONTAJ"

Would simply be:

INTERJECT_COPY_TRANS h_yumild 1 imotoyum1
  == %MONTARON_JOINED% IF ~IsValidForPartyDialogue("Montaron")~ THEN
    ~I've always loved a good ghost story.~
END

Does handling it this way require adding anything to my tp2 file? 

I only vaguely remember using some of these for eet compatibility and that was a while ago.
 

[jastey]

40 minutes ago, TotalMilk90 said:

Does handling it this way require adding anything to my tp2 file? 

First, you need to include and read in the definitions, e.g.:

 ACTION_IF GAME_IS ~bgee~ THEN BEGIN
   INCLUDE ~AjantisBG1/lib/g3_bgee_cpmvars.tpa~
 END

 ACTION_IF GAME_IS ~eet~ THEN BEGIN
      INCLUDE ~EET/other/cpmvars/eet_cpmvars.tpa~
 END

Second, you need to tell the installer to evaluate the variables by adding EVALUATE_BUFFER, e.g.:

   COMPILE EVALUATE_BUFFER ~AjantisBG1/Friendship/Ajantis_friendship_d.d~

  EXTEND_TOP ~%tutu_var%ajantis.bcs~ ~AjantisBG1/ee/Ajantis_ee.baf~ EVALUATE_BUFFER 

 

[TotalMilk90]

Awesome! Thanks, I was missing the EVALUATE_BUFFER

[TotalMilk90]

INTERJECT_COPY_TRANS will create an interjection "where none already exist." So if two different mods use it on the same dialog, only one of them will work? Which one gets priority? I ask because I'm testing some interjections from Xzar and Imoen and I'm not fully understanding it.

In this case, if both of them are in the party, Xzar's interjection gets skipped and Imoen's will fire, even though his is listed first. Why would that happen?

INTERJECT_COPY_TRANS chase 0 xzartochase0
  == %XZAR_JOINED% IF ~IsValidForPartyDialogue("Xzar")~ THEN
~Blah, blah.~
END

INTERJECT_COPY_TRANS chase 0 imotochase0
  == %IMOEN_JOINED% IF ~IsValidForPartyDialogue("%IMOEN_DV%")~ THEN
~Blah.~
END

 

[jastey]

The code looks fine, how does it look compiled? There could be the trivial reason he can't talk or is too far away?

You can also combine these two interjections using I_C_T3 if you don't need the NPC specific variables later:

I_C_T3 chase 0 xyz_variable
  == %XZAR_JOINED% IF ~IsValidForPartyDialogue("Xzar")~ THEN
~Blah, blah.~
  == %IMOEN_JOINED% IF ~IsValidForPartyDialogue("%IMOEN_DV%")~ THEN
~Blah.~
END

 

[TotalMilk90]

Thanks Jastey!

I haven't actually heard of I_C_T3 before. Are you saying if I combine them using that method then all true interjections will fire even if the first one is false? If I combine them with traditional I_C_T like so: 
 

INTERJECT_COPY_TRANS chase 0 xzartochase0
  == %XZAR_JOINED% IF ~IsValidForPartyDialogue("Xzar")~ THEN
~Yes, by all means, jump! The sight of your broken corpse washing ashore will be quite the spectacle. A delightful addition to my studies of mortality.~
  == %MONTARON_JOINED% IF ~IsValidForPartyDialogue("Montaron")~ THEN
~Heh, jump if ye've got the nerve, boy. Or are ye just lookin' for someone to hold yer hand and tell ye not to? Go on, show us ye mean it!~
  == %IMOEN_JOINED% IF ~IsValidForPartyDialogue("%IMOEN_DV%")~ THEN
~Hey, wait! Don't do it! Whatever's got you feeling like this, it can't be worth your life! Just come down and talk to us!~
END

If all 3 are in the party then they all trigger. If Xzar (the first speaker) is not in the party, then none of them will trigger. If Xzar and Imoen are in the party but not Montaron, both Xzar and Imoen's will fire and it will skip over Monty.

I want everyone to be able to say an interjection separately and not have to rely on the first speaker being in the party.

The strange part is that when I did separate them into individual I_C_T blocks, Xzar's dialog gets compiled fine and he will say his line, but only if Imoen is not in party. If Imoen is in the party then only Imoen's line fires.

[jastey]

17 hours ago, TotalMilk90 said:

if I combine them using that method then all true interjections will fire even if the first one is false?

Exactly, that's what I_C_T3 does. I_C_T: all only fire if the first one is true. I_C_T3: all true will fire independent of order.

In your code snippet, you did not add the "3". It should work with it?

BG1NPC Project also uses this to combine interjections at places where several NPCs have one.

17 hours ago, TotalMilk90 said:

If Xzar (the first speaker) is not in the party, then none of them will trigger. If Xzar and Imoen are in the party but not Montaron, both Xzar and Imoen's will fire and it will skip over Monty.

Is this the behavior you got ingame? The first one I'd expect for I_C_T. The second one for I_C_T3. Am I missing something?

Note: if you interject into a state where the speaking character has an action afterwards, these actions will be transferred to the interjecting NPC. Classic "NPC xy vanished after talking to quest giver (and quest giver is still there)" bug. The way to go is NOT to use I_C_T2 (which would pass the actions back to the character) because I_C_T2 is very sensitive and leads to incompatibilities if several mods add interjections. Standard is to add a "pass back line" for the dlg the interjections are added to.

17 hours ago, TotalMilk90 said:

The strange part is that when I did separate them into individual I_C_T blocks, Xzar's dialog gets compiled fine and he will say his line, but only if Imoen is not in party. If Imoen is in the party then only Imoen's line fires.

This is weird. It might be that if coded like this (several individual I_C_T in one d-file), the compiler adds them all to the specified dlg state, but somehow does not copy all other added interjections into the NPC's dlgs because it's not done patching until the d-file is processed, or whatever. It might work if you have different d-files for different NPCs. Or use I_C_T3, this should definitely work.

Here is a tutorial, the formatting is a bit shredded but I think it's still valid: http://www.shsforums.net/topic/36995-coding-interjections/

[jastey]

Here is the file from BG1NPC Project: https://github.com/Gibberlings3/BG1NPC/blob/master/bg1npc/phase2/dlg/x%23ict3.d

Er, I see a I_C_T4 there, too, which would be I_C_T2 for multi conditions. .. Why is it used if there is a passback line (why is it used at all, lol)? I'll take this to the BG1NPC workroom.

[jastey]

6 minutes ago, jastey said:

I_C_T: all only fire if the first one is true.

Looking at the BG1NPC file i linked to, it seems I_C_T lets the first true interjection pass, regardless of place? I am confused. - It clearly is not what you need, anyway.

[TotalMilk90]

22 hours ago, jastey said:

Exactly, that's what I_C_T3 does. I_C_T: all only fire if the first one is true. I_C_T3: all true will fire independent of order.

 

This is exactly what I needed and it worked perfectly, thanks!
 

22 hours ago, jastey said:

On 9/4/2024 at 5:14 PM, TotalMilk90 said:

If Xzar (the first speaker) is not in the party, then none of them will trigger. If Xzar and Imoen are in the party but not Montaron, both Xzar and Imoen's will fire and it will skip over Monty.

Is this the behavior you got ingame? The first one I'd expect for I_C_T. The second one for I_C_T3. Am I missing something?

Yes, this is what happened in my testing. I_C_T will only trigger if the first line is true, but then it behaves like I_C_T3 by skipping over false ones but still continuing on and triggering other ones that are true.
 

22 hours ago, jastey said:

On 9/4/2024 at 5:14 PM, TotalMilk90 said:

The strange part is that when I did separate them into individual I_C_T blocks, Xzar's dialog gets compiled fine and he will say his line, but only if Imoen is not in party. If Imoen is in the party then only Imoen's line fires.

This is weird. It might be that if coded like this (several individual I_C_T in one d-file), the compiler adds them all to the specified dlg state, but somehow does not copy all other added interjections into the NPC's dlgs because it's not done patching until the d-file is processed, or whatever. It might work if you have different d-files for different NPCs. Or use I_C_T3, this should definitely work.

Just tested this and it looks like you are right. I had 3 separate I_C_T blocks in 1 dialog file and only 1 out of 3 interjections would trigger, interestingly the priority was - Monty, Imoen, Xzar, regardless of written order. But then I separated them into different d files and all of them ended up working.

I have I_C_T2 in a few places but I will remove them - I didn't know they could cause issues. I took a quick glance at pass backs in another thread, so I'll either try that or just change the dialog to always end with the speaker to avoid it altogether.

Thanks again for the help Jastey, much appreciated!