Variables and macros

[Miloch]

I just wrote some code that patches some tables in a complex manner based on whether it has certain columns and/or rows present etc. It uses a crapload of variables and arrays to keep track of things while it reads the tables during a COPY_EXISTING and then conditionally makes row/column additions with APPEND/APPEND_COL after the COPY is done processing. Well, it was working just fine until I moved some of the code to macros and PATCH_INCLUDEd them (obviously for efficiency purposes, since I plan on calling the code in more than one place). Now, it still works, but without changing anything else, it returns variable names rather than the values assigned to them in the patched tables. According to the WeiDU doc, "Variables inside macros that are changed keep their new value once the macro has finished being computed." While previously I've seen this to be true, is this true for arrays? Also, does a variable (or array) assigned in one macro get retained when processing passes to another macro? Somewhere this logic is bombing, and I'm not sure where.

 

(P.S.: Please don't ask to look at the code, except as a last resort - it would make your eyes bleed.)

[Icendoan]

Oooooh!

 

Lets look at the code!

 

 

Icen

[Taimon]

If you have a snippet which shows the problem, post it. I really have difficulties understanding your issue.

[Miloch]

Sigh. I was suspecting it's a WeiDU bug having to do specifically with the array construct (and not normal variables) and no, there's no snippet that'll indicate this, since you'll have to look at (and execute) the full code in a mainlined TP2 (where it runs successfully) and the same code segmented into macros (where it also runs successfully but returns variable names rather than their values). I guess I'll upload it somewhere and send you a link.

 

Edit: PM sent. I managed to isolate a smaller reproduceable snippet, but it still required subfiles a bit beyond code that could be inlined without being obnoxious.

[Miloch]

Thanks to Taimon's suggestion, using PHP_EACH instead of PATCH_FOR_EACH seemed to solve the problem. More exaustive documentation will be provided by SConrad .

[Taimon]

By the way, I compared the output from --debug-assign to find the issue.

May be helpful in debugging other things.

[Galactygon]

Miloch, could you do me a favour and send me the macros that remove extended headers? I will need them later.

 

-Galactygon

[Icendoan]

There are macros for them in Gort's Library. REMOVE_(EQ)EFFECT and the like.

 

Icen

[Miloch]

There are macros for them in Gort's Library. REMOVE_(EQ)EFFECT and the like.

Yes, but those only remove effects, not headers.

 

This is a subset of the t-spl_eff_del.tpp macro found in PnP Free Action that removes dead headers on items (if there is more than one header, they are unnecessary). You'd just have to change the PATCH_IF parameters for it to work on spells.

PATCH_IF !(~%SOURCE_FILE%~ STRING_MATCHES_REGEXP ~^.+\.spl~) BEGIN
 hs = 0x28 //Extended header size
END ELSE PATCH_IF !(~%SOURCE_FILE%~ STRING_MATCHES_REGEXP ~^.+\.itm~) BEGIN
 hs = 0x38
END
READ_LONG 0x64 hf //Extended header offset
READ_SHORT 0x68 hc //Extended header count
READ_LONG 0x6a fb //Feature block offset
FOR (i1 = 0; i1 < hc; i1 += 1) BEGIN //Cycle through extended headers
 READ_BYTE (hs * i1 + hf) tk //Attack type
 PATCH_IF (hs = 56) AND (tk = 0) AND (hc > 1) BEGIN //Remove dead headers on items
READ_SHORT (hs * i1 + hf + 0x1e) fc //Feature count
READ_SHORT (hs * i1 + hf + 0x20) fs //Feature offset
DELETE_BYTES (fs * 0x30 + fb) (fc * 0x30) //Delete all effects
WRITE_SHORT (hs * i1 + hf + 0x1e) 0 //Update feature count
FOR (i4 = i1; i4 < hc; i4 += 1) BEGIN //Update 1st effect indices
  READ_SHORT (hs * i4 + hf + 0x20) fs //1st effect index
  WRITE_SHORT (hf + i4 * hs + 0x20) (fs - fc) //Decrease 1st effect index by fc
END
DELETE_BYTES (hs * i1 + hf) hs //Delete header
hc -= 1
WRITE_SHORT 0x68 hc //Update header count
WRITE_LONG 0x6a (fb - hs) //Update feature block offset
 END
END

Feel free to use it and anthing else, though you probably can't read the code at all, on account of my short variable names. Apparently using hideously-long variable names is better than just commenting the code ( @ Ascension64).

[Galactygon]

Thanks Miloch. This part I am having trouble with, and I am most curious of the "!".

 

PATCH_IF !(~%SOURCE_FILE%~ STRING_MATCHES_REGEXP ~^.+\.spl~) BEGIN
 hs = 0x28 //Extended header size
END ELSE PATCH_IF !(~%SOURCE_FILE%~ STRING_MATCHES_REGEXP ~^.+\.itm~) BEGIN
 hs = 0x38
END

 

-Galactygon

[Taimon]

Yeah, this is unintuitive WeiDU syntax. STRING_MATCHES_REGEXP returns 0 if it matches (which would be false in boolean sense, so it needs to be inverted with the ! [NOT]).

By the way, there is a SOURCE_EXT variable available for checking file extensions. (since v206)

[Miloch]

By the way, there is a SOURCE_EXT variable available for checking file extensions. (since v206)

Ah, another undocumented feature. That would probably be more efficient. Would the correct syntax be something like PATCH_IF (~%SOURCE_EXT%~ STRING_EQUAL_CASE ~spl~ = 1) BEGIN?

[Taimon]

Yes, but you can scratch that "= 1". (I think the *_EXT is mentioned in the changelog somewhere. )