ALTER_SPELL_EFFECT, negative values

[critto]

So, apparently, WeiDU's ALTER_SPELL_EFFECT function interprets negative values as no change. What if I need to set a negative value (for opcode 30, in this case)? Is there a workaround or do I have to resort to direct patching via offsets?

[subtledoctor]

I think for ALTER_SPELL_EFFECT (and ADD_SPELL _EFFECT, and ADD_ITEM_EQEFFECT, etc - the old macros) you can use

 

(0 - 1)

 

For ALTER_EFFECT, CLONE_EFFECT, etc. (the newer ones) you cannot use negative values.

[critto]

I tried it, but this syntax gives me errors:

 

 

LAUNCH_PATCH_FUNCTION ~ALTER_SPELL_EFFECT~
    INT_VAR
      check_headers = ~1~
      header_type = ~1~
      match_opcode = ~30~
      parameter1 = (0-20)
  END

[Magus]

Try 0xffffffec

[critto]

Nope, doesn't work either.

[subtledoctor]

Sorry, try ~(0 - 1)~

[critto]

Yeah, I also tried that and it doesn't work too. Fails with an error.

[subtledoctor]

Weird. I know I've used it successfully... hang on -

 

Ah, here is something I used in my mod to apply penalties to heavy weapons:

 

COPY_EXISTING_REGEXP GLOB ~.*\.itm~ ~override~
    PATCH_IF (~%SOURCE_SIZE%~ > ~0x71~) BEGIN
        READ_BYTE ~0x31~ ~prof~
        PATCH_IF (~%prof%~ = ~89~) BEGIN // bastard sword
            LPF ADD_ITEM_EQEFFECT INT_VAR opcode=305 target=1 timing=2 parameter1=(0 - 1) parameter2=0 END
        END
    END
BUT_ONLY

 

I assumed ALTER_SPELL_EFFECT would work similarly, but maybe that's a bad assumption.

[critto]

https://github.com/WeiDUorg/weidu/blob/174f3f58ff489391fa8f89dc4419f13878c051df/src/tph/include/g_macros.tpa

 

ADD_ITEM_EQEFFECT does not appear to do any checks before writing parameter1 to the appropriate offset. The ALTER_SPELL_EFFECT function, however, does a PATCH_IF (parameter1 >= 0) check, as can be found here: https://github.com/WeiDUorg/weidu/blob/174f3f58ff489391fa8f89dc4419f13878c051df/src/tph/include/cd_functions.tpa

 

I didn't study the WeiDU's parser code, but I suspect that WeiDU evaluates whatever was passed to parameter1 (be it subtraction, straight-up negative value, hex number, etc.) and then checks it against the right-hand operand.

[Magus]

Well it's obviously an oversight. Defaults must be out of bounds to filter them out.

I'd copy the code to a custom function, adjust it properly and use that. Send pull to upstream, too.

[critto]

Yes, I made a custom function locally. However, I think Wisp has pulled UNDEFINED from 239, that makes it more difficult to make a proper patch without workarounds.

I'll have to study the WeiDU documentation once more, but so far I see no solution that does not involve some sort of workaround, e.g. http://gibberlings3.net/forums/index.php?showtopic=27709&do=findComment&comment=240332 (great for local use in a single mod, but not something I'd present into the primary distribution).

A thread from WeiDU's forum for reference http://forums.pocketplane.net/index.php/topic,29445.0.html