47 replies to this topic

[Miloch]

I want to replace a string that a mod added to an NPC's dialogue with another string. Actually, I just want to replace a single word. I have no way, therefore, of knowing the absolute string reference, so STRING_SET won't work conventionally. Is there some other way of doing this?

[Icendoan]

REPLACE_TEXTUALLY?

Icen

[Miloch]

I don't think that works for string references in dialogue. You may get a comment as to what the text is, but the reference is an @n where n is an unknown number.

[Icendoan]

I was thinking COPY_EXISTING ~dialog.dlg~ ~override~ DECOMPILE_DLG_TO_D REPLACE_TEXTUALLY ~string~ ~string~ COMPILE_DLG_TO_D BUT_ONLY, or something to that effect.

Sorry if I wasn't clear enough.

Icen

[Sasha Al'Therin]

Newer editions of weidu allow for dialog.tlk editing you could try something like this...

COPY_EXISTING ~dialog.tlk~ ~dialog.tlk~
READ_LONG 0xa num_strrefs //hardcoded to start at byte number 18
READ_LONG 0xe string_data_offset //where strings are stored
FOR (x=0;x<%num_strrefs%;x+=1) BEGIN
 READ_LONG (18 + (%x% * 26) + 0x12) this_string_offset
 READ_LONG (18 + (%x% * 26) + 0x16) length_of_string
 READ_ASCII %this_string_offset% string_data (%length_of_string%)
 PATCH_IF (%string_data% STRING_EQUAL_CASE ~The oringal NPC string here~) BEGIN
  SET strref_num = %x%
  SET x = %num_strrefs% // get out when you got what you want
 END
END
BUT_ONLY_IF_IT_CHANGES

STRING_SET_EVALUATE %strref_num% @your_tra_number

You'll have to replace the whole string with this method. I also don't know if it will actually work, but you could give it a try.

Icen's method might work too, so I'd try that first as it's less likely to cause any major dialog issues...

[SConrad]

I was thinking COPY_EXISTING ~dialog.dlg~ ~override~ DECOMPILE_DLG_TO_D REPLACE_TEXTUALLY ~string~ ~string~ COMPILE_DLG_TO_D BUT_ONLY, or something to that effect.

Sorry if I wasn't clear enough.

Uh, no. This won't work, because of the exact same reason Miloch already provided. A strref is not textually represented in the .dlg file, only a reference to dialog.tlk. R_T won't do diddly.

Miloch, if you know the string you want the word replaced in, why not simply use STRING_SET? It takes both full strings and indexes as the first parameter.

Regardless of whether this works or not, I would not recommend you use Sasha's idea--directly patching the .tlk would not be wise. If what I said above won't work for whatever reason, I have an alternative method you can try.

[Isaya]

In Tutufix, the component that adds the BG2 style title to journal entries is coded like that :

STRING_SET ~Ragefast thinks that Ramazith has evil plans in store for the nymph named Abela.~ ~The plight of Abela the nymph

Ragefast thinks that Ramazith has evil plans in store for the nymph named Abela.~

So I guess this capability has been in WeiDU for quite a while. The exe in Tutufix v15 where I found that is from 2005. Since I don't have an English game, I can't confirm whether this actually works though.

[Miloch]

So I guess this capability has been in WeiDU for quite a while.

Aye, it has. The problem seems to be with this sort of syntax, which generates a parsing error:

STRING_SET @2 @1

I need this since both the original and new strings are language-dependent and need to be translated. The closest I can get is "STRING_SET ~Blah blah~ @1" which will do for the new translation but not the old one.

I vaguely recall mentioning this to the bigg at some point and either it was too complicated to change or he couldn't be bothered with it. But my memory is kind of patchy these days.

[SConrad]

You should be able to get around that with some kind of construct like this:

ACTION_IF ( ~%LANGUAGE%~ STRING_COMPARE_CASE ~swahili~ = 0 ) BEGIN
  STRING_SET ~String in Swahili.~ @1
END ELSE BEGIN 
  STRING_SET ~String in English.~ @1  
END

If you have several languages, you can just expand by adding more ACTION_IFs.

I haven't tested the above code so the syntax may be wrong here or there.

[Jarno Mikkola]

You should be able to get around that with some kind of construct like this:

Well, can't we just auto tra-ffy the original mod with WeiDU.exe and then use the tra files to do all that...

[Miloch]

Well, can't we just auto tra-ffy the original mod with WeiDU.exe and then use the tra files to do all that...

Huh? The original mod is already translated into several languages, which is part of the issue. I guess SConrad's solution would work in theory for that though.

[SConrad]

You should be able to get around that with some kind of construct like this:

Well, can't we just auto tra-ffy the original mod with WeiDU.exe and then use the tra files to do all that...

Wow, people seem to have something against reading Miloch's posts. First, Icendoan didn't, and now you--because if you had, you would realize that he's already indicated that it won't work and why.

[GeN1e]

I need this since both the original and new strings are language-dependent and need to be translated. The closest I can get is "STRING_SET ~Blah blah~ @1" which will do for the new translation but not the old one.

Can't a user be just prompted with a LANGUAGE when installing this? Saving the trouble with ACTION_IFs and such. If they're dumb enough to forget what language they've been playing/installing just before then that's their own problems.

Edited by GeN1e, 18 May 2009 - 05:32 AM.

[Miloch]

Can't a user be just prompted with a LANGUAGE when installing this? Saving the trouble with ACTION_IFs and such. If they're dumb enough to forget what language they've been playing/installing just before then that's their own problems.

Eh, I think you're missing the point too. The user is prompted for a language (or it defaults to English if there are no others). Otherwise the %LANGUAGE% variable wouldn't get set. However, we have to resort to ACTION_IF-type hackery since the usual TRAed behaviour doesn't work (i.e., STRING_SET @2 @1).

[GeN1e]

Ah, the point is that STRING_SET can't use @xxx as an index, correct? Got it now.

I guess one can disassemble the dlg with a bunch of READs (using actions and triggers to orientate) and find the needed string manually. But SConrad's way is sure simplier.

[SConrad]

An alternative I was thinking about would be to just have a series of STRING_SETs:

STRING_SET ~English line.~ ~New English line.~
STRING_SET ~Swahili line.~ ~New Swahili line.~

This would (probably) cause WeiDU to look for both lines in the .tlk, and changing the string(s) it can find (which presumably would be either or). This would essentially be the same functionality as with the ACTION_IF statement I described earlier, as it would patch the appropriate line(s) and ignore the ones it can't find. The only issue with this approach is that I don't know how STRING_SET behaves if it can't find the specific string--if it throws errors or warnings at you, it might be safer to go with the ACTION_IF method so that you don't get bug reports for the errors.

You can try fooling around with ALTER_TLK* as well, but I think SET_STRING is better in this case.

[Miloch]

The only issue with this approach is that I don't know how STRING_SET behaves if it can't find the specific string

In my testing, it does nothing. So this would work too, but I think your first method is marginally preferable runtime-wise (in theory anyway) since it only has to look through dialog.tlk once for each language. Takes a few more lines of code maybe, but not a whole lot more.

Of course, ideally, someone should update WeiDU so it takes the @x @y syntax...

[SConrad]

I would hope that WeiDU reads the entire .tlk into memory while running, so the number of STRING_SETs shouldn't affect execution time too much. I guess you could benchmark it to find out, though.

But this is pure speculation, naturally. If there's a solution that works for your problem, go for that.

[cmorgan]

Warning: irrelevant thought follow, for my own clarification of the difference between what you are seeing if can be done and what already exists - to clarify my own thinking...


hmmm.
Cool idea - a good way of creating a patch for mod-added dialog. STATE_WHICH_SAYS didn't help? I have not tested - doesn't it take .tra references?

You might be able to look for the mod, and use the .tra files already in the mod to compare and thus not have to deal with an internal set of .tras.

STATE_WHICH_SAYS value IN String1 FROM String2 As above, except that @x references are taken from the String1 tra file. In particular, one %s in String1 is expanded to the list of directories; for example (as of Sola v102), solarom/%s/epilogue.tra would match

solarom/american/epilogue.tra
solarom/french/epilogue.tra
solarom/german/epilogue.tra
solarom/italian/epilogue.tra
solarom/polski/epilogue.tra
solarom/portuguese/epilogue.tra
solarom/russian/epilogue.tra

The only sample of usage I have is

E:\ie_modding\BG2_NPC\CrossmodBG2-v8\CrossmodBG2\Setup-CrossmodBG2.tp2 (2 hits)
	Line 408:   OUTER_SET actual_joining_state = (STATE_WHICH_SAYS 5023 IN ~amber/tra/%s/dialogs.tra~ FROM ~m#amber~)
	Line 410:   OUTER_SET actual_kidnapping_state = (STATE_WHICH_SAYS 5207 IN ~amber/tra/%s/dialogs.tra~ FROM ~m#ambern~)

which looks backwards from what you want. Though I am not sure - it looks like that value is a pre-existing string, and I thought S_W_S was designed to find mod-added strings. Now i need to go look at S_W_S again.

I was thinking as I typed and copied, though - I think this still involves more work than SConrad's posted A_I sequence. I just realized that the only reason you might want to do this is if someone was actively updating that mod, and changing spelling/punctuation etc. in the mod .tra, and that isn't a good idea anyways. I really can't think of a more elegant way around the problem. Kudos.