CLONE_EFFECT header_type (EDIT - or maybe [anything]_EFFECT)

[subtledoctor]

This code:

Code: [Select]

COPY_EXISTING_REGEXP GLOB ~^.+\.itm$~ ~override~
  PATCH_IF (%SOURCE_SIZE% > 0x71) BEGIN
LPF CLONE_EFFECT INT_VAR silent = 1 multi_match = 1 header_type = 1 opcode = 318 target = 2 parameter1 = 121 parameter2 = 110 timing = 0 duration = 0 STR_VAR resource = EVAL ~%SOURCE_RES%~ insert = ~first~ END
LPF CLONE_EFFECT INT_VAR silent = 1 multi_match = 1 header_type = 2 opcode = 318 target = 2 parameter1 = 121 parameter2 = 110 timing = 0 duration = 0 STR_VAR resource = EVAL ~%SOURCE_RES%~ insert = ~first~ END
  END
IF_EXISTS BUT_ONLY
...is designed to clone one effect in each melee and ranged weapon header. This the "header_type = 1/2."  But it adds both 318 effects to the item's equipping effects as well as to melee and ranged headers.

[Wisp]

I can reproduce a problem, but not the one you are describing. When I run your code, two effects are inserted among the global effects, but none on the abilities. If you set check_globals to 0, the global effects are not added, but no effect is cloned. You do not use any of the match_* variables, so nothing is matched. Back to the drawing board, or am I missing something? I'll look into why effects are created with check_globals set to 1; that does not seem right.

[subtledoctor]

It works fine for me - hmm, can we not upload screenshots here?  Anyway, after installing this on BG2EE, the Stonefire Axe gets a 318 effect inserted before its extra +2 fire damage.  The generic Axe +2 has no header for on-hit effects, so it is not patched.

I didn't even notice the check_globals variable.  That fixes things on my end, though in general, global effects probably shouldn't be cloned when header_type is specified.

[subtledoctor]

Sorry for the double-post, stray thumbs! See following post...

[subtledoctor]

Okay, there is definitely something going on with how CLONE_EFFECT and DELETE_EFFECT deal with global effects. Try something like this on WAND05.itm (Wand of Fire, which has two headers). The idea is to add two opcode 318 effects to the active ability headers (in my case, it is used for adding IWD-style evasion to the wands' targets)

EDIT - dammit, now I cannot reproduce the error. Something about multiple DELETE_EFFECTs being run, followed by multiple ADD_ITEM_EFFECTs, which tripped over the item with two headers. Adding "check_globals = 0" fixed the problem even though the item had no global effects and it should therefore have been superfluous.

Here's another, lesser, concrete example:

Code: [Select]

COPY_EXISTING ~snakspir.itm~ ~override~
  LPF DELETE_EFFECT INT_VAR header_type = 1 END
IF_EXISTS BUT_ONLYThis removes all effects from the item, including global effects, even though specifying "header_type=1" can reasonably be expected to exclude global effects. Specifying the header type is no sufficient to limit the function to effects in a specific header type; it only works correctly if you add "check_globals=0." This is a fine and easy workaround now that I know about it; but based on the Weidu documentation I would not expect it to be necessary.

[DavidW]

This removes all effects from the item, including global effects, even though specifying "header_type=1" can reasonably be expected to exclude global effects. Specifying the header type is no sufficient to limit the function to effects in a specific header type; it only works correctly if you add "check_globals=0." This is a fine and easy workaround now that I know about it; but based on the Weidu documentation I would not expect it to be necessary.

FWIW that's what I would have expected from the description. It either cycles through globals or it doesn't (that's what check_globals does); it either cycles through headers or it doesn't (that's what check_headers does); if it's cycling through headers, you can restrict that cycling to specific headers, but that's independent of its separate cycling through globals.

[subtledoctor]

I mean, it's not a matter of specifying check_headers yes or no; "header_type=1" evinces an intent to limit the changes to effects in headers with the "melee" type. I would expect anything not in a melee-type header to be excluded - global effects as much as ranged effects.

What you say is reasonable, in its way... but I think that interpretation is far from clear based on the plain language of the function and its documentation.