@DavidW: Request for help

[pro5]

I give up, I don't know how the following code works:

 

COPY_EXISTING 
~_doppgr.cre~ ~override~
	REPLACE_TEXTUALLY ~_S1-12

COPY_EXISTING
~_gdopp7.cre~ ~override~
~_gdopp71.cre~ ~override~
~_gdopp72.cre~ ~override~
~_gdopp73.cre~ ~override~
~_gdopp74.cre~ ~override~
~_gdopp75.cre~ ~override~
	REPLACE_TEXTUALLY ~_S1-12
	WRITE_ASCII 0x248 ~_opspell~

 

Can you please explain: what are we replacing, with what, and why WeiDU lets us do it in such strange way?

 

I'd leave these lines as they are in BGT conversion, but after adding new component for BP compatibility (even if nothing else changed) WeiDU refuses to compile this spot.

[DavidW]

I give up, I don't know how the following code works:

 

COPY_EXISTING 
~_doppgr.cre~ ~override~
	REPLACE_TEXTUALLY ~_S1-12

COPY_EXISTING
~_gdopp7.cre~ ~override~
~_gdopp71.cre~ ~override~
~_gdopp72.cre~ ~override~
~_gdopp73.cre~ ~override~
~_gdopp74.cre~ ~override~
~_gdopp75.cre~ ~override~
	REPLACE_TEXTUALLY ~_S1-12
	WRITE_ASCII 0x248 ~_opspell~

 

Can you please explain: what are we replacing, with what, and why WeiDU lets us do it in such strange way?

 

I'd leave these lines as they are in BGT conversion, but after adding new component for BP compatibility (even if nothing else changed) WeiDU refuses to compile this spot.

 

What's happening is that your text editor isn't showing null characters, and is deleting them when you resave the document.

 

What I'm doing is doing a search-and-replace to replace"_S1-12" with "dw#grdop" (it's simpler to do it this way than to have to find the equipment offsets). But because "_S1-12" is six characters and "dw#grdop" is eight, if you do a straight search-and-replace then two bytes get dropped from the file and it gets corrupted. So there are two null characters after the _S1-12. (I put them in using a hex editor). Your text editor is just deleting everything after the first null character).

 

There are null characters in quite a few places in SCS (normally when I'm overwriting script assignments in CRE files) so this may cause you problems more places than just here...

[pro5]

What's happening is that your text editor isn't showing null characters, and is deleting them when you resave the document.

Ah, this explains everything.

 

What editor do you normally use which can correctly work with null characters?

[DavidW]

What's happening is that your text editor isn't showing null characters, and is deleting them when you resave the document.

Ah, this explains everything.

 

What editor do you normally use which can correctly work with null characters?

 

I normally shove the null characters in at the end with something like xvi32 (freeware). The text editor I use (PFE) doesn't actually disrupt lines with nulls on provided you don't edit those lines (or copy-paste them, etc); I think the same is true for Notepad.

[pro5]

Thanks for pointing this out.

 

For anyone interested reading this: never use Crimson Editor when working with DW's code.

 

Windows Notepad or more advanced Notepad2 editors do a much better job.

[CamDawg]

What's happening is that your text editor isn't showing null characters, and is deleting them when you resave the document.

 

What I'm doing is doing a search-and-replace to replace"_S1-12" with "dw#grdop" (it's simpler to do it this way than to have to find the equipment offsets). But because "_S1-12" is six characters and "dw#grdop" is eight, if you do a straight search-and-replace then two bytes get dropped from the file and it gets corrupted. So there are two null characters after the _S1-12. (I put them in using a hex editor). Your text editor is just deleting everything after the first null character).

 

There are null characters in quite a few places in SCS (normally when I'm overwriting script assignments in CRE files) so this may cause you problems more places than just here...

This concerns me in that players can potentially fubar their copy of SCS simply by browsing the tp2, or (much worse and probably just as likely) I could ruin if I happen to open up the tp2 before making or updating a package, or any of the other myriad dumb things I'm prone to do. Changing these to loops is probably a short-term hassle, but probably a good long-term investment of time:

 

// item replacement
COPY_EXISTING ~foo.cre~ ~override~
 READ_LONG   0x2bc "itm_off" ELSE 0
 READ_LONG   0x2c0 "itm_num" ELSE 0
 FOR (index = 0; index < itm_num; index = index + 1) BEGIN // searches through items
READ_ASCII ("%itm_off%" + (0x14 * "%index%")) "item"
PATCH_IF ("%item%" STRING_COMPARE_CASE "old_item" = 0) BEGIN // old item
  WRITE_ASCII ("%itm_off%" + (0x14 * "%index%")) "new_item" #8 // new item
END
 END
 BUT_ONLY_IF_IT_CHANGES

// script repacement
COPY_EXISTING ~bar.cre~ ~override~
 FOR (index = 0; index < 5; index = index + 1) BEGIN
READ_ASCII (0x248 + ("%index%" * 0x08)) "script" ELSE ""
PATCH_IF ("old_bcs" STRING_COMPARE_CASE "%script%" = 0) BEGIN
  WRITE_ASCII (0x248 + ("%index%" * 0x08)) ~new_bcs~ #8
END
 END
 BUT_ONLY_IF_IT_CHANGES

 

It's probably also a bit faster, as WeiDU will no longer have to look through th entire file instead of the item information specifically. Alternatively, for undroppable items you could also do a straight ADD_CRE_ITEM into its current slot--this would force _s1-12 into inventory, but it won't have any effect there.

[cmorgan]

To help out, but also for my own edification;

 

does S_C_C operate with exact text mtch, so that S1-12 is *not* picked if it has the "_" and vice versa?

 

in other words, is case 1 or case 2 better to use?

 

case 1, separate checks and patches for Tutu and BGT versions:

ACTION_IF FILE_EXISTS_IN_GAME ~FW0100.ARE~ THEN BEGIN
// Tutu item replacement
COPY_EXISTING ~_doppgr.cre~ ~override~
 READ_LONG   0x2bc "itm_off" ELSE 0
 READ_LONG   0x2c0 "itm_num" ELSE 0
 FOR (index = 0; index < itm_num; index = index + 1) BEGIN // searches through items
READ_ASCII ("%itm_off%" + (0x14 * "%index%")) "item"
PATCH_IF ("%item%" STRING_COMPARE_CASE "_S1-12" = 0) BEGIN // old item
  WRITE_ASCII ("%itm_off%" + (0x14 * "%index%")) "dw#grdop" #8 // new item
END
 END
 BUT_ONLY_IF_IT_CHANGES
END ELSE BEGIN
// BGT item replacement
COPY_EXISTING ~_doppgr.cre~ ~override~
 READ_LONG   0x2bc "itm_off" ELSE 0
 READ_LONG   0x2c0 "itm_num" ELSE 0
 FOR (index = 0; index < itm_num; index = index + 1) BEGIN // searches through items
READ_ASCII ("%itm_off%" + (0x14 * "%index%")) "item"
PATCH_IF ("%item%" STRING_COMPARE_CASE "_S1-12" = 0) BEGIN // old item
  WRITE_ASCII ("%itm_off%" + (0x14 * "%index%")) "dw#grdop" #8 // new item
END
 END
 BUT_ONLY_IF_IT_CHANGES
END

 

case 2: straight S_C_C with both string versions:

COPY_EXISTING
~_gdopp7.cre~ ~override~
~_gdopp71.cre~ ~override~
~_gdopp72.cre~ ~override~
~_gdopp73.cre~ ~override~
~_gdopp74.cre~ ~override~
~_gdopp75.cre~ ~override~
/* Reassign 0x248 */
 WRITE_ASCII 0x248 ~_opspell~ #8
/* item replacement */
 READ_LONG   0x2bc "itm_off" ELSE 0
 READ_LONG   0x2c0 "itm_num" ELSE 0
 FOR (index = 0; index < itm_num; index = index + 1) BEGIN // searches through items
READ_ASCII ("%itm_off%" + (0x14 * "%index%")) "item"
  PATCH_IF ("%item%" STRING_COMPARE_CASE "_S1-12" = 0) BEGIN // old item
	WRITE_ASCII ("%itm_off%" + (0x14 * "%index%")) "dw#grdop" #8 // new item
  END
PATCH_IF ("%item%" STRING_COMPARE_CASE "S1-12" = 0) BEGIN // old item
  WRITE_ASCII ("%itm_off%" + (0x14 * "%index%")) "dw#grdop" #8 // new item
END
 END
 BUT_ONLY_IF_IT_CHANGES

??

[CamDawg]

One of the dangers you run with a REPLACE_TEXTUALLY is that it will replace any ASCII strings that match it which means it can potentially replace any resource references (scripts, DVs, memorized spells) in the target file. While it's unlikely that something like _s1-s12 is gong to be anywhere else, I'm way too anal retentive to run a R_T where it could potentially match and replace something unintended.

 

For the example provided, a better choice would just be a STRING_COMPARE_REGEXP that matches both _s1-12 and s1-12:

 

COPY_EXISTING ~_doppgr.cre~ ~override~
 READ_LONG   0x2bc "itm_off" ELSE 0
 READ_LONG   0x2c0 "itm_num" ELSE 0
 FOR (index = 0; index < itm_num; index = index + 1) BEGIN // searches through items
READ_ASCII ("%itm_off%" + (0x14 * "%index%")) "item"
PATCH_IF ("%item%" STRING_COMPARE_REGEXP "_?S1-12" = 0) BEGIN // old item
  WRITE_ASCII ("%itm_off%" + (0x14 * "%index%")) "dw#grdop" #8 // new item
END
 END
 BUT_ONLY_IF_IT_CHANGES

 

In some cases you could make the copy itself a regexp and forgo the need for an ACTION_IF altogether (this would copy both doppgr.cre and _doppgre.cre):

 

COPY_EXISTING_REGEXP GLOB ~^_?doppgr\.cre$~ ~override~
 READ_LONG   0x2bc "itm_off" ELSE 0
 READ_LONG   0x2c0 "itm_num" ELSE 0
 FOR (index = 0; index < itm_num; index = index + 1) BEGIN // searches through items
READ_ASCII ("%itm_off%" + (0x14 * "%index%")) "item"
PATCH_IF ("%item%" STRING_COMPARE_REGEXP "_?S1-12" = 0) BEGIN // old item
  WRITE_ASCII ("%itm_off%" + (0x14 * "%index%")) "dw#grdop" #8 // new item
END
 END
 BUT_ONLY_IF_IT_CHANGES

 

I abuse utilize this trick quite a bit in Tweaks for the Tutu/BGT components.

[cmorgan]

very cool... and now I need to go back and play with the BG1 NPC patch behavior dealing with Tutu to BGT stuff!

There are some tricky areas with Tutu and BGT having dfferent weapons and armor... there must be a good regexp way of simply removing the "_" from resource/item entries, but if I recall correctly some of the wands, etc. do not directly translate like SWH07 and _SWH07. It shouldn't matter for the above code for DavidW; I am tossing this out for the folks checking the translation version to BGT.

[the bigg]

If you want to use \00 in your ASCII strings, use the ever-present \n workaround:

OUTER_INNER_PATCH ~1~ BEGIN
 WRITE_BYTE 1 0
 READ_ASCII 1 null (1)
END

DO_THIS_AND_THAT

COPY_EXISTING
~_doppgr.cre~ ~override~
	REPLACE_TEXTUALLY ~_S1-12%null%~

[DavidW]

Great, that's all very helpful - I'll edit those nulls out of the next release.

 

(Basically I learned my WEIDU coding from reverse-compiling Tactics - I've never been nearly as proficient with it as with scripting, and I've been only gradually waking up to how much WEIDU coding has moved on in the last couple of years...)

[pro5]

If you want to use \00 in your ASCII strings, use the ever-present \n workaround:

OUTER_INNER_PATCH ~1~ BEGIN
 WRITE_BYTE 1 0
 READ_ASCII 1 null (1)
END

DO_THIS_AND_THAT

COPY_EXISTING
~_doppgr.cre~ ~override~
	REPLACE_TEXTUALLY ~_S1-12%null%~

 

It doesn't work this way:

 

ERROR: illegal 1-byte write ( ) offset 1 of 1-byte file INNER_PATCH "1"
Stopping installation because of error.

 

But this does:

OUTER_INNER_PATCH ~13~ BEGIN
 WRITE_BYTE 1 0
 READ_ASCII 1 null (1)
END

[DavidW]

FOr anyone who's worried, v4 of SCS now incorporates these kinds of workarounds to avoid using EOL characters. Thanks for the help explaining how, people.