Jump to content

Baldurdash dialog.tlk and BG1NPC


cmorgan

Recommended Posts

Sorry -- at least it means there is probably nothing wrong with either install. I am assuming the same issue with X#KABAND.CRE is also known, and that any notes I have on similar problems need to be checked against the known issues list.

I searched the bug rerports before starting this, but must not have included all forums (or searched well enough on this one). Could you please post the link here, so that I can follow up without duplicating your efforts? I will keep going with the comparison TOS to Original+TOSC and report next weekend. I am impatient to change party members! Given that a full BG1 story arc may take me over 3 months of dedicated gaming to complete, the BG1NPC project has just booked me for the next several years!

Link to comment

Domi brought my attention to this thread. :D

 

It is an issue because Tutu has dynamic string references. Normally if you copy a creature over (in BG2, say) then his strings for his sounds will be the same on both installs. With Tutu they won't necessarily be since the dialogue is appemded on; the strings are no longer 'fixed'. Which is why on peoples' machines other than mine their zombies may spout odd strings as combat sounds. I forgot to reassign the correct ones.

 

A quick fix would be to do something like this in the zombie creature copying in the .tp2:

 

SAY ATTACK1 -1  
SAY ATTACK2 -1  
SAY ATTACK3 -1  
SAY ATTACK4 -1  
SAY BATTLE_CRY1 -1  
SAY BATTLE_CRY2 -1  
SAY BATTLE_CRY3 -1  
SAY BATTLE_CRY4 -1
SAY BATTLE_CRY5 -1
SAY DAMAGE -1
SAY DYING -1  
SAY HURT -1  

 

That will blank out all their sounds. A better fix would be to work out what strings and sound files should be playing and use them, though I am away from my computer right now so can't find out what they are. :D

Link to comment

OK, I understand... and I understand now why changing the install using or not using Baldurdash (or for that matter anything which changes the dialog.tlk, regardless of order of installation) would create different results/different text; also that having a .CRE yell out odd text is not neccessarily a symptom of a big problem. The first order of business on an old install is to open NearInfinity, and check the .CRE files for sound assignments, and fix if necessary. The new install fix is to add Andyr's lines to the .tp2 before installing BG1NPC.

This also seems to negate the need for a comparison between the different versions of BG1; from a modders perspective, you must have to assume that every person out there may have a slightly different install, and do your best to adjust. Or recreate the whole Tutu package with fixed strrefs, which means actually creating a whole new game. Anyone got a few million $$$ for development/rights acquisition? :D

Then again, life is interesting when there are challenges!

Thank you for the info and tutorial.

Link to comment

Hey there; not to beat a probably-already-fixed horse, but if we can use

SetPlayerSound(Myself,~I should'na got out of bed this morn!~ [_YESLK02],MORALE)

 

in a stringfixer, could the .tp2 changes above look like this:

 

COPY ~BG1NPC/Creatures/X#garz01.CRE~ ~override/X#garz01.CRE~
 SAY NAME1 ~Zombie~
 SAY NAME2 ~Zombie~
 SAY DAMAGE ~ ~ [_ZOMBI08]  
 SAY DYING ~ ~ [_ZOMBI09]

 

(of course, using the other SAY entries edited out here for space)?

 

Would this work even if _ZOMBI09 were in a .bif?

Link to comment

Hello -

 

Yes, X#KABAND.CRE is definitely a problem, as I can attest now that I am a BG1NPC end-user. The DAMAGE strref in the CRE has this bandit talking about Eltan, the Iron Throne, and Candlekeep every time she is hit. Her DYING strref is the Candlekeep guard line "I shoulda joined the army," which is an oddly appropriate misfire. Heh.

 

I'll also add that the resref assigned to this CRE's class script (_SHOUTGT) doesn't exist in my Tutu installation, which causes this bandit to stand dumbly and be slaughtered, since she lacks any AI besides the override script which initiates dialog.

 

As for reasons why the strrefs might be bunged up: a SoA-based Tutu and a ToB-based Tutu will have very, very different DIALOG.TLKs. Could it be this CRE had its soundset assigned on a SoA-only Tutu?

 

I'm enjoying the mod thus far, though. Lots of nice, thoughtful touches (e.g., the whole bit with the "Keeper of the Portal" back at Candlekeep if you head back there to see if they'll readmit you).

Link to comment

Cmorgan is working on fixing the problem with all the CREs we are adding in, and if I am not mistaken he is pretty much done with it, so the next version should have everyone saying the appropriate things. I'll see about assigning a better script to her. In my game she is quite difficult to subdue generally.

Link to comment

I am certainly working on the sound reference fixes, and getting the information set up for Andyr and Domi -- I think we will be in business for the next release, both .cre fixes and correct references for Domi's PID NPC string fixer. Cool to feel useful!

 

[Edited April 3 for content/clarification re: ascii # vs field]

 

I sent a tested snippet of .tp2 fix for both Garrick's and Kagain's quests to MacReady in thanks for his Soundset Utility, which is what I am using to track down and fix errors. While looking at it, MacReady pointed out the problem with the Bandit's script:

WRITE_ASCII 0x280 ~X#KABAND~// death variable
WRITE_ASCII 0x248 ~_initdlg~// override
WRITE_ASCII 0x250 ~_shout~// class
WRITE_ASCII 0x2CC ~X#KABAND~// dialog

WRITE_ASCII 0x250 ~_shout~// class

should have said

WRITE_ASCII 0x250 ~_shout~ #8// class

 

and since it wasn't, it wrote "_shout" over something longer resulting in "_shoutgt".

 

Since everything else in that section was 8 characters in length, no other errors could creep in. I am posting a quick note about this in BG1NPCv11 Public bugfixes and sending a note to Andyr.

 

MacReady's full explanation, edited and summarized for those of us learning on the fly:

[Edited] Whenever you use WRITE_ASCII for a resref, use a #8 at the end to make sure you blank any unused spots. The WRITE_ASCII line for _shout lacking a #8 is probably why [the bandit's] AI was broken...an existing eight-letter resref only got partially overwritten. Anywhere you are writing a resource name (i.e., a sound resource, a script name, etc) it is an eight character field. If you write something shorter than eight characters (e.g., ~_shout~, which is six chars total), and something longer than what you are writing is already there (say, ~_tasight~, which is eight chars total), the "ht" at the end of the existing resref won't get overwritten. Using #8 tells WeiDU to write the string and also blank out any unused spaces, up to eight chars total, if the string you are writing is less than eight chars.  I'd also include the #8 in [already 8 character resource/script names], because it is good practice to do so. However many bytes the field is, that should be your # argument for WRITE_ASCII.

 

FOR EXAMPLE:

According to the IESDP, the field at 0x0280 in a CRE is 32 bytes, so in that case you'd want a #32.  Remember, the # argument should match the size of the field to which you are writing.

step #1 - get a list of fields by hex, match # from IESDP

step #2 - check each WRITE_ASCII against list and

step #3 - match # argument to field length

 

Common WRITE_ASCII argument lengths in BG1NPC from the .cre info at IESDP:

 

0x0248 8 (resref) Creature script - Override

0x0250 8 (resref) Creature script - Class

0x0258 8 (resref) Creature script - Race

0x0260 8 (resref) Creature script - General

0x0268 8 (resref) Creature script - Default

0x0280 32 (char array) Death Variable

0x02cc 8 (resref) Dialog file. Can be overriden by script, or area.

 

0x0094 8 (resref) Area Script reference

0x0034 8 (resref) Small Portrait resource

 

This results in each ASCII string being set to the called value with everything else zeroed out, and thus avoids accidental "hangers-on" causing problems. I am volunteering to add this to my list of .tp2 fixes for BG1NPC; good practice for me to learn. I will send results to Andyr while Domi is vacationing!

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...