23 replies to this topic

[aVENGER_(RR)]

Ok, so let's see if we can get a consensus on this. The current proposal for the Azuredge fix is as follows:

1) Uncorrupt the item by fixing the misaligned indexes
2) Reduce the ranged damage to from 3d6 to 1d6 to match the item description
3) Allow the ranged attack to apply a strength based damage bonus to match all the other throwing axes in the game
4) Increase the extra damage vs. undead creatures to 1d6+4 to match the item description
5) Make two effects for the extra damage, one which deals missile damage for the ranged header and a second one which deals slashing damage for the melee header
6) Since Azuredge has no bonuses to hit and damage in the original game, and the description doesn't mention them, we won't add them (this diverges from Baldurdash)

Lastly, I'd also propose using a modified version of Wisp's code to implement the fix, rather than overwriting the ITM file:

// Azuredge fix (revised by Wisp and aVENGER)

COPY ~bg2fixpack/copy/ax1h10a.eff~  ~override~ // 1d6+4 extra damage vs. undead for Azuredge (slashing)
COPY ~bg2fixpack/copy/ax1h10b.eff~  ~override~ // 1d6+4 extra damage vs. undead for Azuredge (missile)

COPY_EXISTING ~ax1h10.itm~ ~override~
// first uncorrupt the item by fixing the misplaced indexes
  READ_LONG  0x64 abil_off
  READ_SHORT 0x68 abil_num
  READ_LONG  0x6a fx_off
  READ_SHORT 0x70 fx_num
  t_fx_num = fx_num
  CLEAR_ARRAY ab_array
  GET_OFFSET_ARRAY ab_array 0x64 4 0x68 2 0 0 0x38
  PHP_EACH ab_array AS int => goa_abil_off BEGIN
	CLEAR_ARRAY fx_array
	GET_OFFSET_ARRAY2 fx_array goa_abil_off 0x6a 4 0x1e 2 0x20 2 0x30
	PHP_EACH fx_array AS int => goa_fx_off BEGIN
	  t_fx_num += 1
	END
  END
PATCH_IF 0x72 + abil_num*0x38 + 0x30*t_fx_num < BUFFER_LENGTH BEGIN
  DELETE_BYTES 0x72 + abil_num*0x38 + 0x30*t_fx_num BUFFER_LENGTH - (0x72 + abil_num*0x38 + 0x30*t_fx_num)
END
LAUNCH_PATCH_FUNCTION ~DELETE_ITEM_EQEFFECT~ INT_VAR "opcode_to_delete" = "177" END              // delete the old, incorrect bonus damage effect
LAUNCH_PATCH_FUNCTION ~DELETE_ITEM_EFFECT~ INT_VAR "opcode_to_delete" = "177" header = "-1" END  // delete the Baldurdash undead slaying effect
LAUNCH_PATCH_FUNCTION ~DELETE_ITEM_EFFECT~ INT_VAR opcode_to_delete = "55" header = "-1" END     // delete the old, incorrect undead slaying effect
FOR (index4 = 0; index4 < "%abil_num%"; index4 += 1) BEGIN
  READ_BYTE   ("%abil_off%" +        ("%index4%" * 0x38)) "abil_type"
// note: the extra damage and the "Undead Destroyed" string need to go before the death effect, otherwise they won't display in the combat log
  PATCH_IF (%abil_type% = 1) BEGIN                                              // melee ability header
  READ_SHORT  ("%abil_off%" + 0x1e + ("%index4%" * 0x38)) "abil_fx_num"
  READ_SHORT  ("%abil_off%" + 0x20 + ("%index4%" * 0x38)) "abil_fx_idx"
    PATCH_FOR_EACH ~resref~ IN ~die~ ~mesdie~ ~ax1h10a~ BEGIN 
     INSERT_BYTES ("%fx_off%" +        ("%abil_fx_idx%" * 0x30))      0x30      // new effect
     WRITE_SHORT  ("%fx_off%" +        ("%abil_fx_idx%" * 0x30))       177      // use eff
     WRITE_BYTE   ("%fx_off%" + 0x02 + ("%abil_fx_idx%" * 0x30))         2      // target: preset target
     WRITE_LONG   ("%fx_off%" + 0x04 + ("%abil_fx_idx%" * 0x30))         4      // param1
     WRITE_LONG   ("%fx_off%" + 0x08 + ("%abil_fx_idx%" * 0x30))         3      // param2
     WRITE_BYTE   ("%fx_off%" + 0x0c + ("%abil_fx_idx%" * 0x30))         1      // timing
     WRITE_BYTE   ("%fx_off%" + 0x12 + ("%abil_fx_idx%" * 0x30))       100      // probability
     WRITE_ASCIIE ("%fx_off%" + 0x14 + ("%abil_fx_idx%" * 0x30)) ~%resref%~ #8  // resref
     SET %abil_fx_num% += 1                                                     // number of ability effects
    END
  WRITE_SHORT (%abil_off% + %index4% * 0x38 + 0x1e) %abil_fx_num%               // update the number of ability effects
  END
END
FOR (index5 = 0; index5 < "%abil_num%"; index5 += 1) BEGIN
  READ_BYTE   ("%abil_off%" +        ("%index5%" * 0x38)) "abil_type"
  PATCH_IF (%abil_type% = 2) BEGIN                                              // ranged ability header
  READ_SHORT  ("%abil_off%" + 0x1e + ("%index5%" * 0x38)) "abil_fx_num"
  READ_SHORT  ("%abil_off%" + 0x20 + ("%index5%" * 0x38)) "abil_fx_idx"
    WRITE_SHORT ("%abil_off%" + 0x18) 1                                         // adjust dice rolls (1d6)
    WRITE_BYTE  ("%abil_off%" + 0x26) 1                                         // allow strength bonus
    PATCH_FOR_EACH ~resref~ IN ~die~ ~mesdie~ ~ax1h10b~ BEGIN 
     INSERT_BYTES ("%fx_off%" +        ("%abil_fx_idx%" * 0x30))      0x30      // new effect
     WRITE_SHORT  ("%fx_off%" +        ("%abil_fx_idx%" * 0x30))       177      // use eff
     WRITE_BYTE   ("%fx_off%" + 0x02 + ("%abil_fx_idx%" * 0x30))         2      // target: preset target
     WRITE_LONG   ("%fx_off%" + 0x04 + ("%abil_fx_idx%" * 0x30))         4      // param1
     WRITE_LONG   ("%fx_off%" + 0x08 + ("%abil_fx_idx%" * 0x30))         3      // param2
     WRITE_BYTE   ("%fx_off%" + 0x0c + ("%abil_fx_idx%" * 0x30))         1      // timing
     WRITE_BYTE   ("%fx_off%" + 0x12 + ("%abil_fx_idx%" * 0x30))       100      // probability
     WRITE_ASCIIE ("%fx_off%" + 0x14 + ("%abil_fx_idx%" * 0x30)) ~%resref%~ #8  // resref
     SET %abil_fx_num% += 1                                                     // number of ability effects
    END
  WRITE_SHORT (%abil_off% + %index5% * 0x38 + 0x1e) %abil_fx_num%               // update the number of ability effects
  END
END
BUT_ONLY_IF_IT_CHANGES

Edited by aVENGER_(RR), 18 January 2012 - 04:55 PM.

[devSin]

As long as it works with an already fixed (e.g., Baldurdash) copy of the item. IIRC, that was the reason for copying the resource instead of patching, way back when.

Quote

SET %abil_fx_num% += 1

Really? :-)

Edited by devSin, 18 January 2012 - 02:26 PM.

[aVENGER_(RR)]

 devSin, on 18 January 2012 - 02:26 PM, said:

As long as it works with an already fixed (e.g., Baldurdash) copy of the item. IIRC, that was the reason for copying the resource instead of patching, way back when.

I don't think it will, at least not properly. But doesn't the readme specifically warn the users not to install the fixpack on top of Baldurdash?

Quote

Quote

SET %abil_fx_num% += 1

Really? :-)

I borrowed that from Nythrun, along with most of the other code bits. Is it misplaced? For what it's worth, I've tested the Azuredge patched with this and it checks out via DLTCEP and works fine in game.

Edited by aVENGER_(RR), 18 January 2012 - 02:39 PM.

[Dakk]

 aVENGER_(RR), on 18 January 2012 - 02:38 PM, said:

 devSin, on 18 January 2012 - 02:26 PM, said:

As long as it works with an already fixed (e.g., Baldurdash) copy of the item. IIRC, that was the reason for copying the resource instead of patching, way back when.

I don't think it will, at least not properly. But doesn't the readme specifically warn the users not to install the fixpack on top of Baldurdash?

BG2 Fixpack Readme:
"In terms of installation order, the Fixpack should be installed after the official patches, but before other mods. Do not install the Fixpack alongside other fixpacks such as Baldurdash."

and
"Baldurdash or any other previous fixpack
We used the bug lists from previous efforts to fix bugs as a starting point. If the bugs aren't already fixed by the Fixpack they will be in future versions. Installing Baldurdash alongside Fixpack will result in a lot of issues."

So, yes. And quite strongly so.

Edited by Dakk, 18 January 2012 - 02:49 PM.

[devSin]

 aVENGER_(RR), on 18 January 2012 - 02:38 PM, said:

I don't think it will, at least not properly. But doesn't the readme specifically warn the users not to install the fixpack on top of Baldurdash?

The read me encourages all sorts of responsible behavior, I'm sure.

But there's a difference between advocating responsible behavior and expecting responsible behavior, and Cam clearly favored one over the other when he decided to do a resource copy (and we hated resource copies, even back then). Knowing Cam, it was all about us doing the right thing and not simply looking the other way unless the player does the right thing. ;-)

 aVENGER_(RR), on 18 January 2012 - 02:38 PM, said:

I borrowed that from Nythrun, along with most of the other code bits. Is it misplaced? For what it's worth, I've tested the Azuredge patched with this and it checks out via DLTCEP and works fine in game.

Maybe I'm old and stupid now, but isn't that SET (variable named the value of "var") += 1? If abil_fx_num is 4, then the code is SET "4" += 1.

Edited by devSin, 18 January 2012 - 03:06 PM.

[aVENGER_(RR)]

 devSin, on 18 January 2012 - 03:04 PM, said:

Knowing Cam, it was all about us doing the right thing and not simply looking the other way unless the player does the right thing. ;-)

We can revert this to copy-style behavior in no time if that's preferred. But for some reason, I don't think Azuredge would be the only problem for the people who install the fixpack over Baldurdash. If possible, it might be better code in some sort of check for Baldurdash and have the fixpack halt the installation.

Quote

isn't that SET (variable named the value of "var") += 1? If abil_fx_num is 4, then the code is SET "4" += 1.

Good point, but since we nuked all the effects in the previous block it won't make a mess. Still, I should probably revise it.

Edited by aVENGER_(RR), 18 January 2012 - 03:34 PM.

[Wisp]

 devSin, on 18 January 2012 - 03:04 PM, said:

 aVENGER_(RR), on 18 January 2012 - 02:38 PM, said:

I don't think it will, at least not properly. But doesn't the readme specifically warn the users not to install the fixpack on top of Baldurdash?

The read me encourages all sorts of responsible behavior, I'm sure.

But there's a difference between advocating responsible behavior and expecting responsible behavior, and Cam clearly favored one over the other when he decided to do a resource copy (and we hated resource copies, even back then). Knowing Cam, it was all about us doing the right thing and not simply looking the other way unless the player does the right thing. ;-)

It has been a while but I am fairly sure the code I wrote was properly able to handle things like BD. Given some time (and ideally a working BG2 installation) I can have another look at it (unless I am beaten to it, please beat me to it, etc.).

[Ardanis]

So the final decision is to not add enchantment bonus to damage/thaco, right? Cool, within IR's local fixpack I've considered them a bug too.

[Hurricane]

Yes, this is the final outcome - no thac0/damage bonus from the enchantment. The inconsistency you originally reported (regarding the new description) should be resolved by this.