2 replies to this topic

[CamDawg]

The item patching is corrupting a numer of files because it is writing absolute values at absolute offsets, rather than accounting for other possible patches. It is dangerous to use an absolute value when WRITEing beyond 0x72 (114), because these offsets can change if an ability or new effect gets added to the item by another mod. Instead, replace these by reading the item offset fields and using relative values from the offsets. You're also using WRITE_BYTES everywhere, instead of ASCII, SHORT, and LONG as appropriate.

To make truly compatible patches you're going to need a few WHILE loops, even for the patches without a new effect being added. For example, this will properly patch BLUN04.itm and allow the mod to be installed any time in the order:

COPY_EXISTING ~blun04.itm~ ~override~
  READ_LONG  0x6A "fx_offset"
  READ_SHORT 0x70 "fx_num"
  WHILE ("%fx_num%" > 0) BEGIN
    READ_SHORT ("%fx_offset%" +        (0x30 * ("%fx_num%" - 1))) "type"
    READ_LONG  ("%fx_offset%" + 0x08 + (0x30 * ("%fx_num%" - 1))) "location"
    WHILE (("%type%" = 7) AND ("%location%" = 16)) BEGIN
      WRITE_BYTE ("%fx_offset%" + 0x0C + (0x30 * ("%fx_num%" - 1))) 2 // instant/while equipped
      SET "type" = 8
    END
    SET "fx_num" = ("%fx_num%" - 1)
  END

This reads the number of effects, and searches each one of them until it finds the one controlling the color (type = 7) of the weapon head color (location = 16) and then patches the duration field to instant/while equipped ( = 2).

This also needs to be extended to the patches where effects are being added. Writing an absolute value to the number of global effects fields corrupts any file which may have been patched by another mod. It needs to be read and adjusted instead, in addition to the changes above.

COPY_EXISTING ~shld02.itm~ ~override~
  READ_LONG  0x6A "fx_offset"
  READ_SHORT 0x70 "fx_num"
  WRITE_ASCII 0x3A ~ISHLD02~ 
  WRITE_BYTE  0x41 0
  WRITE_ASCII 0x44 ~GSHLD01~ 
  WRITE_BYTE  0x4B 0
  WRITE_SHORT 0x70 ("%fx_num%" + 1) // 1 = number of new effects
  WHILE ("%fx_num%" > 0) BEGIN
    READ_SHORT ("%fx_offset%" +        (0x30 * ("%fx_num%" - 1))) "type"
    READ_LONG  ("%fx_offset%" + 0x08 + (0x30 * ("%fx_num%" - 1))) "location"
    WHILE (("%type%" = 7) AND ("%location%" = 37)) BEGIN
      WRITE_BYTE ("%fx_offset%" + 0x04 + (0x30 * ("%fx_num%" - 1))) 24
      SET "type" = 8
    END
    WHILE (("%type%" = 7) AND ("%location%" = 32)) BEGIN
      WRITE_BYTE ("%fx_offset%" + 0x04 + (0x30 * ("%fx_num%" - 1))) 25
      SET "type" = 8
    END
    SET "fx_num" = ("%fx_num%" - 1)
  END
  INSERT_BYTES "%fx_offset%" 0x30
  WRITE_SHORT "%fx_offset%" 7 // effect type
  WRITE_BYTE ("%fx_offset%" + 0x02) 1 // target self
  WRITE_LONG ("%fx_offset%" + 0x04) 29 // color index
  WRITE_LONG ("%fx_offset%" + 0x08) 34 // location
  WRITE_BYTE ("%fx_offset%" + 0x0C) 2 // instant/while equipped
  WRITE_BYTE ("%fx_offset%" + 0x12) 100 // probability 2

[Erephine]

If someone makes a working WeiDU version from the release, i'll add it. Please keep in mind that none of the WeiDU versions are made by me

[the bigg]

Eh... to save time I simply had run weidu --cmp-from --cmp-to...

When I am done with extending compatibility for Refinements (and adding new contents) I will apply the installer upgrading.
But forget upgrading to WRITE_PROPER, since using WRITE_BYTE's effects are the same (and I already have it done & working ).