Jump to content

Trouble with TP2 code


Skye

Recommended Posts

I'm just starting out with WeiDU (had others do that part in the past) and I could use some help from a WeiDU ninja with a little more experience than me. What I'm trying to do is clean up the item usability flags for kits in each item, more specifically if a core class has the flag set to unusable, I also set it for all of its kits to allow me better customization of item usability for new kits I create.

 

This is what I've come up with:

COPY_EXISTING_REGEXP ~.*\.itm~ ~override~
 READ_LONG     "0x0c" "name"
 READ_SHORT    "0x1c" "type"
 READ_BYTE     "0x1e" "prof1"
 READ_BYTE     "0x1f" "prof2"
 READ_BYTE     "0x20" "prof3"
 READ_BYTE     "0x21" "prof4"
 READ_BYTE     "0x29" "kit1"
 READ_BYTE     "0x2b" "kit2"
 READ_BYTE     "0x2d" "kit3"
 READ_BYTE     "0x2f" "kit4"

 PATCH_IF SOURCE_SIZE > 0x70 THEN BEGIN

 //PATCH_PRINT ~%SOURCE_FILE%~

 //bard
 WHILE (("%prof1%" BAND "0b01000000") = "0b01000000") BEGIN
   WRITE_BYTE   0x2b ("%kit2%" BOR "0b11100000")
   SET ~%kit2%~ |= "0b11100000"
 END

 //cleric
 WHILE (("%prof1%" BAND "0b10000000") = "0b10000000") BEGIN
   WRITE_BYTE   0x29 ("%kit1%" BOR "0b00000111")
   SET ~%kit1%~ |= "0b00000111"
 END

 //fighter
 WHILE (("%prof2%" BAND "0b00001000") = "0b00001000") BEGIN
   WRITE_BYTE   0x2f ("%kit4%" BOR "0b00000111")
   SET ~%kit4%~ |= "0b00000111"
 END

 //mage
 WHILE (("%prof3%" BAND "0b00000100") = "0b00000100") BEGIN
   WRITE_BYTE   0x29 ("%kit1%" BOR "0b10000000")
   SET ~%kit1%~ |= "0b10000000"
   WRITE_BYTE   0x2d ("%kit3%" BOR "0b00111111")
   SET ~%kit3%~ |= "0b00111111"
   WRITE_BYTE   0x2f ("%kit4%" BOR "0b11000000")
   SET ~%kit4%~ |= "0b11000000"
 END

 //paladin
 WHILE (("%prof3%" BAND "0b00010000") = "0b00010000") BEGIN
   WRITE_BYTE   0x2f ("%kit4%" BOR "0b00111000")
   SET ~%kit4%~ |= "0b00111000"
 END

 //ranger
 WHILE (("%prof3%" BAND "0b00100000") = "0b00100000") BEGIN
   WRITE_BYTE   0x2d ("%kit3%" BOR "0b10000000")
   SET ~%kit3%~ |= "0b10000000"
   WRITE_BYTE   0x2b ("%kit2%" BOR "0b00000011")
   SET ~%kit2%~ |= "0b00000011"
 END

 //thief
 WHILE (("%type%" != "0x001d") AND ("%type%" != "0x0011") AND 
       (("%prof3%" BAND "0b01000000") = "0b01000000")) BEGIN
   WRITE_BYTE   0x2b ("%kit2%" BOR "0b00011100")
   SET ~%kit2%~ |= "0b00011100"
 END

 //druid
 WHILE (("%prof4%" BAND "0b01000000") = "0b01000000") BEGIN
   WRITE_BYTE   0x29 ("%kit1%" BOR "0b00111000")
   SET ~%kit1%~ |= "0b00111000"
 END

 END

BUT_ONLY_IF_IT_CHANGES

 

Now while this code works just fine if I define a more specific regular expression, it gets stuck if I use a general one for all items. I guess I'm missing something simple but I'm too tired to think of anyting sensible right now. Any advice is welcome :(

Link to comment

I've skimmed through that thread but haven't really noticed anything that could help me. I changed the code a little and now it gets to a stunning *drumroll* 4th item but then it gets stuck again and this time I don't know what to change. I guess I'll wait for someone more versed in the field. :( (Also edited the original post to show the new code.)

Link to comment

- What item is it failing on? With what error message? (both are usually available by reading SETUP-MYMOD.DEBUG)

- Does it work if you put the READs inside the PATCH_IF SOURCE_SIZE > 0x70 section? Incidentally, it should be >= 0x70 rather than > 0x70.

Link to comment

That's the problem, it doesn't fail anywhere, there's nothing wrong with the code. It simply gets stuck and I have no choice but to close the window. At first it stopped at the first item (abazring.itm), for some reason it didn't like the nested WHILE clauses in the thief part so I made it into one larger condition instead. Now it stops at the fourth item (acidmist.itm) at which it doesn't even get past the first WHILE.

 

And yes, it does work if I put the READs inside the PATCH_IF, that is to say, it works exactly the same. Also having > 0x70 means that the item is more than just a header, changing it to >= 0x70 would make little sense and also little difference.

Link to comment

You'll still want to brace all of the reads inside a SOURCE_SIZE check, as BG2 ToB ships with some zero byte .itm files that will cause read out of bounds errors (you can also READ_FOO offset variable ELSE 0x00, but that won't skip the thrice-damned IF_EVAL pre-pass in WeiDU like that PATCH_IF conditional does).

 

.itm headers are 0x72 bytes unless it's PST or IWD2.

Link to comment

Yes, my beta testers have already noted all that and I got it fixed (I don't have any blank files). However I'm facing a different problem now and this time I don't even know what is wrong much less why it's wrong. The script works fine if I limit the regular expression to some specific, like all axes but if I use .*\.itm it simply goes berserk. Some items are edited fine but in all other cases it evaluates all the conditions as true and I really haven't the slightest clue why, it's like the READs stop working for some reason.

 

Here's the code, I got rid of all the WHILEs since nesting PATCH_IFs seems to work fine (and they were just giving me more trouble anyway). Any ideas? :(

COPY_EXISTING_REGEXP ~.*\.itm~ ~override~

PATCH_IF SOURCE_SIZE > 0x72 THEN BEGIN

 READ_SHORT    "0x1c" "type"
 READ_BYTE     "0x1e" "prof1"
 READ_BYTE     "0x1f" "prof2"
 READ_BYTE     "0x20" "prof3"
 READ_BYTE     "0x21" "prof4"
 READ_BYTE     "0x29" "kit1"
 READ_BYTE     "0x2b" "kit2"
 READ_BYTE     "0x2d" "kit3"
 READ_BYTE     "0x2f" "kit4"

 //bard
 PATCH_IF (("%prof1%" BAND "0b01000000") = "0b01000000") BEGIN
   WRITE_BYTE   0x2b ("%kit2%" BOR "0b11100000")
   SET ~%kit2%~ |= "0b11100000"
 END

 //cleric
 PATCH_IF (("%prof1%" BAND "0b10000000") = "0b10000000") BEGIN
   WRITE_BYTE   0x29 ("%kit1%" BOR "0b00000111")
   SET ~%kit1%~ |= "0b00000111"
 END

 //fighter
 PATCH_IF (("%prof2%" BAND "0b00001000") = "0b00001000") BEGIN
   WRITE_BYTE   0x2f ("%kit4%" BOR "0b00000111")
   SET ~%kit4%~ |= "0b00000111"
 END

 //mage
 PATCH_IF (("%prof3%" BAND "0b00000100") = "0b00000100") BEGIN
   WRITE_BYTE   0x29 ("%kit1%" BOR "0b10000000")
   SET ~%kit1%~ |= "0b10000000"
   WRITE_BYTE   0x2d ("%kit3%" BOR "0b00111111")
   SET ~%kit3%~ |= "0b00111111"
   WRITE_BYTE   0x2f ("%kit4%" BOR "0b11000000")
   SET ~%kit4%~ |= "0b11000000"
 END

 //paladin
 PATCH_IF (("%prof3%" BAND "0b00010000") = "0b00010000") BEGIN
   WRITE_BYTE   0x2f ("%kit4%" BOR "0b00111000")
   SET ~%kit4%~ |= "0b00111000"
 END

 //ranger
 PATCH_IF (("%prof3%" BAND "0b00100000") = "0b00100000") BEGIN
   WRITE_BYTE   0x2d ("%kit3%" BOR "0b10000000")
   SET ~%kit3%~ |= "0b10000000"
   WRITE_BYTE   0x2b ("%kit2%" BOR "0b00000011")
   SET ~%kit2%~ |= "0b00000011"
 END

 //thief
 PATCH_IF (("%type%" != "0x001d") AND ("%type%" != "0x0011") AND 
          (("%prof3%" BAND "0b01000000") = "0b01000000")) BEGIN
   WRITE_BYTE   0x2b ("%kit2%" BOR "0b00011100")
   SET ~%kit2%~ |= "0b00011100"
 END

 //druid
 PATCH_IF (("%prof4%" BAND "0b01000000") = "0b01000000") BEGIN
   WRITE_BYTE   0x29 ("%kit1%" BOR "0b00111000")
   SET ~%kit1%~ |= "0b00111000"
 END

END

BUT_ONLY_IF_IT_CHANGES

Link to comment
What I'm trying to do is clean up the item usability flags for kits in each item, more specifically if a core class has the flag set to unusable, I also set it for all of its kits to allow me better customization of item usability for new kits I create...

 

Now while this code works just fine if I define a more specific regular expression, it gets stuck if I use a general one for all items. I guess I'm missing something simple but I'm too tired to think of anyting sensible right now.

Given what you seem to want to do, I still don't see why this code won't work. Granted, I haven't tested it, and maybe you have to reverse the logic or something, but given the description, it's pretty similar to what you want to do.
Probably good to remove kit restrictions while you're there. I'd do it thusly if it were me
COPY_EXISTING_REGEXP GLOB ~^.+\.itm$~  ~override~
 PATCH_IF (SOURCE_SIZE > 0x71) THEN BEGIN
READ_BYTE  0x1f "u2"
READ_BYTE  0x20 "u3"
PATCH_IF ((("u2" & 0x08) != 0x08) OR (("u3" & 0x40) != 0x40) OR (("u3" & 0x20) != 0x20)) THEN BEGIN
  READ_BYTE   0x29 "k1"
  WRITE_BYTE  0x29 ("k1" & 0xf8)
  PATCH_IF (("u2" & 0x08) != 0x08) THEN BEGIN
	SET "u2" &= (` 0xc0)
  END
  PATCH_IF (("u3" & 0x40) != 0x40) THEN BEGIN
	SET "u2" &= (` 0x02)
  END
  PATCH_IF (("u3" & 0x20) != 0x20) THEN BEGIN
	SET "u2" &= (` 0x04)
  END
END
WRITE_BYTE  0x1f "u2"
 END
BUT_ONLY

Link to comment

The logic in this code snippet is the same, albeit the BAND and BOR are reversed because it does about the reverse thing that mine does. However I don't see any big difference between my last version of the code and this one, I even changed it to match (using hexes, writing only at the end, cleaning quote marks). No effect, I just can't see why it doesn't work, there's nothing wrong with it. Bloody annoying :(

Link to comment

Try running it (from the command-line) with `setup-mymod.exe --debug-value --debug-assign'. It'll show exactly what variables are set, allowing you to identify problems (more) easily.

 

I see you're doing

SET ~%kit2%~ = BLAH

Using ~%var%~ will replace the string with its value, so you're effectively doing

SET "0b0101010101" = BLAH

which is probably not what you wanted. Try removing all ~~ and %%s - they're basically useless for numeric values, and are only needed for some strings.

Link to comment

I don't think that you even need the SET lines at all :(

 

/edited to add

 

But if you want to keep them, Bigg is of course correct and the % would have to go (if you want a variable evaluated on the left hand side of a SET or SPRINT patch, you'll be wanting EVALUATE_BUFFER anyway - since you don't here, it's redunant)

 

"quotes" around a constant are redundant too. They're not strictly needed around integer variables either, but I like to use them to make searching for variable-name typos easier.

Link to comment
Try removing all ~~ and %%s - they're basically useless for numeric values, and are only needed for some strings.
This seems to have worked, I haven't tested it fully yet, I'll leave it up to the beta testers but from what I could tell it fixed the problem. I don't even know why I was using that, I think I had some trouble in the first testing version and just kept it afterwards. Well anyway, thanks for the help, I'll mention you guys in the credits section :(
Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...