54 replies to this topic

[Kulyok]

The discussion started in this topic. It is about interjections into BG1 dialogue states for BGT, namely, for BG1 NPC Project.

It comes to this: BGT adds BG1 dialogues at the end of BG2 dialogue files. Would it be possible to create new files for BG1 dialogues instead, naturally, prefixed with BGT prefix?

[the bigg]

This is one of those cases where I'll pull a terkiS out of my ass and hint that the time taken to rewrite and retest all of those dialogues (in BGT and in all mods that are modded taking that standard in consideration) would likely be better spent making a BGT stack decently bug-less.

[cmorgan]

The vast majority of BGT creates independent files based on the BG1 standard. The exceptions to this (as far as I can tell) are restricted to party-joinable NPCs that exist both in BG and BG2.

I believe the answer, instead of creating a set of dialogue files that are changed via script, or worse a completely new DV/Pdialog.2da, is related to detecting and patching the correct state rather than changing BGT behavior.

As a side note, both Tutu and BGT can have changes applied before they operate; the only current platform where dialogue files can be considered completely static is EasyTutu, because it drops a consistent override into place.

[Ascension64]

The only 'BG1' dialogues with fluid states, the reason being its the only way that it will work:

BG1 -> file appending
BJAHEI -> aBJAHEIR
BVICON -> aBVICONI
None -> aIMOEN2J
IMOENP -> aIMOEN2P
JAHEIJ -> aJAHEIRAJ
JAHEIP -> aJAHEIRAP
VICONJ -> aVICONIJ
VICONP -> aVICONIP
BEDWIN -> aBEDWIN
BMINSC -> aBMINSC
BVICONI -> aBVICONI
EDWIN -> aEDWIN
EDWINJ -> aEDWINJ
EDWINP -> aEDWINP
IMOEN2 -> aIMOEN2
MINSCJ -> aMINSCJ
MINSCP -> aMINSCP

Note that these are all J or P or banter files. Obviously, if these could have been renamed but preserve all BG1 and BG2 states so that correct dialogues trigger, I would have done it ages ago, but is isn't like I can RewritePDialog() and RewriteInterDia() in-game.

Oh, did I mention that these are all in the Developer's Documentation?

Edited by Ascension64, 11 January 2008 - 05:04 PM.

[Kulyok]

Note that these are all J or P or banter files. Obviously, if these could have been renamed but preserve all BG1 and BG2 states so that correct dialogues trigger, I would have done it ages ago, but is isn't like I can RewritePDialog() and RewriteInterDia() in-game.

Using different creatures for Jaheira(Imoen, etc) in BG1 and BG2 would be the answer, then, perhaps?

[Ascension64]

Using different creatures for Jaheira(Imoen, etc) in BG1 and BG2 would be the answer, then, perhaps?

Well, that is already done for the most part, since BG1 and BG2 versions of joinable NPCs have different CRE files. Unless you are suggesting having two different DVs -- cmorgan will get lynched...and almost every mod that BGT is currently compatible with will become incompatible.

Edited by Ascension64, 12 January 2008 - 02:24 AM.

[Kulyok]

Well, that is already done for the most part, since BG1 and BG2 versions of joinable NPCs have different CRE files. Unless you are suggesting having two different DVs -- cmorgan will get lynched...

I believe that this is the best technical solution, since in BG1 NPC Project platform-related variables are used for dialogue files and death variables, so it will be relatively(or, I'd rather say, very) simple.

I know it means more work for rebuilding other mods which may and do use these death variables for BGT version, but I believe it is the best solution and the best architecture in the long run.

Edited by Kulyok, 12 January 2008 - 02:29 AM.

[Ascension64]

I was writing a PM to cmorgan, and I came up with the idea that to patch any mod added fluid state, you can simply determine the starting state number by querying the backed up DLG in the backup directory of said mod for #states and calculating yourStateNumber from that. Pretty simple workaround, as easy as DVs.

This doesn't just go for BGT, provided that state order isn't changed within the mod itself (such as adding new dialogue in new versions of the mod), and the dialogue is backed up (let's say this one is given) it would work for any fluid state.

Edited by Ascension64, 12 January 2008 - 09:10 PM.

[Kulyok]

That would work, I think, if we were not talking about original game dialogue. There, fluid states are never a good thing in the first place.

I was writing a PM to cmorgan, and I came up with the idea that to patch any mod added fluid state, you can simply determine the starting state number by querying the backed up DLG in the backup directory of said mod for #states and calculating yourStateNumber from that. Pretty simple workaround, as easy as DVs.

Fluid states are shuffled around too much - I do it, on purpose and not, in my mods all the time, and it's done in other mods, too, BG1 NPC is a prime example.

Which is one of the reasons why I believe all original BG1 dialogue, whether in the original game, Tutu and BGT, firmly belongs to the "fixed states" position, because it preserves original structure, provides safety and security(not changed on a whim, state numbers don't go hayfire if the dialoguefiles you're appending to have already been changed), and because of that, seems the best solution in the long term.

I'm comfortable either way - since I'm not a part of BG1 NPC, uh, management or moderating team or whatever, as you posted earlier, all I can do is post a suggestion. I do think it will work.

[Ascension64]

I'm comfortable either way - since I'm not a part of BG1 NPC, uh, management or moderating team or whatever, as you posted earlier, all I can do is post a suggestion. I do think it will work.

Well, I was just reading the list out from the G3 forums.

Anyway, while it may be my prerogative to make an executive decision on this, I would risk a transition period of great frustration as other modders try to adapt their code to such changes, and players wondering why things aren't working any more. So, I'm going to put this up to the mod authors who use the death variables of Jaheira, Viconia, Imoen, Edwin, and Minsc. Are you willing to adapt to a change of death variable for these characters during the BG1 portion of the game? You don't have to do it on your own. (apart from BG1NPC, I don't exactly know what these other mods are, so speak up if this will affect you).

Edited by Ascension64, 13 January 2008 - 02:41 AM.

[CamDawg]

I was writing a PM to cmorgan, and I came up with the idea that to patch any mod added fluid state, you can simply determine the starting state number by querying the backed up DLG in the backup directory of said mod for #states and calculating yourStateNumber from that. Pretty simple workaround, as easy as DVs.

...or you could use STATE_WHICH_SAYS, which is designed explicitly for this task.

[cmorgan]

I read and slept (and dreamed of a world where every player's whim could be accomodated to customize their game as a hand fits in a deerskin glove... and woke crying on the morn to find that I am but mortal... and a lousy understander of i.e. structures and relevant manipulations to boot.)

I think that the option of reading the dialogue file from backup and then adding on the BG number difference would work simply and beautifully for the problem faced by BG1NPC. It avoids most Mega install problems, too, because BGT will add the original states onto NeJ/Fixpack/whatever, as they come pre-BGT. It avoids all of the different languages problems (for example, if I use S_W_S and soemeone customizes the string, I am in trouble - and I just killed the folks that use a German Mega-Install with English-Only BG1 NPC, or an intervening mod which modifies that sttref.

I don't know how to code this, but can give it a try if someone can teach me how.

I think the most elegant solution is to use STATE_WHICH_SAYS (since the bigg put in the sweat to create it, it seems appropriate to use it; it just means I need to learn how things work) and load from BGT .tra files, and simply expect that for the Tutu side EasyTutu will be the platform of choice, and not support Tutu v4 installations which use pre-Tutuification mods. (That means not supporting the BG Fixpack if they alter states to the extent that the original state numbers are changed/reordered).

I am having a helluvu time still figuring out how to do that with the BGT extensive (and extremely well implemented) multi-language support, but with careful quiet headbashing from Ascension64, CamDawg, Kulyok, and the bigg, I can try.

So now I have two approaches to try and test out. I am calling in sick to work tomorrow, and am going to try to get a workable solution in place and sent to CamDawg for release by the end of Monday, so any coding teaching/help would be appreciated. I have a triple BGT/FixpackBGT/EasyTutu_ToB setup ready for test installing/troubleshooting/cross comparison.

The Tutu side I can leave as fixed if we are willing to abandon support for pre-tutuification mods. Most folks these days skip the only ones available (I think the only one I know of is The Vault, and erebusant, et al have been pokinhg at it to eventually make it post-Tutu). The BGT side, we make the changes for Fixpack compatibility, and we also solve some troubles for the Mega-Mod folks.

(Side note - so that we can all be sure we are on the same page, Kulyok is part of the development team - she does not speak for the Project, I get to summarize and poll the other folks, but is an author, tester, bughunter, and project member).


As for changing the BGT BG>BG2 party Joinables, for fixed-state-number compatibility, isn't this really just a BG1 NPC problem? I mean, the boyz with the pre-BGT mods are not going to play ball no matter what, from a philosophical perspactive (and I really can't blame them - it is alot of time to put in for something you don't agree with in the first place. Only idiots like me do that.) The Fixpack is playing by the rules, and not destroying or altering states for other modders; this is a stacking problem that doesbn't effect anyone else I know of. I don't think Sirines Call, or any of the other BGT-ized mods Ascension64 has worked with have messed with this, or he would have solved it already

Edited by cmorgan, 13 January 2008 - 09:32 AM.

[cmorgan]

http://forums.gibber...s...st&p=110242

97 states to fix/reference correctly. I could do a temporary "hardcoded" one for v15, checking for the Fixpack and reminding folks that BG1 NPC *MUST* be installed *directly* after BGT to avoid unintended changes... but if I could get assistance on the "how to" of coding, I could probably get all 97 worked out ok by tomorrow night. Especially as I could set it up with the declared variables section with

Tutu:

OUTER_SPRINT "BGTEdwinJState0" "0"

and

bgt

OUTER_SPRINT "BGTEdwinJState0" = STATE_WHICH_SAYS # IN ~bgt/bg1.tra~ FROM edwinJ

and continue with the

COMPILE ~mymod\myfile.d~ EVALUATE_BUFFER


except that for some languages it would have some trubles - and would need to be put on an english language only install, I think.

For English and Russian, is it ~bgt/tra/%s/bg1.tra~ or ~bgt/bg1.tra~ ?

[Ascension64]

Sorry, I'm a bit rushed, might come back and refine later, but here is a really quick example:

COPY - ~BGT/backup/0/EDWINJ.DLG~ ~BGT/backup/0/EDWINJ.DLG~
  READ_LONG 0x8 EDWINJ_num_states
  SET BGTEdwinJState0 = EDWINJ_num_states
  SET BGTEdwinJState1 = EDWINJ_num_states + 1
  SET BGTEdwinJState2 = EDWINJ_num_states + 2
  SET BGTEdwinJState3 = EDWINJ_num_states + 3
  SET BGTEdwinJState4 = EDWINJ_num_states + 4

<<<<<<<< abc/makeEDWINJ3true.d
ADD_STATE_TRIGGER EDWINJ %BGTEdwinJState3% ~True()~
>>>>>>>>

COMPILE EVALUATE_BUFFER ~abc/makeEDWINJ3true.d~

Edited by Ascension64, 13 January 2008 - 11:43 PM.

[cmorgan]

OK, I think I understand - I will play with this for a bit while still working out how to try out STATE_WHICH_SAYS - back with soem results later...

[the bigg]

[quote name='Ascension64' post='371099' date='Jan 14 2008, 08:39 AM'][code=auto:0]COPY - ~BGT/backup/0/EDWINJ.DLG~ ~.../inlined/BGT/backup/0/EDWINJ.DLG~
BLAH[/quote]
Revise as here. Otherwise, chain-uninstalls might fail under strange circumstances.

[cmorgan]

http://forums.pocket....html#msg307521

short form = no backup of the changed file exists in a clean install of BGT:

// Log of Currently Installed WeiDU Mods
// The top of the file is the 'oldest' mod
// ~TP2_File~ #language_number #component_number // [Subcomponent Name -> ] Component Name
~SETUP-BGT.TP2~ #0 #0 // Baldur's Gate Trilogy - Core 1.05b

On the good side, I can patch simply for the current Fixpack install, I think - just by looking up additions to BG2 files:

VICONIP no state changes, end state 13

VICONIJ end state 188 instead of 183

VICONI no state changes, end state 27

BVICONI no state changes, ends at 547

MINSCP no state changes, last state 9

MINSCJ no state changes, has 243 as last state instead of 240

MINSCA no state changes, last state 43

JAHEIRAP no state changes, end state 73

JAHEIRAJ no state changes, end state 536 instead of 530

JAHEIRA no changes, end state 74//My bad - Jaheira and Minsc have different materials for their joining dialogues, so no problems here

EDWINP no changes, state 8

EDWINJ no changes but ends at 190 instead of 187

EDWIN no changes ends at 73

Edited by cmorgan, 14 January 2008 - 01:38 PM.

[Ascension64]

[quote name='the bigg' post='371145' date='Jan 15 2008, 03:01 AM'][quote name='Ascension64' post='371099' date='Jan 14 2008, 08:39 AM'][code=auto:0]COPY - ~BGT/backup/0/EDWINJ.DLG~ ~.../inlined/BGT/backup/0/EDWINJ.DLG~
BLAH[/quote]
Revise as here. Otherwise, chain-uninstalls might fail under strange circumstances.
[/quote]
I'm more of a fan of COPY ~blah~ ~blah~ {...} BUT_ONLY_IF_IT_CHANGES myself.

[cmorgan]

Folks, any leads here? Nythrun sent me some wicked cool ideas, but it will take me several weeks of study and questions to be able to apply them; I have confirmed on a complete (45 minute uninstall/reinstall) install of the latest BGT that the files may exist for Megas and Fixpack installs but the BGT vanilla side is very clean and lacks these files to read.

My options appear to be

• begin gathering .tra references from all possible distributions and GTU fiexs/STRING changes in preparation for a full implementation of STATE_WHICH_SAYS on several files,
  
• create a platform-based hardcoded set of changes for those state numbers, imitating Ascension64's accounting for NeJ, etc., etc., to be OUTER_SET based on what components are already installed,
  
• Put off this decision until I can really understand and implement Nythrun's code (which still means looking up all the various .tra references and putting them in an inlined file, and seems destined to fail for the Mega folks, as the mods they put on pre-BGT may (or may not) change the floating states depending on combinations of mods.)
  
• Go play Morrowind and pray that a much better modder than me takes pity on me and shows me the way to accomplish the impossible, complete with ice sculptures.

Is there any way I can put Ascension64's simple and comfortable idea into play? Is it really true that appending a file avoids creation of a backup file?

I know I am pushing the boundaries by wanting maximum compatibility, and I will leave the creation of a Mega-Install friendly set of fixes that change BG1NPC states to reference the correct ones to the Mega folks to create (as it will be different for many, many of them, and as well over 98% of our stuff will play just fine on everything). But I would like to at least try to get us as universally compatible as is humanly possible.

[Salk]

The effort and generosity you always put in your endeavors are admirable, cmorgan.

I, as ignorant player, just want to ask: what is all this about?

In short, are you guys speaking of possible compatibility problem between BG1 NPC and BGT? Or rather between BG1 NPC and all the Mega Mods?

I am asking because it does make a difference for people like me.

Thanks!