20 replies to this topic

[Miloch]

I want to read a strref for some items, replace something simple like the damage amount, then STRING_SET the new string back so as not to increase dialog.tlk. Simple, eh? No matter what I do though, I can't get WeiDU to evaluate the second argument of STRING_SET. I've tried STRING_SET_EVALUATE old_strref ~%new_string%~, STRING_SET old_strref EVALUATE_BUFFER ~%new_string%~ and a bunch of variations of that, and even more obscure stuff using fake files, etc. Every time I just get the variable name for the description at best. I must be missing something simple though...

Edit: Eh... well, xtreme hackery got it working. I'm almost ashamed to post the code, but it was a combination of stuff like INNER_ACTION, an inlined file, COPY to temp.tra, EVALUATE_BUFFER, REPLACE_TEXTUALLY and STRING_SET_EVALUATE USING ~mymod/temp.tra~. There's gotta be something easier, but, well... it works at least.

Edited by Miloch, 21 June 2008 - 01:38 PM.

[Taimon]

Variables aren't evaluated in the string argument. Either bug the bigg (it's only a minor change) or use some nifty workaround with defining a tra file on-the-fly (e.g. with <<<<<<<<, which evaluates variables) and then use STRING_SET ref @traref USING inline-tra-file.

[Miloch]

use some nifty workaround with defining a tra file on-the-fly (e.g. with <<<<<<<<, which evaluates variables) and then use STRING_SET ref @traref USING inline-tra-file.

Well yes, that's exactly what I did, as I mentioned in my edit...

But yeah, if it's only a minor change... Pretty sure I've requested it before, maybe a few other folks too.

Edit: Actually, that's not exactly what I did. <<<<<<<< was not evaluating the variable in the body - I think maybe it only evaluates them in the filename? However, when I copied it to a real file and EVALUATE_BUFFERed it, it worked, then I used that file to set the tra reference. It wouldn't take the EVALUATE_BUFFER when I copied the inlined file to itself either.

Edited by Miloch, 21 June 2008 - 02:04 PM.

[Taimon]

Edit: Actually, that's not exactly what I did. <<<<<<<< was not evaluating the variable in the body - I think maybe it only evaluates them in the filename? However, when I copied it to a real file and EVALUATE_BUFFERed it, it worked, then I used that file to set the tra reference. It wouldn't take the EVALUATE_BUFFER when I copied the inlined file to itself either.

You are right, it's only evaluated in the filename, my bad. However, EVALUATE_BUFFER should also work on the inlined file. Will check.

/Edit: Works for me.

BACKUP here
AUTHOR me
BEGIN ~inline file test~
INSTALL_BY_DEFAULT
NO_LOG_RECORD

OUTER_SPRINT test ~hello world~
<<<<<<<< .../inlined-file
%test%
>>>>>>>>

COPY - ~.../inlined-file~ ~.../inlined-file~
	EVALUATE_BUFFER

COPY - ~.../inlined-file~ ~.../inlined-file~
	READ_ASCII 0x0 contents (BUFFER_LENGTH)

PRINT ~%contents%~

/Edit2: Wait for v208, for variable evaluation on the tlk string.

Edited by Taimon, 22 June 2008 - 12:50 AM.

[Miloch]

Works for me.

Well I did basically the same thing, but it wasn't liking it in an INNER_ACTION within a patch. You can have the whole miserable code if you want to look at it. It all works now, so all you have to change is the external to inlined to get it to bomb, with a 'FAILED: cannot open target' message. Maybe it's the combination with REPLACE_TEXTUALLY, I dunno.

Wait for v208, for variable evaluation on the tlk string.

When?

[Taimon]

You can have the whole miserable code if you want to look at it.

Yep. Post it here or PM it to me, whatever you want.

/Edit: Are you sure you did not miss that minus sign after the COPY? (Because it is an illegal filename otherwise, and the filesystem will probably fail to create the file.)

Wait for v208, for variable evaluation on the tlk string.

When?

Sorry, no idea. Current beta version is 20715, though.

Edited by Taimon, 22 June 2008 - 07:08 AM.

[the bigg]

Wait for v208, for variable evaluation on the tlk string.

When?

Sorry, no idea. Current beta version is 20715, though.

I have to wait on some checks by CMorgan, and next week I'll be at the seaside so no upload - you can expect it Monday or Tuesday if no problems arise (30th June, not tomorrow).

[Miloch]

Are you sure you did not miss that minus sign after the COPY?

Yeah I guess that was it. Details... I decided that copying to the physical file works out better anyway, because it keeps a record of the last string I changed. Actually I could probably generate a whole dynamic .tra file if STRING_SET_EVALUATE var1 @var2 USING temp.tra worked (maybe it does, but I don't think so). Not that I really need to do that right now, but it could be handy at some point.

I noticed a couple other oddities though. The ~~~~~string ~blah~ here~~~~~ thing doesn't seem to parse for me. I got around it by using "string ~blah~ here" instead, since I didn't need any other special characters.

Also, can someone tell me the difference between these expressions:
PATCH_IF (~%SOURCE_RES%~ STRING_COMPARE_CASE ~charbase~ = 1) BEGIN
PATCH_IF NOT(~%SOURCE_RES%~ STRING_COMPARE_CASE ~charbase~ = 0) BEGIN
PATCH_IF NOT(~%SOURCE_RES%~ STRING_EQUAL_CASE ~charbase~ = 1) BEGIN
PATCH_IF (~%SOURCE_RES%~ STRING_EQUAL_CASE ~charbase~ = 0) BEGIN

I would think they'd be the same, but the first one didn't start patching until after it hit charbase. The second one worked as I'd expect from the documentation (patched everything not matching charbase).

[Taimon]

Cannot replicate your new issues.
Try to give complete code snippets where you confirmed the problem.
What WeiDU Version are you using, btw?

I noticed a couple other oddities though. The ~~~~~string ~blah~ here~~~~~ thing doesn't seem to parse for me. I got around it by using "string ~blah~ here" instead, since I didn't need any other special characters.

What was the parse error you got?

Also, can someone tell me the difference between these expressions:
PATCH_IF (~%SOURCE_RES%~ STRING_COMPARE_CASE ~charbase~ = 1) BEGIN
PATCH_IF NOT(~%SOURCE_RES%~ STRING_COMPARE_CASE ~charbase~ = 0) BEGIN
PATCH_IF NOT(~%SOURCE_RES%~ STRING_EQUAL_CASE ~charbase~ = 1) BEGIN
PATCH_IF (~%SOURCE_RES%~ STRING_EQUAL_CASE ~charbase~ = 0) BEGIN

No difference at all. Behave the same for me.

[Miloch]

What WeiDU Version are you using, btw?

207. I'm not at the Windows machine right now, but I'll see if I can reproduce or dig up the debugs when I get back there.

[Miloch]

I noticed a couple other oddities though. The ~~~~~string ~blah~ here~~~~~ thing doesn't seem to parse for me. I got around it by using "string ~blah~ here" instead, since I didn't need any other special characters.

What was the parse error you got?

Here is the working code:

BACKUP ~1itemchk/backup~
AUTHOR ~null~

BEGIN ~Item Type Check~
INSTALL_BY_DEFAULT
NO_LOG_RECORD

<<<<<<<< .../1itemchk-inlined/t-item_list.txt
Item name	Item file	BAM	Attack type
===================================================
>>>>>>>>

<<<<<<<< .../1itemchk-inlined/t-item_desc.txt
>>>>>>>>

COPY + ~.../1itemchk-inlined/t-item_list.txt~ ~1itemchk~
	   ~.../1itemchk-inlined/t-item_desc.txt~ ~1itemchk~

OUTER_SET hn = 0
OUTER_SET hd = 0
COPY_EXISTING_REGEXP GLOB ~^.+\.itm$~ ~override~
  PATCH_IF SOURCE_SIZE > 0x71 BEGIN
	READ_STRREF 0xc n1 //Name
	READ_SHORT 0x1c tp //Item type
	READ_ASCII 0x3a bm //BAM
	READ_STRREF 0x54 d1 //Description
	READ_LONG 0x64 hf //Extended header offset
	READ_SHORT 0x68 hc //Extended header count
	FOR (i = 0; i < hc; i += 1) BEGIN //Cycle through headers
	  READ_BYTE (0x38 * i + hf) pt //Attack type
	  PATCH_IF tp = 0x15 BEGIN //Hammer
		hn = hd + 1
		hd = hn + 1
		INNER_ACTION BEGIN
		  APPEND_OUTER ~1itemchk/t-item_list.txt~ ~%n1%	%SOURCE_FILE%	%bm%	%pt%~
		  APPEND_OUTER ~1itemchk/t-item_desc.txt~ "@%hn% = ~%n1%~
@%hd% = ~%d1%~"
		END
	  END
	END
  END
BUT_ONLY_IF_IT_CHANGES

Change the "s to ~~~~~s instead, and you get:

[SETUP-1ITEMCHK.TP2] LEXER ERROR at line 39 column 1-18
Near Text: ~
	invalid character [~]
 HINT: Don't use MS Word to edit your .tp2 files - use ConTEXT (http://www.context.cx instead).

[SETUP-1ITEMCHK.TP2]  ERROR at line 39 column 1-18
Near Text: ~
	Parsing.Parse_error
ERROR: parsing [SETUP-1ITEMCHK.TP2]: Parsing.Parse_error
ERROR: problem parsing TP file [SETUP-1ITEMCHK.TP2]: Parsing.Parse_error

FATAL ERROR: Parsing.Parse_error

(That HINT is obnoxious btw. As if I use Word, or even ConText to edit tp2s .)

Also, can someone tell me the difference between these expressions:
PATCH_IF (~%SOURCE_RES%~ STRING_COMPARE_CASE ~charbase~ = 1) BEGIN
PATCH_IF NOT(~%SOURCE_RES%~ STRING_COMPARE_CASE ~charbase~ = 0) BEGIN
PATCH_IF NOT(~%SOURCE_RES%~ STRING_EQUAL_CASE ~charbase~ = 1) BEGIN
PATCH_IF (~%SOURCE_RES%~ STRING_EQUAL_CASE ~charbase~ = 0) BEGIN

No difference at all. Behave the same for me.

Run this (code stolen from Nythrun and the bigg):

BACKUP ~1script/backup~
AUTHOR ~null~

BEGIN ~Script Patching Test~
INSTALL_BY_DEFAULT

OUTER_SPRINT sn ~ ghoulsu.cre gibbersu.cre gnollsu.cre hobgobsu.cre koboldsu.cre nymphsu.cre ogregrsu.cre tasloisu.cre xvartsu.cre~ //Non-animal summonees

<<<<<<<< .../1script-inlined/t-testsc.baf
IF
  Die()
  Global("T-Drop","LOCALS",0)
  OR(2)
	StateCheck(Myself,STATE_FROZEN_DEATH)
	HitBy([ANYONE],2)
THEN
  RESPONSE #100
	SetGlobal("T-Drop","LOCALS",1)
	DropInventory()
END
>>>>>>>>

COMPILE ~.../1script-inlined/t-testsc.baf~

COPY_EXISTING_REGEXP GLOB ~^.*\.cre$~ ~override~
  PATCH_IF SOURCE_SIZE > 0x2d3 BEGIN
	READ_BYTE 0x271 g2 //General
	READ_BYTE 0x275 r2 //Gender
	PATCH_IF (g2 != 0) AND (g2 != 2) AND (r2 != 6) AND (r2 != 7) AND (r2 != 9) AND (r2 != 0xc) BEGIN
	  PATCH_IF (~%sn%~ STRING_CONTAINS_REGEXP ~ %SOURCE_FILE%~ = 1) BEGIN
		PATCH_IF NOT(~%SOURCE_RES%~ STRING_COMPARE_CASE ~charbase~ = 0) BEGIN
		  READ_ASCII 0x248 ~vs~ //Override script
		  PATCH_IF FILE_EXISTS_IN_GAME ~%vs%.bcs~ BEGIN
			PATCH_IF NOT VARIABLE_IS_SET $df(EVALUATE_BUFFER ~%vs%~) BEGIN
			  READ_STRREF 0x8 n1 //Name
			  PATCH_PRINT ~Marking script %vs% of %SOURCE_FILE% (%n1%) for extension.~
			  SPRINT $df(EVALUATE_BUFFER ~%vs%~) ~%vs%~
			END
		  END ELSE BEGIN
			READ_STRREF 0x8 n1 //Name
			PATCH_PRINT ~Assigning new override script to %SOURCE_FILE% (%n1%).~
			WRITE_EVALUATED_ASCII 0x248 ~t-testsc~ #8
		  END
		END
	  END
	END
  END
BUT_ONLY_IF_IT_CHANGES

ACTION_PHP_EACH df AS i => xs BEGIN
  EXTEND_TOP ~%xs%.bcs~ ~override/t-testsc.bcs~
END

And it doesn't start patching until chore.cre:

[C:\Archive\BG2\/DATA/SCRIPTS.BIF] 6510702 bytes, 2826 files, 0 tilesets

Marking script SHOUT of CHORE.CRE (Chore) for extension.

Marking script SPSEQ16A of CHSAM01.CRE (Semaj) for extension.

Marking script GRPSHT01 of CHTAZ01.CRE (Tazok) for extension.

Assigning new override script to CHTAZ02.CRE (Tamoko).
Copied [CHTAZ02.CRE] to [override/CHTAZ02.CRE]
...

Change the PATCH_IF NOT(~%SOURCE_RES%~ STRING_COMPARE_CASE ~charbase~ = 0) to any of the 3 other equivalents above, and it works correctly:

[C:\Archive\BG2\/DATA/SCRIPTS.BIF] 6510702 bytes, 2826 files, 0 tilesets

Marking script SHOUTDL2 of AATAQAH.CRE (Aataqah) for extension.

Assigning new override script to ABAZIGAL.CRE (Abazigal).
Copied [ABAZIGAL.CRE] to [override/ABAZIGAL.CRE]

Assigning new override script to ABISRED1.CRE (Abishai).
Copied [ABISRED1.CRE] to [override/ABISRED1.CRE]

Marking script shoutdlg of ABYDEM01.CRE (Tanar'ri) for extension.
...

[Taimon]

APPEND_OUTER ~1itemchk/t-item_desc.txt~ "@%hn% = ~%n1%~
@%hd% = ~%d1%~"

Replacing the double quotes here will lead to 6 tildes at the end of the string, and the lexer ends the widestring on the first 5 tildes, so you will have an erroneous tilde at the end. Try putting a space between the ~%d1%~ and the 5 tildes.

Change the PATCH_IF NOT(~%SOURCE_RES%~ STRING_COMPARE_CASE ~charbase~ = 0) to any of the 3 other equivalents above, and it works correctly:

Well, PATCH_IF NOT(~%SOURCE_RES%~ STRING_COMPARE_CASE ~charbase~ = 0) works correctly, but removing the NOT and testing for 1 will yield the desired (incorrect) result.
Looks like I was wrong, because STRING_COMPARE actually really does a compare, i. e. it returns -1 if s1 < s2, 0 if s1 ==s2 and 1 if s1 > s2. STRING_EQUAL only returns a boolean value.

[Miloch]

Well, PATCH_IF NOT(~%SOURCE_RES%~ STRING_COMPARE_CASE ~charbase~ = 0) works correctly, but removing the NOT and testing for 1 will yield the desired (incorrect) result.

Ah, right - I guess I had corrected that code already too.

Looks like I was wrong, because STRING_COMPARE actually really does a compare, i. e. it returns -1 if s1 < s2, 0 if s1 ==s2 and 1 if s1 > s2. STRING_EQUAL only returns a boolean value.

Hmm, well maybe it's the documentation that needs to be updated in both cases, then. It says nothing about needing a space between the five tildes and a consecutive tilde either (in fact the example shows the opposite). [Edit: but the example has them at the beginning, so yeah, I see what you're saying. Still could be clarified a bit in the doc though.]

Edited by Miloch, 25 June 2008 - 06:02 AM.

[Taimon]

Feel free to download the WeiDU source, edit doc/base.tex and send the diff to the bigg.

[Qwinn]

Looks like I was wrong, because STRING_COMPARE actually really does a compare, i. e. it returns -1 if s1 < s2, 0 if s1 ==s2 and 1 if s1 > s2.

SERIOUSLY? Damnit! Lol. That means I went through a -ton- of gyrations I didn't have to in order to update the PS:T VAR.VAR file in alphabetical order.

*mumble* *bitch* *moan*

Eh, not really. It was kinda fun coding it, actually, and I was actually pretty proud of how it turned out. God I'm such a geek, heh.

Qwinn

[Miloch]

Feel free to download the WeiDU source, edit doc/base.tex and send the diff to the bigg.

Heh. No, I don't think I'll be doing that anytime soon. Maybe if it was just a quick HTML change (which it should be) but I have enough of my own docs and code to update...

Given that no one seems to know about it though, it really should be documented...

[Miloch]

use some nifty workaround with defining a tra file on-the-fly (e.g. with <<<<<<<<, which evaluates variables) and then use STRING_SET ref @traref USING inline-tra-file.

Did something major change with STRING_SET_EVALUATE between v207 and v211? The below code used to work as-is:

READ_STRREF 0x50 ~dc~ //Unidentified description
READ_SLONG 0x50 d1 //String ref of description
INNER_ACTION BEGIN
<<<<<<<< p5test.txt
@500 = ~%dc%~
>>>>>>>>
  COPY ~p5test.txt~ ~p5tweaks/backup/p5temp.tra~
	EVALUATE_BUFFER
	REPLACE_TEXTUALLY EXACT_MATCH ~this~ ~that~
  STRING_SET_EVALUATE d1 @500 USING ~p5tweaks/backup/p5temp.tra~
END

Now I need to do a STRING_SET_EVALUATE ~%d1%~ @500... Rather minor in appearance, but a released mod that was working with a previous WeiDU no longer works with the latest one. Unless it never worked like that, but I'm pretty damn sure I tested it and verified it worked.

I've noticed other quirky behaviour but can't pin down exactly what else is malfunctioning quite yet.

[the bigg]

Fixed (in git).

[Taimon]

Looks like I screwed up.
How about adding wrapper function for that PE_String -> try int else string?

[the bigg]

Looks like I screwed up.
How about adding wrapper function for that PE_String -> try int else string?

It's always handled at the caller level; I can add that %% handling in Var.get_int32, but then I'd have to remove it everywhere Var.get_int32 is called (and WeiDU is riddled with lovely towers of "try X with _ -> try Y with _ -> ...").