Possible bug in WeiDU?

[grodrigues]

In order to make it easier to patch items, I coded a function:

DEFINE_PATCH_FUNCTION set_item_field STR_VAR field = "" value = "" BEGIN
    //Lower-case field to avoid trivial mismatches.
    TO_LOWER field
    
    //Match on field to decide which write function to use.
    field_offset = $item_offsets("%field%")
    PATCH_MATCH "%field%" WITH
        "id_name"
        "name"
        "id_descr"
        "descr"
        "flags"
        "usability"
        "price"
        "weight"
        "enchantment" BEGIN
            PATCH_PRINT "set_item_field: writing long '%value%' to field '%field%' at offset '%field_offset%'."
            WRITE_LONG field_offset value
        END
        "strength_bonus"
        "intelligence"
        "constitution"
        "dexterity"
        "wisdom"
        "proficiency"
        "kit_usability1"
        "kit_usability2"
        "kit_usability3"
        "kit_usability4" BEGIN
            WRITE_BYTE field_offset value
        END
        "type"
        "level"
        "strength"
        "charisma"
        "stack"
        "lore" BEGIN
            PATCH_PRINT "set_item_field: writing short '%value%' to field '%field%' at offset '%field_offset%'."
            WRITE_SHORT field_offset value
        END
        "animation" BEGIN
            WRITE_EVALUATED_ASCII field_offset "%value%" #2
        END
        "replacement"
        "inventory_icon"
        "ground_icon"
        "description_icon" BEGIN
            WRITE_EVALUATED_ASCII field_offset "%value%" #8
        END
        DEFAULT
            PATCH_FAIL "set_item_field: field '%field%' is not a valid item field."
    END
END

The function is pretty simple: a PATCH_MATCH over the field to select the appropriate write function. Besides the arguments, the only input to the function is the array "item_offsets". The PATCH_PRINT statements were added for debugging. Now running install on a mod where this is is used, we get in the log (just looking at the relevant section):

copy_items_from_table: copying 'spell_overhaul/components/main/resources/itm/spells/ghoul_touch_a.itm' to 'override/ldwi218a.itm'.

set_item_field: writing long '13048' to field 'name' at offset '8'.

set_item_field: writing short '28' to field 'type' at offset '28'.

set_item_field: writing long '0' to field 'price' at offset '52'.

set_item_field: writing long '1' to field 'stack' at offset '56'.

set_item_field: writing short '10' to field 'lore' at offset '66'.

set_item_field: writing long '0' to field 'weight' at offset '76'.

set_item_field: writing long '1' to field 'enchantment' at offset '96'.
Copying and patching 1 file ...

copy_items_from_table: copying 'spell_overhaul/components/main/resources/itm/spells/magical_stone_a.itm' to 'override/ldpr106a.itm'.

set_item_field: writing long '12902' to field 'name' at offset '8'.

set_item_field: writing long '104228' to field 'descr' at offset '80'.

set_item_field: writing short '14' to field 'type' at offset '28'.

set_item_field: writing long '0' to field 'price' at offset '52'.

set_item_field: writing short '20' to field 'stack' at offset '56'.

set_item_field: writing long '0' to field 'lore' at offset '66'.

set_item_field: writing long '0' to field 'weight' at offset '76'.

set_item_field: writing long '1' to field 'enchantment' at offset '96'.
Copying 1 file ...

Let me home in on the two relevant lines:

set_item_field: writing short '10' to field 'lore' at offset '66'.

set_item_field: writing long '0' to field 'lore' at offset '66'.

As you can see in the second line, the `lore` field ended up in the long branch instead of the short. Note that it also happens with the stack field before lore. Writing a long instead of a short is writing to 4 bytes instead of 2, so this will clobber up the file.

I do not see any possible world in which that could happen, outside of a bug in WeiDU with PATCH_MATCH, but maybe someone is smarter than me and can see how this could possibly happen. The problem is compounded by the fact that I can only trigger this apparent bug with the somewhat complicated setup of my mod; all my efforts to narrow it down to a more manageable test case have failed, suggesting that some really weird interaction is going on.

Any suggestions?

Edited November 13, 2023 by grodrigues
couple of info lines

[Magus]

The inability to isolate it says enough.

If you can't build a case from scratch then butcher your mod instead. Throw away all other components, then mechanically cut unrelated code pieces from this component, testing each time, until you actually arrive at a minimal example where it still happens.

Then look at what remains, and if you still can't figure it out, share the full code (branch on github or something).

[grodrigues]

8 hours ago, Magus said:

The inability to isolate it says enough.

No, it is not. But this is entirely my fault, as my question should have been clearer. I should have asked: under what possible conditions can the same string value (in this case, "lore") match against what are obviously mutually exclusive branches in the PATCH_MATCH?

At any rate, I have managed to cut down and segregate to a small-ish, self-contained mod that triggers the behavior above and I have by now a fairly good guess about what triggers it (and if my guess is right, yes, it is a bug).

[grodrigues]

In case anyone is interested, the smallest test case I could get is in this GitHub repository.

[kjeron]

One of the problems is with these lines here:

    OUTER_TEXT_SPRINT stack "20"
    OUTER_TEXT_SPRINT lore "0"
    OUTER_TEXT_SPRINT weight "0"
    OUTER_TEXT_SPRINT enchantment "1"

Weidu automatically attempts to evaluate integer variables, with or without %%, as such, this is valid:

OUTER_SPRINT a ~1~
OUTER_SET b = ~a~ + 1

The "stack" listed among the match values is automatically evaluated to 20 before matching.

[Magus]

Oh right that's it. It's just comparing 0 to 0.

Edited November 16, 2023 by Magus

[grodrigues]

@Kjeron I see, it is not a bug then. It is bat-shit insane behavior, but not a bug. I will close the issue. Thanks a lot for clearing this out for me.

Edited November 16, 2023 by grodrigues