Baldur1 Dialogues for Continuos Characters

[Roxanne]

Thank you very much for this report. Tested it and it's indeed a problem if Viconia is in party.

 

Assigning dialogue directly in the dialogue block that calls the EXTERN doesn't work but it can be fixed directly in the cutscene script with this code:

COPY_EXISTING ~BANCUT01.BCS~ ~override~
~BANCUT02.BCS~ ~override~
DECOMPILE_AND_PATCH BEGIN
    REPLACE_TEXTUALLY ~StartMovie("CAMP")~ ~StartMovie("CAMP")
    ActionOverride("Viconia",SetDialog("VICONJ"))~
END

I think we should consider dropping this workaround considering there may be more vanilla game cutscenes like this one and who knows how many mods add new ones to the game in similar way. If this is widespread issue than maybe it's not worth it.

 

Possible solutions:

1. Someone hacks the exe file to get rid of auto PDIALOG.2DA dialogue swap when LeaveAreaLua is used.

2. I will create a topic on Beamdog forums requesting a new opcode that could disable PDIALOG.2DA dialogue file swap if the effect is present on the creature. In other words something like this. Unlikely that they will add it, because it's not really needed from their perspective.

3. Maybe patch 1.4 will work differently or already has a way to handle this problem

4. Leave it as it is, find all other cutscenes in vanilla game that forces LeaveAreaLua without giving time for local NPC override script to re-assign correct dialogue. Warn about it in Developer's Documentation and wait for bug reports like the one you posted...

5. Go back to appending files just like in BGT with following rules:

- BG1 dialogues appended at the end of BG2 files filtered with Global("ENDOFBG1","GLOBAL",0)

- Siege of Dragonspear dialogues appended after BG1 ones filtered with Global("ENDOFBG1","GLOBAL",1)

- BG2 dialogues filtered with Global("ENDOFBG1","GLOBAL",2) where it's needed (will check BGT code where exactly it added such filtering)

Mods like BG1 NPC Project (if there will be a version with native compatibility in future) would still need to use standard Fluidstates.tpa to figure out the first state number of BG1 files that had been appended, just like in BGT.

 

The last option sounds the worst to me. Not only silly stuff like "fluidstates" variables but also junk filtering and files that may end up weighting several MBs. In other words BGT jankiness all over again... Damn.

Looks like we posted simultaneously coming to about the same conclusion.

 

It is really a rare case (if not the only in BG1) as a number of factors must come together - a cutscene leading to a transportation scene leading directly into a dialogue in which one of the few candidates for the dialogue issue is involved. I stressed my memory fo a while but cannot remember another instance of those circumstances.

If those are rare and singular cases, they may simply be dealt with individually.

[K4thos]

This problem showcased a bigger issue that I didn't anticipated. The engine broke on that EXTERN shutting down the dialogue window even though there were available other responses. This means that when you go back to old areas from BG2 and start doing some missed BG1 quests dialogue could brake if you have NPC in party that already uses BG2 dialogue variant but is called by EXTERN to use different dialogue. Something has to be done to deal with this stuff.
1. Either leave the current implementation and let modders know that additional ENDOFBG trigger may be needed along with usual IsValidForPartyDialogue / InParty / CD_STATE_NOTVALID to make sure that interjection won't show up when the dialogue file is no longer valid. EET would need to patch vanilla content in the same vein.
2.Or append all dialogue files, including ToB ones, so that all states are always available

The second option sounds like nightmare when it comes to cross-platform coding. This is why I think it may be a good idea to do it automatically after every mod is installed with relatively simple code that would analyze all dialogue files and scripts in game, append BG1 and ToB ones (using filenames stored in PDIALOG.2DA) and modify all EXTERN calls to these now appended files. Also similar changes in scripted dialogue calls.

Benefits:
- no chance for bugs in cutscenes like the one you reported
- any EXTERN and dialogue call would be valid during whole game. Only dialogues that can be normally initiated (those with proper trigger statement) would automatically receive additional filtering based on what game it comes from, so for example that cutscene with Teven would still show Viconia interjection, even if you would see it in ToB instead of BG1.
- no additional work for modders to implement this new system. Your tp2 file would be able to still append to unique BG1 and ToB dialogue files (no Fluidstates needed, no additional variables like in BGT). Merging them with BG2 ones would be done at the end by EET itself

Cons:
- EET would need to be installed in 2 steps - first on clean BG2:EE. Than separate component after all mods are installed
- that separate component would need to be uninstalled when you decide to install some additional mods later (and than installed again of course)
- very large dialogue files. Not sure if there is a limit, but if yes than we are risking reaching it

People usually don't read readme files, so something like this would guarantee tons of reports. In order to prevent it EET main component would install custom in-game main menu start screen that would inform that the installation is not finished and what to do (later replaced with proper one after you install that second component).

Opinions?

[agb1]

I think this is a case where we should all petition Beamdog to improve the situation, not rely on crazy workarounds.

[Roxanne]

This problem showcased a bigger issue that I didn't anticipated. The engine broke on that EXTERN shutting down the dialogue window even though there were available other responses. This means that when you go back to old areas from BG2 and start doing some missed BG1 quests dialogue could brake if you have NPC in party that already uses BG2 dialogue variant but is called by EXTERN to use different dialogue. Something has to be done to deal with this stuff.

1. Either leave the current implementation and let modders know that additional ENDOFBG trigger may be needed along with usual IsValidForPartyDialogue / InParty / CD_STATE_NOTVALID to make sure that interjection won't show up when the dialogue file is no longer valid. EET would need to patch vanilla content in the same vein.

2.Or append all dialogue files, including ToB ones, so that all states are always available

 

The second option sounds like nightmare when it comes to cross-platform coding. This is why I think it may be a good idea to do it automatically after every mod is installed with relatively simple code that would analyze all dialogue files and scripts in game, append BG1 and ToB ones (using filenames stored in PDIALOG.2DA) and modify all EXTERN calls to these now appended files. Also similar changes in scripted dialogue calls.

 

Benefits:

- no chance for bugs in cutscenes like the one you reported

- any EXTERN and dialogue call would be valid during whole game. Only dialogues that can be normally initiated (those with proper trigger statement) would automatically receive additional filtering based on what game it comes from, so for example that cutscene with Teven would still show Viconia interjection, even if you would see it in ToB instead of BG1.

- no additional work for modders to implement this new system. Your tp2 file would be able to still append to unique BG1 and ToB dialogue files (no Fluidstates needed, no additional variables like in BGT). Merging them with BG2 ones would be done at the end by EET itself

 

Cons:

- EET would need to be installed in 2 steps - first on clean BG2:EE. Than separate component after all mods are installed

- that separate component would need to be uninstalled when you decide to install some additional mods later

- very large dialogue files. Not sure if there is a limit, but if yes than we are risking reaching it

 

People usually don't read readme files, so something like this would guarantee tons of reports. In order to prevent it EET main component would install custom in-game main menu start screen that would inform that the installation is not finished and what to do (later replaced with proper one after you install that second component).

 

Opinions?

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.

 

agb1 just posted

*petition Beamdog to improve the situation, not rely on crazy workarounds.*

a. beandog is not providing EET and this is a pure EET issue.

b. a simple addition to a script is hardly a *crazy workaround*...

 

Doing changes to the ToB files would rather have the more massive impact on existing code. It is much more than simply appending the ToB contents to the BG1/BG2 files - at least for NPC.bcs and dialogues this will not work.

 

In summary - keep it as simple as possible and first do a thorough analysis of the existing cases - we may be chasing ghosts here (I cannot even come up with more than one example for each of the cases). Just for example: the fairytale of how you break your game when visiting BG1 areas in BG2 has been around for a decade - analysing it with a cool view in a BGT game you will find there are just two cases that will do it - but the story is repeated and repeated and like the chanters with the Bhaal prophesy everybody believes it in the end.

[Roxanne]

 

This problem showcased a bigger issue that I didn't anticipated. The engine broke on that EXTERN shutting down the dialogue window even though there were available other responses. This means that when you go back to old areas from BG2 and start doing some missed BG1 quests dialogue could brake if you have NPC in party that already uses BG2 dialogue variant but is called by EXTERN to use different dialogue. Something has to be done to deal with this stuff.

1. Either leave the current implementation and let modders know that additional ENDOFBG trigger may be needed along with usual IsValidForPartyDialogue / InParty / CD_STATE_NOTVALID to make sure that interjection won't show up when the dialogue file is no longer valid. EET would need to patch vanilla content in the same vein.

2.Or append all dialogue files, including ToB ones, so that all states are always available

 

The second option sounds like nightmare when it comes to cross-platform coding. This is why I think it may be a good idea to do it automatically after every mod is installed with relatively simple code that would analyze all dialogue files and scripts in game, append BG1 and ToB ones (using filenames stored in PDIALOG.2DA) and modify all EXTERN calls to these now appended files. Also similar changes in scripted dialogue calls.

 

Benefits:

- no chance for bugs in cutscenes like the one you reported

- any EXTERN and dialogue call would be valid during whole game. Only dialogues that can be normally initiated (those with proper trigger statement) would automatically receive additional filtering based on what game it comes from, so for example that cutscene with Teven would still show Viconia interjection, even if you would see it in ToB instead of BG1.

- no additional work for modders to implement this new system. Your tp2 file would be able to still append to unique BG1 and ToB dialogue files (no Fluidstates needed, no additional variables like in BGT). Merging them with BG2 ones would be done at the end by EET itself

 

Cons:

- EET would need to be installed in 2 steps - first on clean BG2:EE. Than separate component after all mods are installed

- that separate component would need to be uninstalled when you decide to install some additional mods later

- very large dialogue files. Not sure if there is a limit, but if yes than we are risking reaching it

 

People usually don't read readme files, so something like this would guarantee tons of reports. In order to prevent it EET main component would install custom in-game main menu start screen that would inform that the installation is not finished and what to do (later replaced with proper one after you install that second component).

 

Opinions?

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.

 

agb1 just posted

*petition Beamdog to improve the situation, not rely on crazy workarounds.*

a. beandog is not providing EET and this is a pure EET issue.

b. a simple addition to a script is hardly a *crazy workaround*...

 

Doing changes to the ToB files would rather have the more massive impact on existing code. It is much more than simply appending the ToB contents to the BG1/BG2 files - at least for NPC.bcs and dialogues this will not work.

 

In summary - keep it as simple as possible and first do a thorough analysis of the existing cases - we may be chasing ghosts here (I cannot even come up with more than one example for each of the cases). Just for example: the fairytale of how you break your game when visiting BG1 areas in BG2 has been around for a decade - analysing it with a cool view in a BGT game you will find there are just two cases that will do it - but the story is repeated and repeated and like the chanters with the Bhaal prophesy everybody believes it in the end.

 

Maybe this experience from my own mod helps:

In Sandrah - Return to Faerun you can (in a BGT game) return to all game areas BG1/BG2/ToB after you finished ToB. In this I found it necessary to do a limited clean-up of old areas, i.e.removing some left behind quest-givers or former NPCs (the later will not be necessary in EET anymore). This clean-up in most cases is done by a simple DestroySelf() and a Global - in EET this can simply be done by the continuous chapter numbering, i.e. creatures no longer valid in a later part destroy themselves when ChapterGTxx.

At this stage of development I would keep the topic open and have some trust in modmakers that may want to use the new capabilities - if I write a contents that makes you revisit eg. Nashkel, I will take care that you only meet in Nashkel what/who is still valid. In some cases I also blocked access to some critical areas (e.g. in RtF the Copper Coronet is closed due to sanitary reasons from Amn's council - too many leftover NPCs may have been sent there to wait.)

Players just wandering aimlessly around old areas may encounter some strange things and either live with it or report it, so one could react to it.

[K4thos]

Doing changes to the ToB files would rather have the more massive impact on existing code. It is much more than simply appending the ToB contents to the BG1/BG2 files - at least for NPC.bcs and dialogues this will not work.

there is no need to append BCS files. Each part of the story can use unique one like it does now. Only JOIN and POST dialogue files would be appended. BGT already does it for BG1 files, so it's not an alien concept. The difference would be doing so also for ToB dialogues - all handled automatically by EET during installation (after any other mod).

 

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?

to be honest I have no idea. I pretty much always play vanilla content and there are indeed just few interjections here and there related to the story. Not sure how it looks like in mods, especially those that adds MBs of text. If the amount of required changes wouldn't frighten off modders than the situation may not be as bad as I envisioned after analyzing consequences of your report.

 

I think this is a case where we should all petition Beamdog to improve the situation, not rely on crazy workarounds.

the easiest solution would be a way to alter CRE death variable during game. An actions that would simply (?) overwrite what is stored in the local copy of the GAM file inside the save file. But like Roxanne said chances for such thing are marginal when Beamdog don't need such functionality, especially if such changes are not desired in vanilla game (without EET changing DV mid game doesn't even make sense).

[Roxanne]

 

Doing changes to the ToB files would rather have the more massive impact on existing code. It is much more than simply appending the ToB contents to the BG1/BG2 files - at least for NPC.bcs and dialogues this will not work.

there is no need to append BCS files. Each part of the story can use unique one like it does now. Only JOIN and POST dialogue files would be appended. BGT already does it for BG1 files, so it's not an alien concept. The difference would be doing so also for ToB dialogues - all handled automatically by EET during installation (after any other mod).

 

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?

to be honest I have no idea. I pretty much always play vanilla content and there are indeed just few interjections here and there related to the story. Not sure how it looks like in mods, especially those that adds MBs of text. If the amount of required changes wouldn't frighten off modders than the situation may not be as bad as I envisioned after analyzing consequences of your report.

 

I think this is a case where we should all petition Beamdog to improve the situation, not rely on crazy workarounds.

the easiest solution would be a way to alter CRE death variable during game. An actions that would simply (?) overwrite what is stored in the local copy of the GAM file inside the save file. But like Roxanne said chances for such thing are marginal when Beamdog don't need such functionality, especially if such changes are not desired in vanilla game (without EET changing DV mid game doesn't even make sense).

 

At this point I do not really see a justification for any of those massive changes to the current approach. Until now, there was always a much simpler solution every time.

And a change of DVs violates the higher goal of a continuos game, I would really like to interact with my continuos NPCs with other continuos NPCs and forget about the (former) split of the game while we proceed from chapter to chapter and through IWD and other regions.

[agb1]

Is it possible to do something like this:

 

- Copy all states from BG1 J dialogues to BG2 J dialogues

 

- Replace all states in BG1 J dialogue with a setdialogue action to use the BG2 J dialogue, then transition to the same state in that dialogue as was used to enter the BG1 J dialogue?

 

I guess this is like K4thos' option 2 but with a variation (BG1 J dialogue becomes just a shell and redirect)

 

I guess not, if transition numbers must be unique...

[Roxanne]

Is it possible to do something like this:

 

- Copy all states from BG1 J dialogues to BG2 J dialogues

 

- Replace all states in BG1 J dialogue with a setdialogue action to use the BG2 J dialogue, then transition to the same state in that dialogue as was used to enter the BG1 J dialogue?

 

I guess this is like K4thos' option 2 but with a variation (BG1 J dialogue becomes just a shell and redirect)

This is looking at those dialogues in isolation. But they are not static. Just for example Imoen2_.dlg will have as much contents (if not more) from other mods than from vanilla game. And the same mods append later to Imoen2J.dlg for other occasions. Mixing them might turn out a nighmare.

My question to all of that - what do we gain with it, even given that it is technically possible? Is there added value?

[agb1]

Isn't the underlying problem here that the NPC is assigned the wrong dialogue (BG2 version in this case) when a script makes the NPC leave the party? I was thinking (along the line that K4thos suggested) that we could solve that by making both versions of the script do the same thing... I assume we can't control the script change itself?

[Roxanne]

Isn't the underlying problem here that the NPC is assigned the wrong dialogue (BG2 version in this case) when a script makes the NPC leave the party? I was thinking (along the line that K4thos suggested) that we could solve that by making both versions of the script do the same thing... I assume we can't control the script change itself?

This is NOT about leaving the party - leaving party correctly results in a change of dialogue.

The scenario here is LeaveAreaLUA i.e. the command used to transport PC or NPC or whole party to another location without using the worldmap (mostly done by cutscenes). The very specific case that causes issue is not even the normal case of that use but the special event that a cutscene directly ends with triggering a new dialogue AND the new dialogue has an NPC interjecting AND that NPC is one of those few who has a split joined dialogue file AND the occurance is in BG1 plot (AND it only happens when that NPC is InParty at that very moment).

And this is why my main question was - how many such cases exist? So far we know of one in the game, probably we will find a few more but they are quite rare.

[agb1]

I see. Thanks for the explanation.

[K4thos]

Thanks for feedback.

 

Isn't the underlying problem here that the NPC is assigned the wrong dialogue (BG2 version in this case) when a script makes the NPC leave the party? I was thinking (along the line that K4thos suggested) that we could solve that by making both versions of the script do the same thing...

nope, this is not about it. Only things posted today are related to the proposed change. In short - when EXTERN is used in dialogue and refers to dialogue file that is not assigned to CRE than the dialogue is broken.

 

I assume we can't control the script change itself?

We do have full control on script assignment. What is problematic is a JOIN dialogue file. Join dialogue files would need to be merged to make EET 100% reliable even if you're going back to old areas later in game, when dialogue file may no longer be valid but could be still called by some other dialogue via EXTERN (interjection). But from Roxanne words this may not be such a huge issue to warrant a treatment mentioned in second suggestion when most of such interjections are related to previous story content.

 

In this I found it necessary to do a limited clean-up of old areas

Could you please share a list of such changes (not related to joinable NPCs since that case is already handled). Currently EET filters out random dialogues (tavern rumours, random folks talks) about Iron Crisis and the ceremony in Duchal Palace and Sarevok after finishing BG1 storyline. Scripts get rid of the CRE related to Sarevok (story related encounters). Also here is a list of CRE that are currently planned to be disabled since they also appear in BG2 (will do it after full SoD implementation, just to be sure that they are not used there): Brennan Risling, Bubbles, Calahan, Dradeel, Drizzt, Neb, Volothamp Geddarm. More cleaning obviously will be needed so any help would be appreciated.

[Jarno Mikkola]

 

I assume we can't control the script change itself?

What is problematic is a JOIN dialogue file. Join dialogue files would need to be merged to make EET 100% reliable even if you're going back to old areas later in game, when dialogue file may no longer be valid but could be still called by some other dialogue via EXTERN (interjection).

 

Or you could just take control of the whole thing by joining teh BG1 - BGSoA and other parts as a 1 dialog file dictated by the chapter number system , with controls that say what part they are in the game. Of course it will be a lots of work, bu... in theory it can be done.

[K4thos]

Or you could just take control of the whole thing by joining teh BG1 - BGSoA and other parts as a 1 dialog file dictated by the chapter number system , with controls that say what part they are in the game. Of course it will be a lots of work, bu... in theory it can be done.

Not sure if I understand your post. You mean merge all join files related to a single NPC? That's exactly what I proposed in the second suggestion. Filtering and coding it without breaking the content (even added by mods) is not really a problem. In fact the code would be probably already ready for test if not for the negative feedback on this idea. I can't think about anything that could go wrong when it's done automatically at the end of the installation process (after all other mods are installed). The question is - is it really needed? If you meant something else than please clarify.