Posted by: Ascension64
« on: August 17, 2007, 07:31:14 AM »OK, thanks for the information.
BEGIN @1114 /* The BG1 NPC Project: SixofSpades Extended Sarevok's Diary */
SUBCOMPONENT @1115 /* The BG1 NPC Project: Sarevok's Diary Adjustments. */
GROUP @1065 /* The BG1 NPC Project: Tweaks */
REQUIRE_FILE ~override/X#BG1NPCCore.G3~ @1004 /* BG1 NPC Required Changes component is not installed. */
/* SixofSpades Sarevok's Diary changes, Tutu/BGT */
COPY_EXISTING ~%tutu_var%SCRL3F.itm~ ~override~
SAY UNIDENTIFIED_DESC @575
SAY DESC @575
WRITE_SHORT 0x1c 0x25 // Sets item category from Scrolls to Books
WRITE_BYTE 0x4c 0x08 // Sets weight to 8 lbs
BUT_ONLY_IF_IT_CHANGES
BEGIN @1116 /* The BG1 NPC Project: Sarevok's Diary Date Changes only */
SUBCOMPONENT @1115 /* The BG1 NPC Project: Sarevok's Diary Adjustments. */
GROUP @1065 /* The BG1 NPC Project: Tweaks */
REQUIRE_FILE ~override/X#BG1NPCCore.G3~ @1004 /* BG1 NPC Required Changes component is not installed. */
/* Fixing Sarevok's Diary dates changed only, Tutu/BGT */
COPY_EXISTING ~%tutu_var%SCRL3F.itm~ ~override~
SAY UNIDENTIFIED_DESC @2
SAY DESC @2
WRITE_SHORT 0x1c 0x25 // Sets item category from Scrolls to Books
WRITE_BYTE 0x4c 0x08 // Sets weight to 8 lbs
BUT_ONLY_IF_IT_CHANGES
Yes, obviously, [ \t] will also pick up a space character. So duplicate column 0 entries still work nearly-correctly? What would happen?I'm not sure what you're asking. If there is more than one symbol for the same value, it should work correctly (the APPEND won't happen if there are any lines beginning with "VALUE "). If you want to append your own symbol where one already exists, you wouldn't use UNLESS with the (Column 0) value, and it would work fine (but WeiDU will choose the last defined symbol -- the one you just appended -- when decompiling scripts and when compiling dialogues). (Near Infinity works opposite here, and the first defined symbol wins, so it shouldn't change NI's decompile behavior at all).
Nythrun just said "Stats.ids in BG1/BG2/Tutu contains tab delimitation". So I suppose they shouldn't use tabs, but you'd still have to use a different regexp to catch Stats.ids entries, like [^A-Za-z0-9_], right?It's common to use a bit of code to create a 4-byte value with the characters you want to test for. Nythrun has a cleaner bit of code, but it usually resembles
INNER_PATCH 1234 BEGIN
WRITE_BYTE 0x0 0x20 // Space
WRITE_BYTE 0x1 0x9 // Tab
WRITE_BYTE 0x2 0xd // CR
WRITE_BYTE 0x3 0xa // LF
READ_ASCII 0x0 whitespace (4)
END
When constructing your expression, you'd use [%whitespace%] to match any spaces, tabs, or line breaks in the source string. (But be aware that I've had only limited success getting this to actually work correctly with WeiDU on Mac OS X.) It's almost never necessary when specifying constraints for APPEND, etc., however (but it would be useful in the case where a string you wanted to match already had tabs or line breaks).Since it's engendered such discussion, I just wanted to mention that the code does work and will do the right thing in almost all cases. In the unlikely situation that any of the values being appended appear in the IDS file and are followed by a tab, the append will happen anyway, but it will still be functioning nearly-correctly.Yes, obviously, [ \t] will also pick up a space character. So duplicate column 0 entries still work nearly-correctly? What would happen?
2DA and IDS files shouldn't use tabs to separate columns anyway, so you could almost consider it a feature that tabs aren't correctly matched by the caml regexp.Nythrun just said "Stats.ids in BG1/BG2/Tutu contains tab delimitation". So I suppose they shouldn't use tabs, but you'd still have to use a different regexp to catch Stats.ids entries, like [^A-Za-z0-9_], right?