WeiDU CRE patching - how to add BG2 proficiencies?

[Nythrun]

The only thing that leaps out after a casual read through is that the offsets to the known spells list and the spell memorization table aren't being updated; while those are "supposed" to come before the effects list, they might not, necessarily. You could try adding

  SET "new_fx" = 2												  // effect number
 READ_BYTE   0x33 "fx_type"
 READ_LONG  0x2a0 "spell_off"
 READ_LONG  0x2a8 "mem_off"
 READ_LONG  0x2b0 "known_off"
 READ_LONG  0x2b8 "slot_off"
 READ_LONG  0x2bc "itm_off"
 READ_LONG  0x2c4 "fx_off"
 READ_LONG  0x2c8 "fx_num"
 WRITE_LONG 0x2c8 ("%fx_num%" + "%new_fx%")
 SET "offset" = ((0x30 + (0xd8 * "%fx_type%")) * "%new_fx%")
 PATCH_IF ("%spell%" >= "%fx_off%") BEGIN
WRITE_LONG 0x2a0 ("%known_off%" + "%offset%")
 END
 PATCH_IF ("%mem_off%" >= "%fx_off%") BEGIN
WRITE_LONG 0x2a8 ("%known_off%" + "%offset%")
 END
 PATCH_IF ("%known_off%" >= "%fx_off%") BEGIN
WRITE_LONG 0x2b0 ("%known_off%" + "%offset%")
 END
 PATCH_IF ("%slot_off%" >= "%fx_off%") BEGIN
WRITE_LONG 0x2b8 ("%slot_off%" + "%offset%")
 END
 PATCH_IF ("%itm_off%" >= "%fx_off%") BEGIN
WRITE_LONG 0x2bc ("%itm_off%" + "%offset%")
 END

 

and if you still receive "harmless reordering" messages, it probably is harmless reordering

[aVENGER_(RR)]

It's still happening, even with that code. BTW, I think the %spell% in this line:

PATCH_IF ("%spell%" >= "%fx_off%") BEGIN

should be %spell_off%.

 

Anyway, I'm tempted to simply ignore this since everything actually works properly in-game, but I've recently noticed that this warning might not be so harmless after all.

[Nythrun]

Outside of archaic WeiDU ADD_KNOWN_SPELL patches, it shouldn't matter; bgmain doesn't care about the ordering of the various creature blocks (and will reorder them in temp memory anyway). If you're concerned about conflicts with other patches, you can force the issue by reordering the .cre yourself:

  READ_BYTE	  0x033 "eff"
 READ_LONG	  0x2a0 "kso"
 READ_LONG	  0x2a4 "ksc"
 READ_ASCII	 "kso" ~ks~ ("ksc" * 0x0c)
 READ_LONG	  0x2a8 "smo"
 READ_LONG	  0x2ac "smc"
 READ_ASCII	 "smo" ~sm~ ("smc" * 0x10)
 READ_LONG	  0x2b0 "mso"
 READ_LONG	  0x2b4 "msc"
 READ_ASCII	 "mso" ~ms~ ("msc" * 0x0c)
 READ_LONG	  0x2b8 "iso"
 READ_BYTE	  ("iso" + 0x4f) "chk" ELSE 0xeeee
 PATCH_IF	   !("chk" = 0xeeee) THEN BEGIN
READ_ASCII   "iso" ~is~ (0x50)
 END
 READ_LONG	  0x2bc "ilo"
 READ_LONG	  0x2c0 "ilc"
 READ_ASCII	 "ilo" ~il~ ("ilc" * 0x14)
 READ_LONG	  0x2c4 "elo"
 READ_LONG	  0x2c8 "elc"
 READ_ASCII	 "elo" ~el~ ("elc" * (("eff" & 0x1 = 0x1) ? 0x108 : 0x30))
 DELETE_BYTES   0x2d4 (SOURCE_SIZE - 0x2d4)
 WRITE_LONG	 0x2a0 0x2d4
 INSERT_BYTES   0x2d4 ("ksc" * 0x0c)
 WRITE_ASCIIE   0x2d4 ~%ks%~
 WRITE_LONG	 0x2a8 (0x2d4 + ("ksc" * 0x0c))
 INSERT_BYTES   (0x2d4 + ("ksc" * 0x0c)) (0x11 * 0x10)
 PATCH_IF ("smc" = 0x11) THEN BEGIN
WRITE_ASCIIE (0x2d4 + ("ksc" * 0x0c)) ~%sm%~
 END ELSE BEGIN
WRITE_LONG   0x2ac 0x11
FOR ("i1" = 0x00; "i1" < 0x07; "i1" += 0x01) BEGIN
  WRITE_SHORT ((0x2d4 + ("ksc" * 0x0c)) + ("i1" * 0x10)) "i1"
END
FOR ("i1" = 0x00; "i1" < 0x09; "i1" += 0x01) BEGIN
  WRITE_SHORT ((0x2d4 + ("ksc" * 0x0c)) + ("i1" * 0x10) + 0x070) "i1"
  WRITE_SHORT ((0x2d4 + ("ksc" * 0x0c)) + ("i1" * 0x10) + 0x076) 0x01
END
WRITE_SHORT   ((0x2d4 + ("ksc" * 0x0c)) + ("i1" * 0x10) + 0x106) 0x02
 END
 WRITE_LONG	 0x2b0 (0x2d4 + ("ksc" * 0x0c) + (0x11 * 0x10))
 INSERT_BYTES   (0x2d4 + ("ksc" * 0x0c) + (0x11 * 0x10)) ("msc" * 0x0c)
 WRITE_ASCIIE   (0x2d4 + ("ksc" * 0x0c) + (0x11 * 0x10)) ~%ms%~
 WRITE_LONG	 0x2c4 (0x2d4 + ("ksc" * 0x0c) + (0x11 * 0x10) + ("msc" * 0x0c))
 INSERT_BYTES   (0x2d4 + ("ksc" * 0x0c) + (0x11 * 0x10) + ("msc" * 0x0c)) ("elc" * (("eff" & 0x1 = 0x1) ? 0x108 : 0x30))
 WRITE_ASCIIE   (0x2d4 + ("ksc" * 0x0c) + (0x11 * 0x10) + ("msc" * 0x0c)) ~%el%~
 WRITE_LONG	 0x2bc (0x2d4 + ("ksc" * 0x0c) + (0x11 * 0x10) + ("msc" * 0x0c) + ("elc" * (("eff" & 0x1 = 0x1) ? 0x108 : 0x30)))
 INSERT_BYTES   (0x2d4 + ("ksc" * 0x0c) + (0x11 * 0x10) + ("msc" * 0x0c) + ("elc" * (("eff" & 0x1 = 0x1) ? 0x108 : 0x30))) ("ilc" * 0x14)
 WRITE_ASCIIE   (0x2d4 + ("ksc" * 0x0c) + (0x11 * 0x10) + ("msc" * 0x0c) + ("elc" * (("eff" & 0x1 = 0x1) ? 0x108 : 0x30))) ~%il%~
 WRITE_LONG	 0x2b8 (0x2d4 + ("ksc" * 0x0c) + (0x11 * 0x10) + ("msc" * 0x0c) + ("elc" * (("eff" & 0x1 = 0x1) ? 0x108 : 0x30)) + ("ilc" * 0x14))
 INSERT_BYTES   (0x2d4 + ("ksc" * 0x0c) + (0x11 * 0x10) + ("msc" * 0x0c) + ("elc" * (("eff" & 0x1 = 0x1) ? 0x108 : 0x30)) + ("ilc" * 0x14)) 0x50
 PATCH_IF	   !("chk" = 0xeeee) THEN BEGIN
WRITE_ASCIIE (0x2d4 + ("ksc" * 0x0c) + (0x11 * 0x10) + ("msc" * 0x0c) + ("elc" * (("eff" & 0x1 = 0x1) ? 0x108 : 0x30)) + ("ilc" * 0x14)) ~%is%~
 END ELSE BEGIN
FOR ("i1" = 0x00; "i1" < 0x4c; "i1" += 0x02) BEGIN
  WRITE_SHORT ((0x2d4 + ("ksc" * 0x0c) + (0x11 * 0x10) + ("msc" * 0x0c) + ("elc" * (("eff" & 0x1 = 0x1) ? 0x108 : 0x30)) + ("ilc" * 0x14)) + "i1") 0xffff
END
 END

 

usual caveats about my slapdash and errorprone suggestions apply; I'll check if it even parses tomorrow

[aVENGER_(RR)]

Outside of archaic WeiDU ADD_KNOWN_SPELL patches, it shouldn't matter; bgmain doesn't care about the ordering of the various creature blocks (and will reorder them in temp memory anyway). If you're concerned about conflicts with other patches, you can force the issue by reordering the .cre yourself

 

Nah, I guess I'll just leave it in its current form if it's really that trivial. Thanks anyway!

[Gort]

there is a collision when offsets are equal - it means that at least one of the blocks is empty. And if both are empty - there is no way to determine with weidu if a block with the same offset should get updated or not (if emtpy is only one, you can choose basing on number of units in the block being updated). I don't know what's better - make oversafe coding with the risk of reordering, or imply that a creature is ordered correctly and update only offsets that should be after current. Either way, mixing these two methods may result in corrupted creature. I tend to use the second, for weidu makes the same, if I'm not mistaken.

[Miloch]

If you're concerned about conflicts with other patches, you can force the issue by reordering the .cre yourself:

...

I'll check if it even parses tomorrow

"Tomorrow" = "Mañana" = much, much later...

 

Anyway, it parses, but does nothing to alleviate the "harmless reordering" message after adding a proficiency effect with one of the methods above (one of which changes the priest spell levels 2 and 3 to 234 and 105 respectively, but, well... that's another issue).

 

So... is it really "harmless" if we patch the creature to cause this message that wasn't there before and someone wants to come by later and patch it with something else?

[aVENGER_(RR)]

Anyway, it parses, but does nothing to alleviate the "harmless reordering" message after adding a proficiency effect with one of the methods above (one of which changes the priest spell levels 2 and 3 to 234 and 105 respectively, but, well... that's another issue).

 

If BG2 proficiencies are your primary concern, note that the bigg added a native SET_BG2_PROFICIENCY command to WeiDU a couple of versions ago. See this thread for details.

 

FYI, using that command won't cause the "harmless inconsistency" error to appear.

[Miloch]

Ah, cool. I guess I should stop living in the 80s, or in 2007 anyway.