Baldur1 Dialogues for Continuos Characters

[agb1]

I'm not against a fixer component at the end of the install. We already have other end-of-install components. But if as Roxanne suggested we can just fix a few specific cutscenes and not need an extra component, even better.

[Roxanne]

I'm not against a fixer component at the end of the install. We already have other end-of-install components. But if as Roxanne suggested we can just fix a few specific cutscenes and not need an extra component, even better.

*We already have other end-of-install components.*

Means BWS, I suppose. Which is good. But many people will use EET while maybe not using BWS to install it...

Just not to mix things.

[agb1]

I meant in general, not just BWS, there is precedent for installing corrections at the end. Generalized biffing (which might not be needed for EE?) is an "install finisher" (not always last, but usually after all mods that add dialogue at least).

[K4thos]

Like in that cutscene case - things sound alarming at first but may turn out to be exceptions rather. To stick with the Viconia example - this is pure BG1 contents, Tazok is long dead in BG2.

So, the problem will only exist in dialogues that are 1. independent of the main storyline and 2. have interjects from NPCs with split dialogues. Leads to the question how many (if at all) are there?

Most I_C_T are specific to the plot and situation, so little chance that they happen in the wrong part of the game.

Most modders add those I_C_T for their own NPCs, so they are aware of the situation in EET and could take care if necessary (by adding an additional check for their dialogue). This is covered by your option 1 above.

 

After spending some time analyzing how problematic the old implementation is when it comes to mods and vanilla content I have to disagree with this. It would be extremely likely to break dialogues when the dialogue file no longer matches what is called by interjection. Of course I don't mean bugs like the one reported here but situation in which we return to BG1 areas from BG2 when the character have different dialogue assigned (or from ToB to BG1 and BG2).

 

For example Imoen from BG1 NPC Project interjects like crazy with everybody. Let's say you missed some dialogues with random people during BG1 and than go back there during BG2. Now all those missed dialogues are broken if you have Imoen in party. Ok, this may not sound so bad. But what about situations when player forgets to do some huge optional quest (or simply decide to delay it)? Now when the party travels back during ToB the quest will be broken very soon by either interjection done by vanilla NPC or some modded one (interjections are not really limited to main story quests - see "Cult of the Unseen Eye", Trademeet etc.). Should EET clean out all quest givers just because of this problem? That's the opposite of the goal here - finishing each part of the story is meant to be treated like finishing any other chapter.

 

Let's say we add additional trigger filtering to all vanilla interjections and force it on modders (which would be a mess for compatibility with mods btw.), so that they don't show up when the dialogue is no longer valid. But now we ended up with dumbed down version of the quest where there are no interjections whatsoever.

 

Another example: IWD-in-EET is meant to be played in any part of the story. Should modders patch BG1 dialogue, BG2 dialogue and ToB dialogue to interject properly if they wish to add such content?

 

-----------

 

This implementation is flawed in my opinion and would be long gone if not for my previous lack of understanding how compiled EXTERN command is interpreted by the engine. Merging JOIN/POST/BANTER dialogue files is better approach in this situation, imo. Like I mentioned before there is no need to revolutionize how the mods are written. Also the new implementation doesn't have quirks from BGT where you need to manually add filtering for merged dialogues and watch out for changed state numbers. Modders can work with vanilla files without complicating it. At the end of installation (after any other mod is installed) EET will do the merging automatically and add proper filtering to script initiated dialogues, so everything works exactly like now, but with always available interjections.

 

Since we are no longer relaying on ToB PDIALOG.2DA and INTERDIA.2DA entries whole MoveToExpansion() no longer makes much sense, imo. I think it's better to integrate the ToB properly instead of treating it differently than other parts of the story. Here are some benefits of this change:

- ToB now uses the same GUI and saves as other parts of the story,

- I've patched executable to run BALDUR.BCS even during ToB, so the main menu slot became open for another game - I've placed Shadows of Amn there, so you can now start EET in either BG1 or BG2 from the main menu,

- Returning from ToB to old areas no longer breaks conversations due to not valid dialogues

 

Quote from updated documentation regarding these changes:

 

Working with files that are merged during installation

EET is installed in two steps - main component on a clean BG2:EE, and second component at the end, after any other mods. This second step is used to automatically merge BG1, SoD, BG2, ToB files that are normally controlled by PDIALOG.2DA and INTERDIA.2DA. You need to know following things when working natively with EET:

• BALDUR.BCS / BALDUR25.BCS - the game now uses BALDUR.BCS global script during whole game. BALDUR25.BCS is no longer used even in Throne of Bhaal. The vanilla script has been expanded with all relevant content from BG:EE global script (4 new blocks) as well as ToB "25" version of it (6 new blocks) using standard trigger filtering. Mods that supports EET should always patch BALDUR.BCS instead of BALDUR25.BCS.
• JOIN / POST / BANTER dialogues and DREAM scripts - these files are normally automatically assigned by PDIALOG.2DA and INTERDIA.2DA. In EET it's also true but the platform doesn't use ToB and BG1 variants of these files. To not introduce changes in how cross-platform coding is usually handled, EET does the merging of vanilla content as well as updating state numbers in dialogues and references in scripts and cre files automatically at the end. Files should be patched exactly the same as you would do in vanilla games. No need to worry about state numbers (same as in vanilla games) or additional trigger filtering. For example when you want to add content to BG1, BG2 and ToB Neera join dialogue files than you should do it by patching NEERAJ_.DLG (BG1 file uses standard renaming due to conflict with BG2 file), NEERAJ.DLG and NEERA25J.DLG. When all other mods are installed and files have already all relevant changes, EET second component will convert them to use this system.

   

  New BG1 NPCs added by mods don't need any merging. If your mod adds BG2 joinable NPC with separate JOIN / POST / BANTER dialogue files and DREAM scripts for SoA and ToB than you can add EET compatibility in 2 ways:

  1. Merge them yourself using proper trigger filtering, so they are relevant only during part of the story (not really worth it if your mod supports cross-platform coding)
  2. Or use pre-made EET_NPC_ENDMERGE action function, available within EET_functions.tph. Below code will generate array based on what has been included in PDIALOG.2DA and INTERDIA.2DA and than append it to EET/lib/EET_end.tph file. This way your NPC will be converted to use this system at the end of installation (after all other mods are installed).

LAF ~EET_NPC_ENDMERGE~ STR_VAR dv = "NPCDeathVariable" END

 

In other words not really a problem when it comes to compatibility with other mods. Only BG2 NPCs are affected but they just need 1 additional line in code to add them into merging pool (I couldn't use 2DA entries because BG1 NPCs don't need any merging unless they are characters that migrates to BG2 with separate dialogues). Things like one time ToB override script assignining has been implemented to the existing EET_NPC_TRANSITION function (already used by BG2 NPC mods that supports EET).

 

Installation of that second EET component on vanilla EET without any mods takes about 1 minute and with BG1 NPC Project (larger than whole BG1 text wise) + 20 additional BG2 NPCs from the compatibility list - about 3 minutes on my slow laptop, so not the end of the world, imo. If it's not installed than following screen is visible instead of the main menu, so there is no way that someone will forget to install it:

 

Of course nothing is set in stone, so feel free to criticise the current implementation. We can change it back if you convince us that it's not really a good idea. Sorry for the "wall post"

 

edit: forgot to mention the obvious - new EET beta supporting this system is available on GitHub. BG2 NPCs also received proper patches update.

[agb1]

This is very well done, is what I think. Kudos.

[Roxanne]

Sounds like a great idea - on first sight...BUT

 

Can you elaborate a bit on how merging of BG/BG2 and ToB25 files is actually going to happen. BCS and DLG files are used in the game according to a sequence of how code blocks, dialogue states etc are read and executed.

You cannot just append the 25 files to the BG2 files and expect the same result, unless all your dialogues and scripts are coded for that (which I doubt is done) My concern is mostly about the 25 files which will have an overlap (for NPCs that had a BG2 and a ToB part) and/or use similar triggers (something like EndofBG1 Global did not exist for ToB files, as this was never necessary dur to the use of different files.)

At least for my own mod (NPCs with continuous BG1/BG2 files and scripts + dedicated set for ToB and sequels) the new approach requires a complete re-writing and integration of the ToB contents. (To some extend this would also apply to a number of other mods with BG2 AND ToB contents).

 

A complete new approach, but I guess you have done some analysis and my concerns are superfluous...

[Roxanne]

Sounds like a great idea - on first sight...BUT

 

Can you elaborate a bit on how merging of BG/BG2 and ToB25 files is actually going to happen. BCS and DLG files are used in the game according to a sequence of how code blocks, dialogue states etc are read and executed.

You cannot just append the 25 files to the BG2 files and expect the same result, unless all your dialogues and scripts are coded for that (which I doubt is done) My concern is mostly about the 25 files which will have an overlap (for NPCs that had a BG2 and a ToB part) and/or use similar triggers (something like EndofBG1 Global did not exist for ToB files, as this was never necessary dur to the use of different files.)

At least for my own mod (NPCs with continuous BG1/BG2 files and scripts + dedicated set for ToB and sequels) the new approach requires a complete re-writing and integration of the ToB contents. (To some extend this would also apply to a number of other mods with BG2 AND ToB contents).

 

A complete new approach, but I guess you have done some analysis and my concerns are superfluous...

Another consideration - you said

either interjection done by vanilla NPC or some modded one (interjections are not really limited to main story quests - see "Cult of the Unseen Eye", Trademeet etc.). Should EET clean out all quest givers just because of this problem?

The answer in a number of cases actually is YES. Some of these side-quests are really imbedded in the main story and also deeply related with NPCs and among each other e.g. Trademeet and Cernd, Nalia and d'Arnise, Valygar and Planar Sphere - in addition they are related to strongkolds which in return are related with going to Brynlaw etc etc. Doing these quests in ToB has more issues than just some NPC interjections.

When you talk about re-visiting old areas at a later stage, it should be - either for quests that are not related directly or indirectly to the main (Bhaalspawn) plot - or that are new for this purpose.

[Jarno Mikkola]

Whahahahahahaa. It worked.

Ouh, by the way, you are crazy work horse K4thos, respect.

 

 

 

At least for my own mod (NPCs with continuous BG1/BG2 files and scripts + dedicated set for ToB and sequels) the new approach requires a complete re-writing and integration of the ToB contents.

Nope, at worst, you just have to recode the IF statements for all your BG1, SoA, and ToB dialogs. And assuming the SoA is the standards, just the other 2... and while the BG1's already should have the not EndOfBG1 = 2... the ToB's just need a valid variable just like the BG1's, and that's actually easy to insert automatically when compiling from a different dialog file, as you can use the exact method my LStest tool uses, and then just merge the whole freaking 3-4(BG1, BG1:SotDs, BG2:SoA, BG2:ToB) files to be one. Easy. The ***P files as SoA*P files, and ***J files as SoA*J files.

[K4thos]

Sounds like a great idea - on first sight...BUT

 

Can you elaborate a bit on how merging of BG/BG2 and ToB25 files is actually going to happen. BCS and DLG files are used in the game according to a sequence of how code blocks, dialogue states etc are read and executed.

You cannot just append the 25 files to the BG2 files and expect the same result, unless all your dialogues and scripts are coded for that (which I doubt is done) My concern is mostly about the 25 files which will have an overlap (for NPCs that had a BG2 and a ToB part) and/or use similar triggers (something like EndofBG1 Global did not exist for ToB files, as this was never necessary dur to the use of different files.)

At least for my own mod (NPCs with continuous BG1/BG2 files and scripts + dedicated set for ToB and sequels) the new approach requires a complete re-writing and integration of the ToB contents. (To some extend this would also apply to a number of other mods with BG2 AND ToB contents).

 

A complete new approach, but I guess you have done some analysis and my concerns are superfluous...

Hmm, I see I have a problem with describing clearly what I mean. Merging JOIN, POST, BANTER dialogue files and DREAM scripts (so only things that are controlled by PDIALOG.2DA and INTERDIA.2DA, override scripts are not merged) doesn't mean just combining files. It means:

- reading whole content of the file and adding proper trigger filtering depending on which part of the story they come from, based on what is stored in EET/lib/EET_end.tph. Currently it's done with "endofbg1" and "endofbg2" variables that are set by EET, but in future it will be changed to less confusing "chapter" variable. Dialogue file only receives filtering if the state can be called by script (which means already has some triggers). Dream scripts receivs filtering in each block.

- combining these files together

- updating all DLG, BCS and CRE files that exists in game to change references to files and updating old state numbers into new ones

 

All of this is done by this file. Notice that it also uses EET macros. Before conversion you will see messages like this printed on the screen:

Preparing NEERAJ.dlg source file (540 states starting from 0)
Appending NEERAJ_.dlg to NEERAJ.dlg (172 appended states starting from 540)
Appending NEERA25J.dlg to NEERAJ.dlg (173 appended states starting from 712)

And than tons of prints like:

Patching BMONTA.DLG: BMINSC_ => BMINSC - dlg; 419 => 778 - state
Patching BIMOEN2.DLG: BJAHEI25 => BJAHEIR - dlg; 166 => 1275 - state

and so forth.

 

As for the mods that adds new NPCs to the pool of files for merging, here is what is generated when you install 20 BG2 NPCs that uses the new EET_NPC_ENDMERGE function that appends data based on what is found in PDIALOG.2DA and INTERDIA.2DA into EET/lib/EET_end.tph:

 

 

//appended by C#Ajantis NPC
ACTION_DEFINE_ASSOCIATIVE_ARRAY table_append_dlg BEGIN
~C#AjanJ~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~C#Aja25J~ , ~C#AjanJ~ => ~Global("ENDOFBG2","GLOBAL",2)~
~C#AjanP~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~C#Aja25P~ , ~C#AjanP~ => ~Global("ENDOFBG2","GLOBAL",2)~
~C#AjanB~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~C#Aja25B~ , ~C#AjanB~ => ~Global("ENDOFBG2","GLOBAL",2)~
END
ACTION_DEFINE_ASSOCIATIVE_ARRAY table_append_bcs BEGIN
~C#AjanD~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~C#Aja25D~ , ~C#AjanD~ => ~Global("ENDOFBG2","GLOBAL",2)~
END
//appended by CMAlora NPC
ACTION_DEFINE_ASSOCIATIVE_ARRAY table_append_dlg BEGIN
~CMALORAJ~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~CMALO25J~ , ~CMALORAJ~ => ~Global("ENDOFBG2","GLOBAL",2)~
~CMALORAP~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~CMALO25P~ , ~CMALORAP~ => ~Global("ENDOFBG2","GLOBAL",2)~
~BCMALOR~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~BCMALO25~ , ~BCMALOR~ => ~Global("ENDOFBG2","GLOBAL",2)~
END
//appended by ADANGEL NPC
ACTION_DEFINE_ASSOCIATIVE_ARRAY table_append_dlg BEGIN
~ADANGELJ~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~ADANG25J~ , ~ADANGELJ~ => ~Global("ENDOFBG2","GLOBAL",2)~
~ADANGELP~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~ADANG25P~ , ~ADANGELP~ => ~Global("ENDOFBG2","GLOBAL",2)~
~BADANGEL~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~BADANG25~ , ~BADANGEL~ => ~Global("ENDOFBG2","GLOBAL",2)~
END
ACTION_DEFINE_ASSOCIATIVE_ARRAY table_append_bcs BEGIN
~ADANGELD~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~ADANG25D~ , ~ADANGELD~ => ~Global("ENDOFBG2","GLOBAL",2)~
END
//appended by K#AUREN NPC
ACTION_DEFINE_ASSOCIATIVE_ARRAY table_append_dlg BEGIN
~K#AurenJ~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~K#Aur25J~ , ~K#AurenJ~ => ~Global("ENDOFBG2","GLOBAL",2)~
~K#AurenP~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~K#Aur25P~ , ~K#AurenP~ => ~Global("ENDOFBG2","GLOBAL",2)~
~K#AurenB~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~K#Aur25B~ , ~K#AurenB~ => ~Global("ENDOFBG2","GLOBAL",2)~
END
//appended by O#Bran NPC
ACTION_DEFINE_ASSOCIATIVE_ARRAY table_append_dlg BEGIN
~O#BranJ~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~O#Bra25J~ , ~O#BranJ~ => ~Global("ENDOFBG2","GLOBAL",2)~
~O#BranP~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~O#Bra25P~ , ~O#BranP~ => ~Global("ENDOFBG2","GLOBAL",2)~
~O#BBran~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~O#BBra25~ , ~O#BBran~ => ~Global("ENDOFBG2","GLOBAL",2)~
END
ACTION_DEFINE_ASSOCIATIVE_ARRAY table_append_bcs BEGIN
~O#BranD~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~O#Bra25D~ , ~O#BranD~ => ~Global("ENDOFBG2","GLOBAL",2)~
END
//appended by O#Coran NPC
ACTION_DEFINE_ASSOCIATIVE_ARRAY table_append_dlg BEGIN
~O#CoranJ~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~O#Cor25J~ , ~O#CoranJ~ => ~Global("ENDOFBG2","GLOBAL",2)~
~O#CoranP~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~O#Cor25P~ , ~O#CoranP~ => ~Global("ENDOFBG2","GLOBAL",2)~
~BO#Coran~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~BO#Cor25~ , ~BO#Coran~ => ~Global("ENDOFBG2","GLOBAL",2)~
END
//appended by L#FOU NPC
ACTION_DEFINE_ASSOCIATIVE_ARRAY table_append_dlg BEGIN
~L#FouJ~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~L#Fou25J~ , ~L#FouJ~ => ~Global("ENDOFBG2","GLOBAL",2)~
~L#FouP~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~L#Fou25P~ , ~L#FouP~ => ~Global("ENDOFBG2","GLOBAL",2)~
~L#FouB~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~L#Fou25B~ , ~L#FouB~ => ~Global("ENDOFBG2","GLOBAL",2)~
END
//appended by rh#Isra2 NPC
ACTION_DEFINE_ASSOCIATIVE_ARRAY table_append_dlg BEGIN
~rh#isrj~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~rh#is25j~ , ~rh#isrj~ => ~Global("ENDOFBG2","GLOBAL",2)~
~rh#isrp~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~rh#is25p~ , ~rh#isrp~ => ~Global("ENDOFBG2","GLOBAL",2)~
~brh#isr~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~brh#is25~ , ~brh#isr~ => ~Global("ENDOFBG2","GLOBAL",2)~
END
ACTION_DEFINE_ASSOCIATIVE_ARRAY table_append_bcs BEGIN
~rh#isrd~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~rh#is25d~ , ~rh#isrd~ => ~Global("ENDOFBG2","GLOBAL",2)~
END
//appended by J#Kelsey NPC
ACTION_DEFINE_ASSOCIATIVE_ARRAY table_append_dlg BEGIN
~J#KlsyJ~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~J#Kls25J~ , ~J#KlsyJ~ => ~Global("ENDOFBG2","GLOBAL",2)~
~J#KlsyP~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~J#Kls25P~ , ~J#KlsyP~ => ~Global("ENDOFBG2","GLOBAL",2)~
~BJ#Klsy~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~BJ#Kls25~ , ~BJ#Klsy~ => ~Global("ENDOFBG2","GLOBAL",2)~
END
ACTION_DEFINE_ASSOCIATIVE_ARRAY table_append_bcs BEGIN
~J#KlsyD~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~J#Kls25D~ , ~J#KlsyD~ => ~Global("ENDOFBG2","GLOBAL",2)~
END
//appended by P#KIVAN NPC
ACTION_DEFINE_ASSOCIATIVE_ARRAY table_append_dlg BEGIN
~P#KIVJ~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~P#KI25J~ , ~P#KIVJ~ => ~Global("ENDOFBG2","GLOBAL",2)~
~P#KIVP~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~P#KI25P~ , ~P#KIVP~ => ~Global("ENDOFBG2","GLOBAL",2)~
~BP#KIV~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~BP#KIV25~ , ~BP#KIV~ => ~Global("ENDOFBG2","GLOBAL",2)~
END
ACTION_DEFINE_ASSOCIATIVE_ARRAY table_append_bcs BEGIN
~P#KIVD~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~P#KI25D~ , ~P#KIVD~ => ~Global("ENDOFBG2","GLOBAL",2)~
END
//appended by P#DEHER NPC
ACTION_DEFINE_ASSOCIATIVE_ARRAY table_append_dlg BEGIN
~P#DEHJ~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~P#DE25J~ , ~P#DEHJ~ => ~Global("ENDOFBG2","GLOBAL",2)~
~P#DEHP~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~P#DE25P~ , ~P#DEHP~ => ~Global("ENDOFBG2","GLOBAL",2)~
~BP#DEH~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~BP#DEH25~ , ~BP#DEH~ => ~Global("ENDOFBG2","GLOBAL",2)~
END
//appended by K#SARAH NPC
ACTION_DEFINE_ASSOCIATIVE_ARRAY table_append_dlg BEGIN
~K#SarahJ~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~K#Sar25J~ , ~K#SarahJ~ => ~Global("ENDOFBG2","GLOBAL",2)~
~K#SarahP~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~K#Sar25P~ , ~K#SarahP~ => ~Global("ENDOFBG2","GLOBAL",2)~
~K#SarahB~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~K#Sar25B~ , ~K#SarahB~ => ~Global("ENDOFBG2","GLOBAL",2)~
END
ACTION_DEFINE_ASSOCIATIVE_ARRAY table_append_bcs BEGIN
~K#SarahD~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~K#Sar25D~ , ~K#SarahD~ => ~Global("ENDOFBG2","GLOBAL",2)~
END
//appended by SKIEDV NPC
ACTION_DEFINE_ASSOCIATIVE_ARRAY table_append_dlg BEGIN
~1xSkieJ~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~1xSki25J~ , ~1xSkieJ~ => ~Global("ENDOFBG2","GLOBAL",2)~
~1xSkieP~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~1xSki25P~ , ~1xSkieP~ => ~Global("ENDOFBG2","GLOBAL",2)~
~1xSkieB~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~1xSki25B~ , ~1xSkieB~ => ~Global("ENDOFBG2","GLOBAL",2)~
END
//appended by O#Tiax NPC
ACTION_DEFINE_ASSOCIATIVE_ARRAY table_append_dlg BEGIN
~O#TiaxJ~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~O#Tia25J~ , ~O#TiaxJ~ => ~Global("ENDOFBG2","GLOBAL",2)~
~O#TiaxP~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~O#Tia25P~ , ~O#TiaxP~ => ~Global("ENDOFBG2","GLOBAL",2)~
~BO#Tiax~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~BO#Tia25~ , ~BO#Tiax~ => ~Global("ENDOFBG2","GLOBAL",2)~
END
//appended by G#Tyris NPC
ACTION_DEFINE_ASSOCIATIVE_ARRAY table_append_dlg BEGIN
~G#TYRISJ~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~G#TRS25J~ , ~G#TYRISJ~ => ~Global("ENDOFBG2","GLOBAL",2)~
~G#TYRISP~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~G#TRS25P~ , ~G#TYRISP~ => ~Global("ENDOFBG2","GLOBAL",2)~
~BG#TYRIS~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~BG#TRS25~ , ~BG#TYRIS~ => ~Global("ENDOFBG2","GLOBAL",2)~
END
ACTION_DEFINE_ASSOCIATIVE_ARRAY table_append_bcs BEGIN
~G#TYRISD~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~G#TRS25D~ , ~G#TYRISD~ => ~Global("ENDOFBG2","GLOBAL",2)~
END
//appended by O#XAN NPC
ACTION_DEFINE_ASSOCIATIVE_ARRAY table_append_dlg BEGIN
~O#XANJ~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~O#XAN25J~ , ~O#XANJ~ => ~Global("ENDOFBG2","GLOBAL",2)~
~O#XANP~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~O#XAN25P~ , ~O#XANP~ => ~Global("ENDOFBG2","GLOBAL",2)~
~BO#XAN~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~BO#XAN25~ , ~BO#XAN~ => ~Global("ENDOFBG2","GLOBAL",2)~
END
ACTION_DEFINE_ASSOCIATIVE_ARRAY table_append_bcs BEGIN
~O#XAND~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~O#XAN25D~ , ~O#XAND~ => ~Global("ENDOFBG2","GLOBAL",2)~
END
//appended by YxYve NPC
ACTION_DEFINE_ASSOCIATIVE_ARRAY table_append_dlg BEGIN
~YxYveJ~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~YxYv25J~ , ~YxYveJ~ => ~Global("ENDOFBG2","GLOBAL",2)~
~YxYveP~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~YxYv25P~ , ~YxYveP~ => ~Global("ENDOFBG2","GLOBAL",2)~
~YxYveB~ , ~~ => ~Global("ENDOFBG1","GLOBAL",2)
GlobalLT("ENDOFBG2","GLOBAL",2)~
~YxYv25B~ , ~YxYveB~ => ~Global("ENDOFBG2","GLOBAL",2)~
END

 

 

 

Does this make sense, or should I try to clarify it more? Maybe someone would like to help me explaining the process in less confusing manner - that would be helpful for writing documentation.

[K4thos]

At least for my own mod (NPCs with continuous BG1/BG2 files and scripts + dedicated set for ToB and sequels) the new approach requires a complete re-writing and integration of the ToB contents.

this literally changes nothing in your mod. Sandrah should be installed before the merging takes place. You can even still use seprate ToB files for your mod and than add them for merging. They will work exactly the same as before merging, just with working interjections during whole game.

 

you cannot just append the 25 files to the BG2 files and expect the same result

yes you can (although currently we are appending max 3 files - or 4 if SoD will have separate dialogue files), that's the point.

 

1. This will be true only in BG2:

GlobalGT("CHAPTER","GLOBAL",14)
GlobalLT("CHAPTER","GLOBAL",22)

2. This in BG1:

GlobalLT("CHAPTER","GLOBAL",8)

3. This in ToB

GlobalGT("CHAPTER","GLOBAL",21)

And these triggers are added automatically based on which point of the story the dialogue comes from (which means nothing is changed compared to situation if those file were separate and assigned in different part of the story), exactly in places that needs them (so not in blocks that didn't have any triggers). Just to be sure I will repeat it again - NPC override scripts are NOT merged.

 

Currently the pre-made function that adds NPCs to merging pool only does it for BG2 NPCs but it's a matter of 5 lines of code to append all Sandrah files (including BG1 ones) manually into the tph file. Or you can switch to using merged dialogue files from the get go and have full control over trigger filtering, although that would be some additional work.

[Roxanne]

 

At least for my own mod (NPCs with continuous BG1/BG2 files and scripts + dedicated set for ToB and sequels) the new approach requires a complete re-writing and integration of the ToB contents.

this literally changes nothing in your mod. Sandrah should be installed before the merging takes place. You can even still use seprate ToB files for your mod and than add them for merging. They will work exactly the same as before merging, just with working interjections during whole game.

 

you cannot just append the 25 files to the BG2 files and expect the same result

yes, you can (although we are appending max 3 files - or 4 if SoD will have separate dialogue files), that's the point.

 

1. This will be true only in BG2:

GlobalGT("CHAPTER","GLOBAL",14)
GlobalLT("CHAPTER","GLOBAL",22)

2. This in BG1:

GlobalLT("CHAPTER","GLOBAL",8)

3. This in ToB

GlobalGT("CHAPTER","GLOBAL",21)

And these triggers are added automatically based on from which point of the story the dialogue comes from (whicj means nothing changes compared to situation if those file were separate and assigned in different part of the story), exactly in places that needs them (so not in blocks that didn't have any triggers). Just to be sure I will repeat it again - NPC override scripts are NOT merged.

 

Yes, using the continuous Chapter numbering came as well to my mind.

I am still not sure I understood this *NPC override scripts are NOT merged*.

Does it mean, the 25.bcs will be used if GlobalGT("CHAPTER","GLOBAL",21)?

How are creatures treated that are pure ToB?? e.g. LR Irenicus, Illyios, my own RtF NPCs? I can guess they will remain unschanged since they have only 25.dlg and 25,bcs and those are just treated as normal scripts/2,da entries?

 

And most likely it is just my very own problem to solve once I have understood the whole convention used in EET. Looks like no macros will help in the special way I did my BGT-only.mod...

Anyway. it is worth my effort as I need to re-do some parts of the mod like transition from BG1 to BG2 via SoD (Not the technical issue, which is already done by EET, but the continuous storyline I want to have). Same needs to be done for BG2 to ToB as I was building on the old TDD intermezzo between Ellessime and ToB start which maybe will not be part of TDDz and EET - so I must re-write that part of my mod. In short. former ToB files need to be merged with BG2 not just technically but also contentswise to allow for seamless operation across former game parts.

Finally - I hope there is no performance issue in EET. Merging everything for Sandrah means her override.bcs has 30.000+ lines and her joined.dlg about 8000 states (both growing if IWD is included).

[K4thos]

I am still not sure I understood this *NPC override scripts are NOT merged*.

Does it mean, the 25.bcs will be used if GlobalGT("CHAPTER","GLOBAL",21)?

Let's take Minsc as an example:

- he starts in BG1 with MINSC_.BCS override script (MINSC.BCS from vanilla BG:EE, just renamed due to conflict with BG2 resources)

- during BG2 transition his script is changed to MINSC.BCS (vanilla BG2:EE script)

- during ToB transition (or later when he is summoned by Fate Spirit) MINSC25.BCS is assigned to him.

 

Why would you add CHAPTER filtering there? It's not needed at all. We have full control on what script is assigned and when. You can assign whatever you wish for RTF or continue to use ToB script - it doesn't matter.

 

Only Dream scripts are merged because they are forced on us by PDIALOG.2DA, and we no longer use MoveToExpansion() to switch into ToB files.

 

How are creatures treated that are pure ToB?? e.g. LR Irenicus, Illyios, my own RtF NPCs? I can guess they will remain unschanged since they have only 25.dlg and 25,bcs and those are just treated as normal scripts/2,da entries?

correct, if creature doesn't have multiple dialogue or dream files than it doesn't need any merging. For example Sarevok from ToB or Yoshimo from SoA (even if "Keeping Yoshimo" mod is installed because that mod still uses vanilla SoA files even in ToB).

[K4thos]

And most likely it is just my very own problem to solve once I have understood the whole convention used in EET. Looks like no macros will help in the special way I did my BGT-only.mod...

tell me exactly what the problem is and I will write a macro to change it automatically. For now I don't see anything in this change that would affect your mod.

 

Finally - I hope there is no performance issue in EET. Merging everything for Sandrah means her override.bcs has 30.000+ lines and her joined.dlg about 8000 states (both growing if IWD is included).

once again, override scripts are not merged

and IMOEN2J.DLG after merging (with those 20 BG2 NPC mods installed as well as BG1 NPC Project) has 5442 states - no performance issue observed when she is interjecting, so I doubt that there will be a problem for Sandrah.

[Roxanne]

 

And most likely it is just my very own problem to solve once I have understood the whole convention used in EET. Looks like no macros will help in the special way I did my BGT-only.mod...

tell me exactly what the problem is and I will write a macro to change it automatically. For now I don't see anything in this change that would affect your mod.

 

Finally - I hope there is no performance issue in EET. Merging everything for Sandrah means her override.bcs has 30.000+ lines and her joined.dlg about 8000 states (both growing if IWD is included).

once again, override scripts are not merged

and IMOEN2J.DLG after merging (with all those BG2 NPC mods installed as well as BG1 NPC Project) has 5442 states - no performance issue observed when speaking to her.

 

Sounds good - thank you very much for taking the time to explain this to me.

 

So in summary, things required to do for me are

1. Merge dream scripts into one (check triggers and update if necessary)

2. Update crossmod references of some NPCs in BG1 to their BG2 joined dialogues.

(3, ?? update some crossmod references of some NPCs in ToB to their BG2 joined dialogues.??)

 

Otherwise I now do not see any further problems as all my conversations use unique triggers and are not affected by those merges.

[K4thos]

(3, ?? update some crossmod references of some NPCs in ToB to their BG2 joined dialogues.??)

no, you still work with vanilla files. Merging is done at the end, after your mod is installed. Before it takes place all vanilla and mod added files looks exactly the same as they look now in your installation or in vanilla games (separate files for SoA and ToB, same states, no additional triggers required).

 

2. Update crossmod references of some NPCs in BG1 to their BG2 joined dialogues.

again no. See above. Just keep in mind that some BG1 files are renamed due to conflicts with BG2 files.

 

1. Merge dream scripts into one (check triggers and update if necessary)

it would be less work for you (in fact no work at all) if you simply append your NPC to be merged by setup-EET_end.exe at the end of installation for both join/post/banter dialogues and dream scripts, so it's not really needed. But yes, you can use single file in your mod and filter it as you wish instead of relaying on automated solution.

 

-------------

 

just forget that files are even merged. Don't think about state numbers. Work with files that are available before merging takes place.