pro5 Posted November 6, 2006 Share Posted November 6, 2006 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. Link to comment
DavidW Posted November 6, 2006 Share Posted November 6, 2006 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... Link to comment
pro5 Posted November 6, 2006 Author Share Posted November 6, 2006 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? Link to comment
DavidW Posted November 6, 2006 Share Posted November 6, 2006 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. Link to comment
pro5 Posted November 6, 2006 Author Share Posted November 6, 2006 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. Link to comment
CamDawg Posted November 6, 2006 Share Posted November 6, 2006 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. Link to comment
cmorgan Posted November 6, 2006 Share Posted November 6, 2006 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 ?? Link to comment
CamDawg Posted November 6, 2006 Share Posted November 6, 2006 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. Link to comment
cmorgan Posted November 6, 2006 Share Posted November 6, 2006 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. Link to comment
the bigg Posted November 7, 2006 Share Posted November 7, 2006 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%~ Link to comment
DavidW Posted November 7, 2006 Share Posted November 7, 2006 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...) Link to comment
pro5 Posted November 8, 2006 Author Share Posted November 8, 2006 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 Link to comment
DavidW Posted January 4, 2007 Share Posted January 4, 2007 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. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.