Swapping out dialogue files between BG1 and BG2

[berelinde]

BGT can be a pain. Gavin's got a set of scripts and a set of dialogue files for BG1, but the scripts are rather large. Too large to continue using for BG2. And then there's the whole matter of PID for BG1, and how BG2 PID might be tricky to work in around it.

 

I already know it's possible to change out override scripts, and I can live with a shared dream script between BG1 and BG2, but I was wondering if it was possible to swap out files that are contained in pdialog.2da.

 

In other words, I want to keep the CRE and the DV the same, but switch the following:

 

Override script: B!Gavin.bcs => B!GavS.bcs (know I can do this)

Join dialogue: B!Gavin.dlg => B!Gav.dlg

Joined dialogue: B!GavinJ.dlg => B!GavJ.dlg

Post dialogue: B!GavinP.dlg => B!GavP.dlg

Banter files: BB!Gavin.dlg => BB!Gav.dlg

 

I'm thinking that the answer might be no, that I'm going to have to create a second CRE with a second DV to be able to switch files like that, but I figured it was worth asking.

[cmorgan]

Well, I bet there is a way around it.

 

The script is easy, as you can set that via in-dialogue or .bcs scripting; you could probably use the same trick for lots of stuff.

 

For example, Aerie's pdialog entries:

 

AERIE AERIEP AERIEJ AERIED AERIE25P AERIE25J AERIE25D aeri25

 

means that all those columns can be used for Gavin, too; the tricky stuff would be the pre-joining and post files.

 

Scripts and dialogue files can be reassigned in BCS calls:

 

60 ChangeAIScript(S:ScriptFile*,I:Level*Scrlev)

Is used to change to the script specified. (from SCRLEV.ids: 0 OVERRIDE, 1 AREA, 2 SPECIFICS, 4 CLASS, 5 RACE, 6 GENERAL, 7 DEFAULT) on the object running the script. Script priority is defined in the same order as listed above, where OVERRIDE is the highest priority on a creature and DEFAULT is the lowest priority. ScriptFile is set to the name of the script and can be any script up to 8 characters in length and having the .bcs extension.(example USEITEM.bcs), you can use custom scripts with this but they must be in the override directory and .bcs format. You can rename .bs format to .bcs, or compile from .baf to .bcs or .bs.

 

138 SetDialogue(S:DialogFile*)

Sets the dialog file associated with the object running the script to the dialog file (********.DLG) specified. SetDialogue("") will set the dialog file to none.

 

 

IF

AttackedBy([GOODCUTOFF],DEFAULT)

Global("KR_CHANGE_DIALOG","LOCALS",0)

THEN

RESPONSE #100

SetDialogue("")

SetGlobal("KR_CHANGE_DIALOG","LOCALS",1)

END

 

 

But I am not sure you really want to do that with everything. First of all the BG1 and BG2 PID thing is taken care of by having two PIDs - one that fires if %BGT_VAR% is false, the other if it is true (just take the BG1NPC stuff, do the same IsGabber check, and instead of saying !Global("endofbg","GLOBALS",2), say GlobalGT("endofbg","GLOBALS",1), and voila - a new PID that only applies to BG2 content in BGT. Worst comes to worst, set the global in a vanilla BG2 game via BCS, so it is enabled, or simply use the %BGT_VAR% as blank if BG2, filled in if BGT, etc.

 

It might be simpler to leave everything like that alone, and only swap out hs AI script/standard BCS using B!GBG1.bcs and B!GBG2.bcs

 

Or you can script a cutscene a-la Imoen, and presto chango have a whole new cre. I don't think you will be able to cpature the .cre data and rebuild him on the fly, though -

[jastey]

What I see used in game is "SetLeavePartyDialogueFile()" to prevent leaving NPCs to approach the PC for their kick-out dialogues. Maybe this can be used to set another P-dialogue, too. I have never worked with this, though.

 

I would be very much interested in the solution, though.

[berelinde]

All things considered, it might just be easier to use a different CRE after all. He's a cleric, so it isn't as if the PC will have had him memorize a bunch of mage spells that would be different in a new CRE, and I prefer the "choose your own proficiencies" method, anyway, so that won't be an issue. In BG1, I base his XP on PC XP, so doing the same in BG2 wouldn't be too much of a stretch. I didn't think it was fair for him to start with all the equipment he had in BG1 when the PC gets stripped, so I was planning to strip him down and adding a smaller selection of equipment anyway. And I'm not going to be relying on BG1 variables anyway, since I've no guarantees the player will be using BGT.

 

I already use ChangeAIScript() in BG1 Gavin, so I know how that works. The problem with SetDialogueFile() is which would it set? The joined dialogue file if he'd ever been recruited in BG1, but the pre-join if he hadn't, unless I ran the script only after he joined the party. His dilaogue files are really, really big. I don't know if there's a limit to how big dialogue files can be before the player sees a lag in NPC response while the correct scripted dialogue file is run, but I don't know if I want to risk it.

[cmorgan]

I think the lag is the number of triggers that must be parsed, judging by the PID slowdowns, rather than the size, but I don't know why I am typing that as the large dialogue file is because you are serious about tailoring the dialogue to the action, thus lots of triggers to parse - but I know what you mean.

 

If you are going to 0-level him anyways, I think a new .cre means less work making it into a combined Tutu/BGT/SoA/ToB installer. Three chapters, three .cres, set the baseline stuff, and pull him away from the party in BGT via a cutscene before the transition. Have him join in Amn (prefereably *not* in the same marketplace - preferably either in a good logical place like the Temple District or on a timer spawning, or else it becomes "Yo! We are starting a new game! Quick, Mob the PC!!!").

 

It would have to be a devSin et al. question on the SetLeavePartyDialogue (JoinParty() does it automaticlly, too) as to what is chosen when in what game. I assume it just looks at pdialog.2da, and chooses based on what stage (25's for ToB, non-25's for SoA), but that is a random guess. I can try this afternoon to see if it will accept parameters, but I think that would have been listed in the IESDP if it were true.

[berelinde]

Yeah, I'm pretty sure the IESDP would have said if JoinParty() and SetLeavePartyDialogue() accepted parameters, so don't waste precious playing time checking.

 

Yeah, I think it's going to be a different CRE. He'll be summonable by the fate spirit too, I think, but only if he was in the party at some point in SoA.

 

Anyway, if I did use the same dialogue files, I don't know if I really want to wade through a decompiled BGT J file to find potential bugs.