Jump to content


Photo

BG1 NPC v12 for BGT


  • Please log in to reply
5 replies to this topic

#1 pro5

pro5
  • Modder
  • 722 posts

Posted 19 November 2006 - 09:28 AM

Still many problems with this mod. I'm currently building it into my install, so I'll use this thread to report any serious issues I find (hoping someone from BG1NPC team will wander by here sometime).

BGREPLACE.D file (possibly others too):

For NPCs who can join party in SoA - Imoen, Jaheira, Minsc, Viconia, Edwin - BGT appends new states to already existing dialog files. So, the state in their dialogs which has number X in Tutu and BG1, will have number X + N in BGT, where N is number of states in SoA version of this file.

Example for Minsc case:

BMINSC.DLG in SoA already has 98 dialog states by default; BGT upon installation appends 9 states from BG1. So, the state which is number 0 in Tutu will be number 99 in BGT, and so on. The current BGREPLACE.D file doesn't account for this and uses Tutu state numbers.

Unfortunately, just replacing 0 with 99 in above example won't guarantee that everything will work fine. It will work only if BGT was the first mod installed which appended new states to BMINSC.DLG. If any such mods were installed prior to BGT (for example - TS-BP or NEJ), the BGT state numbers will be different again.

In SCS-BGT, I worked around this problem by appending duplicate outweighted states, this ensures that changes will work as intended in all cases and with any installation order. For more details, take a look at NPCMANAG.D file in SCS-BGT installation.

#2 pro5

pro5
  • Modder
  • 722 posts

Posted 20 November 2006 - 09:42 AM

/* Death variable assignments for Yeslick dialogue */
COPY_EXISTING ~iron11.CRE~ ~override~
  WRITE_ASCII 0x280 ~IRON11~ #32 // death variable
  BUT_ONLY_IF_IT_CHANGES

COPY_EXISTING ~POE.CRE~ ~override~
  WRITE_ASCII 0x280 ~X#POE~ #32 // death variable
  BUT_ONLY_IF_IT_CHANGES

and other blocks changing deathvars: the number of symbols written is a bit too much? BG2 Fixpack writes 18 symbols, random example:

// DV changes
COPY_EXISTING ~brus.cre~  ~override~
			  ~brus2.cre~ ~override~
  WRITE_ASCII 0x280 ~brus~ #18

if you write 32, you're overwriting with 0's:
- known spells offset field
- # of known spells field
- Memorization info offset field
- # of memorization info field
- first 2 bytes of memorized spells offset

Edited by pro5, 20 November 2006 - 02:55 PM.


#3 cmorgan

cmorgan
  • Modder
  • 2301 posts

Posted 20 November 2006 - 02:34 PM

Pro5, are you sure? DVs are listed as 32, so our standard write is WRITE_ASCII #32. We don't appear to have troubles with this code, but I definitely could use an update if this is wrong!!!!


D:\Beta3\BG1NPC\BGT\DLG\X#JFIX.D also needs some serious tweaking; it's primary focus is getting non-conditioned variables to be weighted so that they do not pop up when the PID content is desired (those are the only non-conditional dialogue states so that they fire when no other one is cued up). Perhaps BGT already deals with this in another way, so that the state changes are unnessesary? Currently we even have to false() Kivan's timer block for the Bandits to get things working on a BGT install.

I am downloading the BGT -SCS right now and going to look for the code in NPCMANAG.D.

I appreciate any and all time you can put into this, and can promise you instant updating of the internal and credit for any and all fixes presented. We are short on BGT testers and coders, and I really really want this correctly working cross platform; while the bugs may not be apparent to most users, we want all the content enabled without blasting away other modders work if possible!

EDIT: ummm.. ok, this is a beast. If I understand you correctly, for the materials to work correctly, we need to rebuild each one of the entries with a Weight -10 so they have new versions that are higher up in the order. For each of the lines where we

REPLACE_STATE_TRIGGER _BXZAR 0 ~InteractingWith("montaron")
RandomNum(3,1) Global("X#BIOXZ1","LOCALS",0)~

or

ADD_TRANS_ACTION _BSKIE BEGIN 10 END BEGIN
END
~SetGlobal("X#BIOSK4","LOCALS",1)~

we need to create a new IF WEIGHT #-10 version. How do we false out the old, though, so we don't have multiple versions become available?

Edited by cmorgan, 20 November 2006 - 02:50 PM.


#4 pro5

pro5
  • Modder
  • 722 posts

Posted 20 November 2006 - 02:54 PM

Pro5, are you sure? DVs are listed as 32, so our standard write is WRITE_ASCII #32. We don't appear to have troubles with this code, but I definitely could use an update if this is wrong!!!!

Well, I've just looked in IESDP to be sure - you're right it lists DV field as 32-byte array. But in that case I'm curious why all mods I've seen so far write #18... :blink: Sorry for my mistake.

As for the dialog changes - BGT indeed doesn't need many of those fixes. I'll probably PM you a full list of dialog corrections when I'm done looking through the code.

One other thing - Imoen's override script in BGT is BGIMOEN.BCS, not BGIMOEN2. Also all NPCs already have their override scripts assigned, so all you have to do is EXTEND_BOTTOM them.

we need to create a new IF WEIGHT #-10 version. How do we false out the old, though, so we don't have multiple versions become available?


Actually, any less-than-zero WEIGHT will do the trick. You don't need to false out anything, because the negative WEIGHT ensures the state you're appending will always override any previous states with same trigger conditions.

Edited by pro5, 20 November 2006 - 03:00 PM.


#5 cmorgan

cmorgan
  • Modder
  • 2301 posts

Posted 20 November 2006 - 04:11 PM

Well, I've just looked in IESDP to be sure - you're right it lists DV field as 32-byte array. But in that case I'm curious why all mods I've seen so far write #18... :blink: Sorry for my mistake.

I'd be happy to know, too... if it is standard procedure to use #18, then that might be there for a reason we don't know about. I will get researching :) .

As for the dialog changes - BGT indeed doesn't need many of those fixes. I'll probably PM you a full list of dialog corrections when I'm done looking through the code.

awesome -- Thank you! Any oddities or tweaks you see that can improve things, just let me know soIi can repair them for everybody. I may have attempted to unify the project, but that was a huge number of cooks over a very long period - I am open to suggestions.

One other thing - Imoen's override script in BGT is BGIMOEN.BCS, not BGIMOEN2. Also all NPCs already have their override scripts assigned, so all you have to do is EXTEND_BOTTOM them.

cool - so the addition of the DVs and reassignment can be scrapped, and all references to extending imoen go from BGIMOEN2.BCS to BGIMOEN.BCS

Actually, any less-than-zero WEIGHT will do the trick. You don't need to false out anything, because the negative WEIGHT ensures the state you're appending will always override any previous states with same trigger conditions.

What about the no-condition ones or the ones where we are adding a trigger? For example,

original state = X + added trigger Y so even if X+Y comes higher in the order, won't X fire before X+Y becmes available?

Edited by cmorgan, 20 November 2006 - 04:13 PM.


#6 pro5

pro5
  • Modder
  • 722 posts

Posted 20 November 2006 - 06:42 PM

What about the no-condition ones or the ones where we are adding a trigger? For example,

original state = X + added trigger Y so even if X+Y comes higher in the order, won't X fire before X+Y becmes available?


If two or more different conditions evaluate to true, the dialog state with lower weight always wins. So, if in resulting DLG we have:

IF WEIGHT #3 ~Race(Player1,ELF)~ THEN BEGIN StateOne
  SAY ~something1~
  IF ~~ THEN EXIT
END

IF WEIGHT #1 ~Class(Player1,RANGER)~ THEN BEGIN StateTwo
  SAY ~something2~
  IF ~~ THEN EXIT
END

and Player1 is both ELF and RANGER, StateTwo will always fire, and StateOne will never fire, unless Player1's class changes from RANGER to something else.

But, on second thought - this won't work in the case of ADD_TRANS_TRIGGER part of the BGREPLACE.D file; because what we're doing is adding trigger and action to ensure that dialog state fires only once. Our appended state will fire once and correctly disable itself immediately; but the original state will still fire afterwards and this makes the whole change pointless. :doh:

Incidentally, what we might want to try here is something like this (in TP2 file):

// define "~" symbol to correctly use R_T in D files
OUTER_INNER_PATCH ~13~ BEGIN
  WRITE_ASCII 1 "~"
  READ_ASCII 1 tild (1)
END

COPY_EXISTING ~BMINSC.DLG~ ~override~
	DECOMPILE_DLG_TO_D
		REPLACE_TEXTUALLY CASE_INSENSITIVE
~%tild%InteractingWith("Dynaheir")[%tab%%lnl%%mnl%%wnl% ]*GlobalLT("ENDOFBG1","GLOBAL",2)[%tab%%lnl%%mnl%%wnl% ]*RandomNum(2,1)[%tab%%lnl%%mnl%%wnl% ]*%tild%[%tab%%lnl%%mnl%%wnl% ]*THEN[%tab%%lnl%%mnl%%wnl% ]*BEGIN[%tab%%lnl%%mnl%%wnl% ]*\([0-9]+\)[%tab%%lnl%%mnl%%wnl% ]*SAY[%tab%%lnl%%mnl%%wnl% ]*#\([0-9]+\)[%tab%%lnl%%mnl%%wnl% ]*IF[%tab%%lnl%%mnl%%wnl% ]*%tild%%tild%[%tab%%lnl%%mnl%%wnl% ]*THEN[%tab%%lnl%%mnl%%wnl% ]*EXTERN~~%tild%InteractingWith("Dynaheir")GlobalLT("ENDOFBG1","GLOBAL",2)RandomNum(2,1) Global("X#BIOMI1","LOCALS",0)%tild% THEN BEGIN \1  SAY #\2  IF %tild%%tild% THEN DO %tild%SetGlobal("X#BIOMI1","LOCALS",1)%tild% EXTERN~  		REPLACE_TEXTUALLY CASE_INSENSITIVE~%tild%InteractingWith("Dynaheir")[%tab%%lnl%%mnl%%wnl% ]*GlobalLT("ENDOFBG1","GLOBAL",2)[%tab%%lnl%%mnl%%wnl% ]*%tild%[%tab%%lnl%%mnl%%wnl% ]*THEN[%tab%%lnl%%mnl%%wnl% ]*BEGIN[%tab%%lnl%%mnl%%wnl% ]*\([0-9]+\)[%tab%%lnl%%mnl%%wnl% ]*SAY[%tab%%lnl%%mnl%%wnl% ]*#\([0-9]+\)[%tab%%lnl%%mnl%%wnl% ]*IF[%tab%%lnl%%mnl%%wnl% ]*%tild%%tild%[%tab%%lnl%%mnl%%wnl% ]*THEN[%tab%%lnl%%mnl%%wnl% ]*EXTERN~~%tild%InteractingWith("Dynaheir")GlobalLT("ENDOFBG1","GLOBAL",2)RandomNum(2,2) Global("X#BIOMI2","LOCALS",0)%tild% THEN BEGIN \1  SAY #\2  IF %tild%%tild% THEN DO %tild%SetGlobal("X#BIOMI2","LOCALS",1)%tild% EXTERN~  	COMPILE_D_TO_DLG

Looks terrible, I know. :whistling:
But it works - at least testing suggests so.

Edited by pro5, 20 November 2006 - 07:28 PM.