Baldur1 Dialogues for Continuos Characters

[Roxanne]

 

(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 (same states, no additional triggers required).

 

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

again no. See above.

 

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

it would be easier if you simply append your NPC to be merged by setup-EET_end.exe at the end of installation, so not really needed, but yes, you can do it yourself, but probably not worth it.

 

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

 

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

 

Fine - I will work based on these assumptions - I may need to revisit the topic later, when IWD is in EET (not sure how to handle the issue that you can visit IWD in all parts of the game - so where to put the crossmod??? BG2 or ToB?? or maybe it does not matter at all.)

[K4thos]

(not sure how to handle the issue that you can visit IWD in all parts of the game - so where to put the crossmod??? BG2 or ToB?? or maybe it does not matter at all.)

it doesn't matter at all. When you use CHAIN command than it ends up as a state block without any trigger filtering, which is than called by external dialogue file. That state will be available after merging regardless of the file that you appended it to. That is why merged dialogue files no longer have problem with interjections, but still work properly because they have proper filtering added in states that can be initiated by scripts or by starting dialogue (those states that already had top level conditions).

 

-----

 

but you can use common files for Sandrah's join/post/banter dialogues and dream script if you like instead of relaying on automated merging (just like Keeping Yoshimo mod simply uses SoA dialogues in ToB too, so it doesn't need any changes). This way you have full control over trigger filtering, which means you can for example code a dialogue that can be triggered by script regardless of the portion of the story. It's your decision though.

[Roxanne]

 

(not sure how to handle the issue that you can visit IWD in all parts of the game - so where to put the crossmod??? BG2 or ToB?? or maybe it does not matter at all.)

it doesn't matter at all. When you use CHAIN command than it ends up as a state block without any trigger filtering, which is than called by external dialogue file. That state will be available after merging regardless of the file that you appended it to. That is why merged dialogue files no longer have problem with interjections, but still work properly because they have proper filtering added in states that can be initiated by scripts or by starting dialogue (those states that already had triggers).

 

Thank you for your patience - it took a bit of time but I have finally understood it (I guess).

Also looked at my 25dreamfiles now and there is no problem,. the triggers are so unique that they can only be true in the ToB part.

[K4thos]

No problem. I would appreciate if someone could help with describing it properly, to make the documentation (quoted in this post) less confusing.

btw. Roxanne, not sure if you are aware but it's also possible to start scripted conversation using different dialogue file than the JOIN one, without replacing the dialogue file attached to CRE file:

StartDialogOverride(S:DialogFile*,O:Target*)

[agb1]

K4thos, is EET automatically merging any mod-introduced blocks from the baldur25.bcs script into baldur.bcs during the end install or is it a modder's responsibility to append to baldur.bcs instead if game type is EET?

[K4thos]

K4thos, is EET automatically merging any mod-introduced blocks from the baldur25.bcs script into baldur.bcs during the end install or is it a modder's responsibility to append to baldur.bcs instead if game type is EET?

it doesn't merge them, so it's up to modders. Usually mods adds the same code to both BALDUR.BCS and BALDUR25.BCS, so we would end up with tons of usless junk by doing so. All relevant code from BG1 BALDUR.BCS script (4 blocks) and ToB BALDUR25.BCS (6 blocks) is appended during EET installation (first component). I've updated all patches to append into proper file (or don't append at all if it's not needed) as you can see in this commit.

[agb1]

Makes sense. Does the EET converter tool now find any appends to baldur25.bcs and advise that they need a !GAME_IS ~eet~ condition?

[K4thos]

when the same stuff is added to both BALDUR25.BCS and BALDUR.BCS than it's actually harmless to leave that code in 25 file too, since it's not used at all (I've changed it in exe file to force BALDUR.BCS even if the game is started from ToB menu, now occupied by SoA). !GAME_IS ~eet~ condition in the above mentioned patches is just a cosmetic change to not slow down Near Infinity when doing global BCS search, not print unrelevant matches etc.

If the code is indeed unique than you should always check if the script blocks are filtered enough to only show up in ToB (for example with some unique global set by ToB script or area reference check etc.). If yes than it's a matter of this:

ACTION_IF GAME_IS ~eet~ BEGIN  EXTEND_BOTTOM ~Baldur.bcs~ ~Angelo/Scripts/Baldur25.baf~END ELSE BEGIN  EXTEND_BOTTOM ~Baldur25.bcs~ ~Angelo/Scripts/Baldur25.baf~END

if no than some additional filter is needed (see Xan patch) or unique files depending on platform.

Either way it always requires some time to check the code when BALDUR25.BCS is used, so adding some warning to the converter may be a good idea. On the other hand mod authors knows when they patch global script, so if they are aware that the file is not used in EET than it's pretty obvious what to do, without additional warnings.

[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.

 

I am not sure this is still of interest or already solved by your new approach on the dialogues.

Anyway this is the other cutscene needeing some dialogue setting capcut01.bcs with respect to Imoen and Viconia.

[K4thos]

I am not sure this is still of interest or already solved by your new approach on the dialogues.

Anyway this is the other cutscene needeing some dialogue setting capcut01.bcs with respect to Imoen and Viconia.

all problems like this are completely solved by this new approach. No need to report them (well, until you install new EET beta at least )

[Roxanne]

 

I am not sure this is still of interest or already solved by your new approach on the dialogues.

Anyway this is the other cutscene needeing some dialogue setting capcut01.bcs with respect to Imoen and Viconia.

all problems like this are completely solved by this new approach. No need to report them (well, until you install new EET beta at least )

 

Fine - I will do the new install soon as I am nearing BG1 end. I will do the transition and then do a new install also with the new mods that have become available meanwhile.

[Kulyok]

I was confused about something and just wanted to pop in with a silly question (lack of sleep and such, sorry): I've never been a fan of mod Xan's filenames (for example) changing, because he's a BG2-only character, a mod character, designed specifically for one single purpose. BG1 Xan may have something to do with him storywise, yeah, but in no way should they have same filenames, death variables and such.

 

I.e. I hope and believe that Xan, Branwen, Coran, Tiax (have I forgotten someone?) should remain O#Xan, O#Coran and so on, absolutely - because this way they will remain separate NPCs as they were always meant to be.

(and I'll only be dealing with my own bug reports). Same as any BG2-only character - just treat O#Coran as a BG2-only character, if it makes the job easier.

 

I think I've been asked about this in PM once, and, yeah, I believe this "same dialogue for BG1 and BG2" just doesn't work here, I think.

[K4thos]

I.e. I hope and believe that Xan, Branwen, Coran, Tiax (have I forgotten someone?) should remain O#Xan, O#Coran and so on, absolutely - because this way they will remain separate NPCs as they were always meant to be.

correct, all BG1 NPCs that you've released for BG2 are not continuous like vanilla ones, even after applying those patches (they have different DV, dialogue and script names). Changes that I've listed in Changes.txt file are needed to be compatible with how EET systems works. For example chapters thing is needed by EET continuous chapter system (it will be implemented in version 1.0+ but the code I've posted is compatible with both current beta v0.9 and future versions). A little bit different FATESP.DLG implementation when GAME_IS ~eet~, done by that pre-made function will just adopt your mod to the way ToB summoning works in EET (which basically means no way to summon new creature file, only existing one if it's valid for summoning, also ToB Override script assigning since we no longer depend on PDIALOG.2DA to do it) - implementing it differently would conflict with this function and it's meant to be used by many other mods (it expects 3 responses per NPC coded in a specific way to be able to correctly determinate appending point sorted alphabetically). Same goes for appending ToB dialogue files to SoA ones done after all other mods are installed. After doing so nothing is really changed in a way they work (proper trigger filtering is automatically added to them). The only difference is eliminating a problem when you come back to BG2 areas from ToB - this way SoA interjections called by other dialogue files are still valid instead of breaking the dialogue.

[Roxanne]

A question

What script and dialogue is Imoen supposed to have when you rescue her in Spellhold, area ar1512?

 

I have Imoen.bcs and ImoenP.d prior to letting her join again, is that correct?

[K4thos]

yep, correct. Same files as in vanilla BG2:EE. Even with the implementation that merges all PDIALOG dialogue files you should still modify vanilla files and not merged ones, since the merging takes place at the very end, after your mod is installed. So IMOENJ.dlg and IMOENP.dlg for Irenicus Dungeon Imoen.

 

I've reread your post and noticed that you're talking about Spellhold Imoen. At that point she should use her normal IMOEN2 files. Sounds like the K#IMIMO2.BCS script has not been attached to her override slot during Waukeen Promenade cutscene, if she still have IMOEN.BCS override script. This code from CUT01.BCS is responsible for adding it:

    ActionOverride("Imoen2",MoveGlobal("AR1512",Myself,[1857.1520]))
    ActionOverride("Imoen2",Face(SW))
    ActionOverride("Imoen2",ChangeAIScript("K#IMIMO2",OVERRIDE))

it worked the last time I've tested it. Please check following things:

- did she had K#IMIMO2.BCS attached as Oveeride script in any save before you entered Spellhold?

- does the CUT01.BCS have the above mentioned code?