47 replies to this topic

[SConrad]

cmorgan: The problem with your approach is that with STATE_WHICH_SAYS, you get a state number. While finding the state number certainly can be useful--for interjections, and so on--it actually doesn't help this issue.

Because you only get the state number, and not the strref, it's still impossible to edit the strref itself. I suppose you can insert a new strref to the state in order to replace the old one this way, but that would add another string to dialog.tlk instead of just changing the old one.

[Taimon]

Why not use the OUTER_SPRINT/STRING_SET combination?
There even is an STRING_SET_EVALUATE that evaluates variables on the index parameter, but it only accepts integers, so you have to use the template/EVALUATE_BUFFER/REINCLUDE workaround.

<<<<<<<< .../template.tpa
STRING_SET ~%my_string%~ %tra_ref%
>>>>>>>>

// for all your strings do (use for loop + array construct or whatever)
OUTER_SPRINT my_string @1	// old string
OUTER_SPRINT tra_ref "@101"  // new string
COPY - ".../template.tpa" ".../string_set.tpa"
	EVALUATE_BUFFER
ACTION_REINCLUDE ".../string_set.tpa"
// end for

Edited by Taimon, 18 May 2009 - 11:06 PM.

[SConrad]

That's an idea, but I honestly think the ACTION_IF construct would be simpler--and quite possibly faster as well.

[Miloch]

Why not use the OUTER_SPRINT/STRING_SET combination?

Why not ADD_TO_WEIDU STRING_SET @1 @2?

[cmorgan]

@Sconrad - yep - that is what I was thinking. And you are right. It adds another strref instead of replacing the old one. Working forward from the state number, etc. I think your A_I set of statements works the best.

@Taimon - cool.

@Miloch - heh. Darned half-orcs, taking all the wind out of the whole discussion by thwacking it repeatedly with the simple solution.
Why not ask the bigg at PPG? He might say no, or point you to the first request you think you might have made, but then again, the worst answer you could get is "no.". OK, well, possibly "#$^%$ *&^*& no, you *&6465%^&^ half-orc )(&$54^". But that will give him some fun swearing on the forums

[Sasha Al'Therin]

With all the ideas being brought forth, I keep going back to the one I posted.

Yeah, I know it deals with actually reading the dialog.tlk file, but it doesn't do any writing and it's got a boiic on there. The initial read inside the "copy" shouldn't cause the dialog.tlk to be written. The string_set that is called later with the string number learned through the read will cause the dialog.tlk to be written, but that's what you want anyway.

Here. Give this a try. It's a modification of the one above. You will need to have one tra file with the OLD/ORIGINAL strings which you want modified and a second tra file with the NEW/MODIFIFIED strings which you want in the game. Corresponding strings between the two MUST be given the same tra number for this to work. For testing, setup a new directory called 'mymod' OR go through and rename all the files and directories to what you want.

BEGIN ~Modify one or more strings by one or more words in one or more languages. Version 1~
<<<<<<<< ...blank.file
>>>>>>>>
COPY ~...blank.file~ ~mymod\string_set.tph~

OUTER_SPRINT string ~~
OUTER_SPRINT number ~~
OUTER_SET read = 0
OUTER_SET num_read = 0
COPY ~mymod\tra\original_strings.tra~ ~mymod\tra\original_strings.tra~
 SPRINT ~tra_file~ ~%SOURCE_FILE%~
 FOR(index=0;index<%SOURCE_SIZE%;index+=1) BEGIN
  READ_ASCII %index% ~char~ (1)
  //original_strings MUST have matching tra numbers for modified_strings
  PATCH_IF (%char% STRING_EQUAL_CASE "@") 
		  AND (%num_read% = 0)
		  AND (%read% = 0) BEGIN
   SET num_read = 1
   SET start_num_at = %index%
  END
  PATCH_IF !(%char% STRING_EQUAL_CASE "@") 
		  AND !(%char% STRING_EQUAL_CASE "=") 
		  AND !(%char% STRING_EQUAL_CASE " ") 
		  AND (%read% = 0)
		  AND (%num_read% = 1) BEGIN
   SPRINT number ~%number%%char%~
  END
  PATCH_IF (%char% STRING_EQUAL_CASE "=") 
			OR (%char% STRING_EQUAL_CASE " ") 
		  AND (%read% = 0)
		  AND (%num_read% = 1) 
		  AND !(%start_num_at% = %index%) BEGIN
   SET num_read = 0
   SPRINT tra_value ~%number%~
  END
  PATCH_IF (%char% STRING_EQUAL_CASE "~") 
		  AND (%num_read% = 0)
		  AND (%read% = 0) BEGIN
   SET read = 1
   SET start_at = %index%
  END
  PATCH_IF !(%char% STRING_EQUAL_CASE "~") 
		  AND (%num_read% = 0)
		  AND (%read% = 1) BEGIN
	SPRINT string ~%string%%char%~
  END
  PATCH_IF (%char% STRING_EQUAL_CASE "~") 
		  AND (%num_read% = 0)
		  AND (%read% = 1) 
		  AND !(%start_at% = %index%) BEGIN
   SET read = 0
   SPRINT old_string ~%string%~
   SET found_string = 0
   PATCH_PRINT ~Looking for the tra text from %tra_value% in %tra_vile%.~
   PATCH_PRINT ~searching dialog.tlk for:   %old_string%~
   INNER_PATCH_FILE~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 ~%old_string%~) BEGIN
	  SET found_string = 1
	  SET strref_num = %x%
	  SET x = %num_strrefs% // get out when you got what you want
	  INNER_ACTION BEGIN
	   APPEND_OUTER ~mymod\string_set.tph~ ~	 STRING_SET %strref_num% @%tra_value%~
	  END
	 END
	END
   END
   PATCH_IF (%found_string% = 0) BEGIN
	PATCH_PRINT ~Looking for the tra text from %tra_value% in %tra_vile%. Not found in DIALOG.TLK~
	PATCH_PRINT ~searching dialogf.tlk for:   %old_string%~
	INNER_PATCH_FILE~dialogf.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 ~%old_string%~) BEGIN
	   SET found_string = 1
	   SET strref_num = %x%
	   SET x = %num_strrefs% // get out when you got what you want
	   INNER_ACTION BEGIN
		APPEND_OUTER ~mymod\string_set.tph~ ~	 STRING_SET %strref_num% @%tra_value%~
	   END
	  END
	 END
	END
   END
  END
 END
BUT_ONLY_IF_IT_CHANGES

APPEND_OUTER ~mymod\string_set.tph~ "	  USING_TRA ~mymod\tra\modified_strings.tra~"

Here is another option which avoids the dialog.tlk altogether, but is based on the above with it's same requirements regarding the tra files...

BEGIN ~Modify one or more strings by one or more words in one or more languages. Version 2~
<<<<<<<< ...blank.file
>>>>>>>>
COPY ~...blank.file~ ~mymod\string_set.tph~

OUTER_SPRINT string ~~
OUTER_SPRINT number ~~
OUTER_SET read = 0
OUTER_SET num_read = 0
COPY ~mymod\tra\original_strings.tra~ ~mymod\tra\original_strings.tra~
 SPRINT ~tra_file~ ~%SOURCE_FILE%~
 FOR(index=0;index<%SOURCE_SIZE%;index+=1) BEGIN
  READ_ASCII %index% ~char~ (1)
  //original_strings MUST have matching tra numbers for modified_strings
  PATCH_IF (%char% STRING_EQUAL_CASE "@") 
		  AND (%num_read% = 0)
		  AND (%read% = 0) BEGIN
   SET num_read = 1
   SET start_num_at = %index%
  END
  PATCH_IF !(%char% STRING_EQUAL_CASE "@") 
		  AND !(%char% STRING_EQUAL_CASE "=") 
		  AND !(%char% STRING_EQUAL_CASE " ") 
		  AND (%read% = 0)
		  AND (%num_read% = 1) BEGIN
   SPRINT number ~%number%%char%~
  END
  PATCH_IF (%char% STRING_EQUAL_CASE "=") 
			OR (%char% STRING_EQUAL_CASE " ") 
		  AND (%read% = 0)
		  AND (%num_read% = 1) 
		  AND !(%start_num_at% = %index%) BEGIN
   SET num_read = 0
   SPRINT tra_value ~%number%~
  END
  PATCH_IF (%char% STRING_EQUAL_CASE "~") 
		  AND (%num_read% = 0)
		  AND (%read% = 0) BEGIN
   SET read = 1
   SET start_at = %index%
  END
  PATCH_IF !(%char% STRING_EQUAL_CASE "~") 
		  AND (%num_read% = 0)
		  AND (%read% = 1) BEGIN
	SPRINT string ~%string%%char%~
  END
  PATCH_IF (%char% STRING_EQUAL_CASE "~") 
		  AND (%num_read% = 0)
		  AND (%read% = 1) 
		  AND !(%start_at% = %index%) BEGIN
   SET read = 0
   SPRINT old_string ~%string%~
   SET found_string = 0
   INNER_ACTION BEGIN
	APPEND_OUTER ~mymod\string_set.tph~ ~	 STRING_SET %old_string% @%tra_value%~
   END
  END
 END
BUT_ONLY_IF_IT_CHANGES

APPEND_OUTER ~mymod\string_set.tph~ "	  USING_TRA ~mymod\tra\modified_strings.tra~"

And if you don't want to have the same tra numbers in both files, modify the INNER_ACTION as below and add as needed till all new tra numbers have been matched to the old strings...

BEGIN ~Modify one or more strings by one or more words in one or more languages. Version 3~
<<<<<<<< ...blank.file
>>>>>>>>
COPY ~...blank.file~ ~mymod\string_set.tph~

OUTER_SPRINT string ~~
OUTER_SPRINT number ~~
OUTER_SET read = 0
OUTER_SET num_read = 0
COPY ~mymod\tra\original_strings.tra~ ~mymod\tra\original_strings.tra~
 SPRINT ~tra_file~ ~%SOURCE_FILE%~
 //reading through the whole tra file one byte at a time
 FOR(index=0;index<%SOURCE_SIZE%;index+=1) BEGIN
  READ_ASCII %index% ~char~ (1)
  //looking for tra number in original strings file
  PATCH_IF (%char% STRING_EQUAL_CASE "@") 
		  AND (%num_read% = 0)
		  AND (%read% = 0) BEGIN
   SET num_read = 1
   SET start_num_at = %index%
  END
  //gathering all bytes that make up the actual number of the tra entry
  PATCH_IF !(%char% STRING_EQUAL_CASE "@") 
		  AND !(%char% STRING_EQUAL_CASE "=") 
		  AND !(%char% STRING_EQUAL_CASE " ") 
		  AND (%read% = 0)
		  AND (%num_read% = 1) BEGIN
   SPRINT number ~%number%%char%~
  END
  //we reached the end of the tra number of the tra entry so we need to stop looking for that
  PATCH_IF (%char% STRING_EQUAL_CASE "=") 
			OR (%char% STRING_EQUAL_CASE " ") 
		  AND (%read% = 0)
		  AND (%num_read% = 1) 
		  AND !(%start_num_at% = %index%) BEGIN
   SET num_read = 0
   SPRINT tra_value ~%number%~
  END
  //we aren't looking for the tra number so lets look for the actual string text
  PATCH_IF (%char% STRING_EQUAL_CASE "~") 
		  AND (%num_read% = 0)
		  AND (%read% = 0) BEGIN
   SET read = 1
   SET start_at = %index%
  END
  //gathering all bytes that make up the string in the tra file
  PATCH_IF !(%char% STRING_EQUAL_CASE "~") 
		  AND (%num_read% = 0)
		  AND (%read% = 1) BEGIN
	SPRINT string ~%string%%char%~
  END
  //we reached the end of the string so let's get out and set up the string_sets
  PATCH_IF (%char% STRING_EQUAL_CASE "~") 
		  AND (%num_read% = 0)
		  AND (%read% = 1) 
		  AND !(%start_at% = %index%) BEGIN
   SET read = 0
   SPRINT old_string ~%string%~
   SET found_string = 0
   INNER_ACTION BEGIN
	//new strings that don't match old strings in tra number value are set here
	ACTION_IF (%tra_value% = 0) THEN BEGIN
	 APPEND_OUTER ~mymod\string_set.tph~ ~	 STRING_SET %old_string% @100~
	END
	ACTION_IF (%tra_value% = 1) THEN BEGIN
	 APPEND_OUTER ~mymod\string_set.tph~ ~	 STRING_SET %old_string% @101~
	END
   END
  END
 END
BUT_ONLY_IF_IT_CHANGES

APPEND_OUTER ~mymod\string_set.tph~ "	  USING_TRA ~mymod\tra\modified_strings.tra~"

And in the midst of all this typing... cmorgan makes his post above

[SConrad]

It might just be me, but that seems like an awful lot of work and code for something that can be accomplished with much less. The issue itself can be solved with the two LOC I posted in post #17, and if you need to use a .tra file, you can use Taimon's example from #22.

[Sasha Al'Therin]

It might just be me, but that seems like an awful lot of work and code for something that can be accomplished with much less. The issue itself can be solved with the two LOC I posted in post #17, and if you need to use a .tra file, you can use Taimon's example from #22.

@SConrad: Did you even read between the code blocks? There were three different suggestions in that one post. Perhaps not as much code as you were thinking... Sure maybe yours is smaller, but small is not always a good thing...

@Miloch: Those are my recent ideas to help you get what you wanted to be able to do. The end result would be the creation of a tph file that could then be called up from the tp2 at whatever point you wanted. It'll work with one tra file just use version 3. Put the strings to be replaced at the beginning and the replacement strings later. You'll know what the tra number after the last string to be replaced is, just put a check in for that number and cancel the whole process. The string sets that are created would look like STRING_SET ~string to be replaced~ @100.
Keep in mind, that if you've only got one or two strings to modify, it would be better to go with one of the other suggestions. If you have a lot of strings to adjust, then you may want to consider my ideas. It's your call...

[GeN1e]

Still I find Taimon's solution to be more compact than long sheets of code.

[SConrad]

It might just be me, but that seems like an awful lot of work and code for something that can be accomplished with much less. The issue itself can be solved with the two LOC I posted in post #17, and if you need to use a .tra file, you can use Taimon's example from #22.

@SConrad: Did you even read between the code blocks? There were three different suggestions in that one post. Perhaps not as much code as you were thinking... Sure maybe yours is smaller, but small is not always a good thing...

I did read the entire post, and I did notice that there were three different code blocks. My comment is applied on all of them, individually and together.

So let me expand on what I said. What you're basically doing is parsing the .tra file(s), looking up @values and their adjoining strings. Then you dynamically create a .tp* with SET_STRING based on the string from the .tra. It's clever, sure, but I think that's very unnecessary as WeiDU already has native .tra parsing support--and better support at that, too. You're doing things WeiDU already does automatically, so what's the point?

If you look carefully, Taimon's code from post #22 does pretty much the exact same thing as what you're trying to do, with the difference that (s)he is using WeiDU's native .tra parsing support and you don't.

To move forward: At a glance, I can break your code in a heartbeat by using tabs or newlines (or other whitespace characters) instead of normal spaces in between the @value, the = and the ~string~. I can break your code even further by using other string delineators, such as %% or "". Both of these things are supported in .tra files. I'm pretty certain that there are other ways I can break your code too if I try a bit harder. Sure, you can fix these issues in your code by adding more code, but why reinvent the wheel? Again, WeiDU already natively parses .tra files for you.

Of course, your entire bulk of the .tra parsing in your code can be done in one line with a regular expression, which would make it less likely to break as well--I imagine this is how WeiDU does it. But you can't really do that with .tp2 code, which is why this kind of parsing is better left to the interpreter itself.

[Taimon]

Why not ADD_TO_WEIDU STRING_SET @1 @2?

I'd rather add another patch expression (i. e. STRREF_WHICH_SAYS). It's more flexibile and should be easy to add.

[Miloch]

Keep in mind, that if you've only got one or two strings to modify, it would be better to go with one of the other suggestions.

Well this is the thing really, I've got only one string I want to change. I can see where your code might be useful for mass-modification of an unknown number of strings, but for the former at least, it's so simple it shouldn't require more than a few lines of code (really only one line IMO).

Why not ask the bigg at PPG?

Because we half-orcs are even lazier than the bigg. I suppose I'll get around to it eventually, once I get around to catching up with G3 and PPG. I just thought I'd rib Taimon a bit, since he's had success implementing things bigg hasn't been bothered with.

I'd rather add another patch expression (i. e. STRREF_WHICH_SAYS). It's more flexibile and should be easy to add.

Hey, I'm all for new commands as long as it doesn't bloat WeiDU.exe overmuch. But what exactly would the issue be with getting STRING_SET to accept a TRA reference for the first parameter?

[Taimon]

I just thought I'd rib Taimon a bit, since he's had success implementing things bigg hasn't been bothered with.

Ha, I won't fall for that.
Seriously, you should check things with the bigg.

I'd rather add another patch expression (i. e. STRREF_WHICH_SAYS). It's more flexibile and should be easy to add.

Hey, I'm all for new commands as long as it doesn't bloat WeiDU.exe overmuch. But what exactly would the issue be with getting STRING_SET to accept a TRA reference for the first parameter?

Because then you have to code it again for STRING_SET_EVALUATE, MY_FUTURE_COMMAND, etc. (DRY => Don't Repeat Yourself)
It also has less chance to inclict backwards incompatibility.

[Icendoan]

Copy/Paste ftw?

Icen

[Sasha Al'Therin]

I was curious what the bigg would suggest in this situation. So I asked. Of course, you may wish to give a better explanation and all that...

You can see my query and his response at this link http://forums.pocket...ic,26567.0.html.

I did do a search before posting and couldn't find anything that looked like Miloch had already asked about it before. Unless you can figure out how ALTER_TLK works, I guess you'll have to use the original string text in the tp2 instead of a tra file...

Hope I didn't step on any toes or anything of that nature by asking. I just thought that since Taimon had said it would be better to ask the bigg and Miloch mentioned being way behind in the forums and not having time, that I'd give it a go and see what the response would be...

Who knows maybe when Miloch gets all caught up on the forums he can ask the bigg again with a more thorough and in depth explanation. Perhaps the bigg might have forgotten and be willing to do something about it...

[Taimon]

Copy/Paste ftw?

This is the cause for many errors and countless hours of debugging.

[Miloch]

Who knows maybe when Miloch gets all caught up on the forums he can ask the bigg again with a more thorough and in depth explanation. Perhaps the bigg might have forgotten and be willing to do something about it...

Rofl. To be honest, I don't care enough about this (at least not right now) to make an issue out of it. I'd be more interested in seeing commands (or at least standard macros) to do stuff like ADD_CONTAINER_TO_AREA or ADD_DOOR_TO_AREA or ADD_INFO_TRIGGER to replace your long sheets of code as in this post .

Also, for what it's worth, I tested both of SConrad's suggestions and Taimon's with a handful of strings and found pretty much zero statistical difference in runtime in multiple installs - all ~1.7 seconds or so. Granted, maybe I'd have to use a larger sample to notice anything but a large sample wasn't really what I was after in the first place. It occurred to me that it actually makes some sense to have the existing strings hardcoded in the tp2 - they're already translated so no need to make folks retranslate them (and indeed that could defeat the purpose). Though the other snippets could come in handy for other things no doubt.

[Sasha Al'Therin]

... or ADD_INFO_TRIGGER to replace your long sheets of code as in this post .

I try, I really do.
If I understood how to make a macro and then get the bigg to incorporate it into weidu, I'd go for it.

Asencion64 did a macro for part of the container addition to FAI, but that I believe was just for the offset update portion...

Do you know a good macro creator that we could beg into creating ADD_INFO_TRIGGER or one of the others?

[Icendoan]

If you read some of the WeiDU SRC (or source, but I think it is called SRC), it has a directory called macros and, iirc, a readme of how to make WeiDU have more default ones.

Wouldn't you throw all that under one DEFINE_*_MACRO (remove the C_E_R for patch, leave it for action), and just make sure you know what variables you need?

Then again, I may be horribly wrong (something that happens disconcertingly often).

Icen

Edited by Icendoan, 23 May 2009 - 01:35 PM.

[Sasha Al'Therin]

If you read some of the WeiDU SRC (or source, but I think it is called SRC), it has a directory called macros and, iirc, a readme of how to make WeiDU have more default ones.

Wouldn't you throw all that under one DEFINE_*_MACRO (remove the C_E_R for patch, leave it for action), and just make sure you know what variables you need?

Then again, I may be horribly wrong (something that happens disconcertingly often).

Icen

I don't dig into the source code of weidu. Other than modding the only programming language that I ever had any kind of training in was basic. I've heard of c++, fortran, c# and such but know nothing about them. Shoot I don't even understand javascript, but I can handle basic html (with a guide/tutorial nearby).

That said, I'm not a good candidate for making a new macro that is built into weidu. Perhaps, maybe, possibly, with an infinite number of monkeys and an infinity number of typewriters I just might get one to make a working in tp2 macro (i.e DEFINE_*_MACRO).

Okay, let's not high-jack this thread anymore...

back to the original topic....

Oh, wait...

Miloch said he decided what he was going to do and left the door open to switch topics...

Okay, maybe we are still on topic...