Patching SNDSLOT.IDS

[cmorgan]

Carrying on a conversation from the Soundset Utilites thread, since I am moving considerably off-topic there...

 

In order to make sure that a Tutu stringfixer doesn't have difficulties installing, I need to have every user have a SNDSLOT.IDS that matches (in this case) Smoketest's entries. Using the default IDS crops up some difficulties in WeiDU -- which are ameliorated when the IDS entries are defined. This should not require any dramatic changes -- merely clarifications of existing IDS numbers. BUT, judging from the cool IDS entry work in the BG2 realm, just plain replacing the SNDSLOT.IDS is definitely not a great idea --

 

If I use

// Patching SNDSLOT.IDS for PIDstringfixer, entries 44 45 and 46 are not listed in BG2
APPEND ~sndslot.ids~ ~44 INSULT1~ UNLESS ~44 INSULT1~
APPEND ~sndslot.ids~ ~45 INSULT2~ UNLESS ~45 INSULT2~
APPEND ~sndslot.ids~ ~46 INSULT3~ UNLESS ~46 INSULT3~

 

I add new entries (double up) and I believe cause problems.

 

From reading the AI script work and cirrerick's materials, it looks like :

 

// Patching SNDSLOT.IDS for PIDstringfixer, entries 44 45 and 46 are not listed in BG2
COPY_EXISTING ~sndslot.ids~ ~override~
REPLACE_TEXTUALLY ~44~ ~44 INSULT1~
REPLACE_TEXTUALLY ~45~ ~44 INSULT2~
REPLACE_TEXTUALLY ~46~ ~44 INSULT3~

 

should work the way I want... or (probably) do I need to change the ~44~ to an actual offset # -and if so, how do I figure out those offsets, please?

[CamDawg]

You can multiple entries for the same numeric value, i.e.

1 FOO
1 BAR
1 FOO_BAR

is just dandy. This is what might get you into trouble:

 

1 FOO
2 FOO
3 FOO

 

In other words, your first method (appending) should be fine.

[CamDawg]

Of course I forgot the simplest alternative of them all: use the direct numeric values in your scripts or dialogues, and screw the IDS symbols.

[the bigg]

1 FOO
1 BAR
1 FOO_BAR

<{POST_SNAPBACK}>

Go Near Infinity / WeiDU fuck-up!

(explaination: NI will pick FOO when decompiling, WeiDU FOO_BAR).

[CamDawg]

Yes, and both will work on compiling.

[cmorgan]

Y'know, now I owe devSin a case of the beverage of his choice. Cam, you mentioned skipping back to the numbers. devSin was trying to explain this, and I STILL missed the point - the names in the Tutu install are there for the humans, not the computer.

 

pulling

 

SetPlayerSound(Myself,%[VICONIA 03] Lil alurl! For Shar!% [_VICON03],BATTLE_CRY1)

 

out of Tutu, I can convert it to

 

SetPlayerSound(Myself,%[VICONIA 03] Lil alurl! For Shar!% [_VICON03],#)

 

where # = the soundslot ID (e.g. "73" for BG1 Biography) and both WeiDU and the in-game PID dialog-run script to reset will work fine. Only NI will have difficulties, which I can leave to the tender mercies of the individual; they can forum search and follow the leader!

 

To expand and make sure I understand; I think Bioware scripts must use direct #s, because the Soundset Utility pulls "INSULT" as a BG1 call, but Tutu doesn't use "INSULT" -- more directly, if I use the sndslot.ids #, I can be assured that if someone HAS created a script using the IDS long name, I am not messing up their stuff.

[Smoketest]

Only dialog scripts can be messed up by changes to soundset IDS files because they aren't compiled to code that uses numeric values instead of labels.

 

I forgot to mention that you might want to keep certain names like EXISTANCE5 in SNDSLOT.IDS for mods that use that old label (like Saerileth).

[cmorgan]

Understood - that was why I was so happy to finally understand number usage meant the same thing as label usage . I don't want to mess with the "default" SNDSLOT.IDS if I can avoid it. Even though there are not many Tutu mods, I don't want to run the risk of messing up installing another mod. For my own usage, i will use your (Smoketest's) versions, so that I can learn and understand usage and have clarity in NI. For anything that needs to be included in a distributed mod, I use the numbers and sidestep parse warnings/errors.

 

The answer here must to remap the stringfixer (for the 6th time - thank goodness for Macready's Soundset Utility) to the number labels rather than the word labels and leave the IDS alone. If you folks can confirm my understanding:

 

For in-game script run from within player-initiated dialog,

 

IF ~~ ViconiaVoice

SAY ~*coughs*~

IF ~~ THEN DO ~SetName(%Viconia%)

SetPlayerSound(Myself,%[VICONIA 03] Lil alurl! For Shar!% [_VICON03],9) etc.

 

 

for sound repairs through COPY in the Tp2,

 

SAY INITIAL_MEETING ~[MALE GREETING 1] Yes?~ [_GENMG01]

 

becomes

 

SAY 0 ~[MALE GREETING 1] Yes?~ [_GENMG01]

[CamDawg]

for sound repairs through COPY in the Tp2,

 

SAY INITIAL_MEETING ~[MALE GREETING 1] Yes?~ [_GENMG01]

 

becomes

 

SAY 0  ~[MALE GREETING 1] Yes?~ [_GENMG01]

For the script yes, for the tp2, no. In the tp2 these are actually fixed WeiDU constants and not IDS lookups, so there's no need to change them. You would actually break a great deal with this change--rather than adding the string to the inital meeting area of a creature soundset (at offset 164) you would be overwriting the creature file header at offset 0.

[cmorgan]

Almost had it -- is it >> IDS and WeiDU constants are two independent, unrelated "windows" into the same offset?

 

IDS uses labels "0" and "INITIAL_MEETING" to identify offsets in a .cre file. These can be relabelled, at the risk of disabling other people's in-game scripts, but as long as the number is there the IDS entry acts as a link to the relationship of string reference and associated sound resource (if any) to .cre. Therefore, the above PID syntax works.

 

BUT for tp2, a parrallel but unrelated relationship occurs;

 

WeiDU uses a set of fixed, defined constants (that have no direct relationship to the IDS entries) to identify the offsets in a .cre; INITIAL_MEETING is WeiDU-speak for "offset 0164" in myCre.cre.

 

This means for sound repairs through COPY in the Tp2,

 

SAY INITIAL_MEETING ~[MALE GREETING 1] Yes?~ [_GENMG01]

 

works, and could be restated as

 

SAY 0164 ~[MALE GREETING 1] Yes?~ [_GENMG01]

 

but since these WeiDU constants are, well, "constant", it is unnecessary to reidentify them the way IDS may need to be in order to work on different installs. We still use SAY instead of WRITE_ASCII because SAY will match existing strings, and Write won't?)

 

IF I finally have this right, then my whole problem is that I have been using the IDS identifier as if it were the WeiDU constant, which usually (but not always) matches (thus BIO vs BIOGRAPHY, INSULT vs INSULT1).

[CamDawg]

Almost had it -- is it >> IDS and WeiDU constants are two independent, unrelated "windows" into the same offset?

 

IDS uses labels "0" and "INITIAL_MEETING" to identify offsets in a .cre file. These can be relabelled, at the risk of disabling other people's in-game scripts, but as long as the number is there the IDS entry acts as a link to the relationship of string reference and associated sound resource (if any) to .cre. Therefore, the above PID syntax works.

 

Yes. When a script is compiled (or a dialogue evaluated in real-time), INITIAL_MEETING is replaced by its numeric value from the ids file. If you use the numeric value directly, you can bypass these lookups.

 

BUT for tp2, a parrallel but unrelated relationship occurs;

 

WeiDU uses a set of fixed, defined constants (that have no direct relationship to the IDS entries) to identify the offsets in a .cre; INITIAL_MEETING is WeiDU-speak for "offset 0164" in myCre.cre.

 

This means for sound repairs through COPY in the Tp2,

 

SAY INITIAL_MEETING ~[MALE GREETING 1] Yes?~ [_GENMG01]

 

works, and could be restated as 

 

SAY 0164 ~[MALE GREETING 1] Yes?~ [_GENMG01]

 

Yep.

 

but since these WeiDU constants are, well, "constant", it is unnecessary to reidentify them the way IDS may need to be in order to work on different installs. We still use SAY instead of WRITE_ASCII because SAY will match existing strings, and Write won't?)

 

Almost. Strings are not actually stored in any files other than dialog.tlk. Whenever you see a string in creature file, or dialogue, or whatever, it's a string reference (strref). So, WRITE_ASCII would not work, as the string doesn't actually exist in the file itself. Using SAY in a patch does two things--adds a string to dialog.tlk if it's not already there, and adds the reference to the string in the file you're patching. In the case of an existing string, SAY can indeed be used interchangeably with WRITE_LONG as the end result is the same: a four-byte number. I.e. these two are equivalent:

 

COPY_EXISTING ~imoen.cre~ ~override~
 SAY 0x08 #16453 // Imoen
 WRITE_LONG 0x08 16453 // Imoen

 

 

IF I finally have this right, then my whole problem is that I have been using the  IDS identifier as if it were the WeiDU constant, which usually (but not always) matches (thus BIO vs BIOGRAPHY, INSULT vs INSULT1).

The WeiDU constants were named after the ones in the ids files, which is why they're so similar. But yes, they're looked up on different tables (ids for scripts/dialogues, WeiDU constants for tp2s). You can bypass either lookup with numeric values.

[cmorgan]

Thank you! I appreciate the clarifications. I think I have got it now... off to test, proofread, compile, and playtest!