Comment author: @bob-the-hamster

see also related bug bz#16 (#1029) for situations when adding to 32767 results in a
negative number (this killing an enemy by curing it)

Comment author: @bob-the-hamster

Created attachment 25
test case

Cleaning out my ancient e-mail, I found this:

On Tue, Aug 26, 2003 at 02:59:02PM +0000, Sean Sheeley wrote:

I don't know if it's still true or not, but in the buglist it said that
you need a test-case for the math overflow error in the battle system. So,

I created one. I creates the error every time (~50 tests). I hope this
helps you work out some of those bugs.

Sean

PS I appologise for the lack a title screen or battle sprites, but I
didn't think they were necessary. I almost didn't put in walk-about
sprites.

This may not be the only math overflow. I believe there to be multiple
potential overflows, but this testcase should help eliminate at least one.

Attached file: OVERTEST.zip (application/zip, 4844 bytes)
Description: test case

Comment author: @arperry

http://www.cp-games.org/images/dderror.png

In Darkmoor Dungeon, there is an enemy who counters attacks by raising his
defense by 50%. The exponential growth causes a quick overflow. This enemy
occurs in the second battle of the game, making Darkmoor Dungeon a good test
case for this bug. Two players have notified me of this bug.

Defense and Magic Defense can't be set past 999 in the editor, so it is odd that
they are allowed to pass that limit in-game. I seem to remember Counter not
being able to pass 100 (its maximum inside the editor).

Comment author: @pkmnfrk

(I had forgotten about this bug.)

Right, the defense would get so large that it eventually goes negative, screwing
the damage formulas up (I assume that shit happens when the next person attacks
the enemy?)

Comment author: @arperry

No, I believe the overflow error occurs when the defense exceeds 32,767 and not
just when the enemy is attacked afterward. At least, that's what the two error
reports indicate.

Comment author: @pkmnfrk

Either way, I added a few things to curb this bug.

A) I cap damage at 32767 (mainly for 32-Bit OHR, which uses a larger unsigned
Integer, meaning that stats can get very very high, and then wrap back around to
0 :)

A.5) There's also a new 9999 Damage Cap bitset, although James wants to make it
customizable. I agree, and am working on that right now. Also, I made it so that
if the "Show damage without inflicting" bitset is on, the damage is *not* capped.

B) I changed percentage based attacks to use the standard inflicting routines,
so they are also subject to the damage cap, and cannot cause a stat to overflow.

I've tested it (albeit with my own test case), and it seems to work fine.

Comment author: @pkmnfrk

*** Bug bz#16 (#1029) has been marked as a duplicate of this bug. ***

Comment author: @bob-the-hamster

Did you test with Sean Sheeley's attached testcase also?

Comment author: @pkmnfrk

No, but I'll do so now.

Comment author: @pkmnfrk

Oh bother. That should not be happening ("Duh!").

I checked with 32-bit game, and the damage being dealt is +326760.

*sigh*

Well, I did fix half of it, the part plaguing Darkmoor.

Comment author: @bob-the-hamster

I think the case where this bug is still occuring is when various multipliers
cause the damage to go over 32767

For example, suppose your hero has strength of 1000, and does an attack on an
enemy with no defense

The attack has Extra Damage=500, making his damage 5000

The attack's elements are Fire, Water, Earth, Wind, and Pizza, and the target is
weak to all of them, so the damage is doubled five times. 5000*2*2*2*2*2 = 160000

So now the damage is way over the limit. The same can happen with enemy-type
weaknessess too.

So I think we need a safemultiply() function similar to the safesubtract()
command which converts the operands to long ints, multiplies them, then crops
the answer if it is over short int limits, and returns the result as a short
int. Then we can use that in any place where damage is multiplied.

There might be some other cases too, like suppose an attack does exactly 32767
damage, but then it gets randomized, so the result is 32914 or something.

Comment author: @pkmnfrk

Funny that you mention it, because I just added a safemultiply :)

I made the second parameter a double, since more often than not, we're
multiplying decimals.

I got it to stop crashing, but it's A) still healing, and B) it gives a segment
fault when you exit.

Comment author: @pkmnfrk

I've kinda run into a bit of a problem. I changed the percentage-based-attack
damage lines to use safe multiply and subtract, but now the damage is 0!

atk(11) is 1000:

h = safesubtract(, safesubtract(, -(safemultiply(atk(11),
/ 100))))
h = safesubtract(32767, safesubtract(32767, -(safemultiply(1000, 327.67 / 100))))
h = safesubtract(32767, safesubtract(32767, -(safemultiply(1000, 327.67))))
h = safesubtract(32767, safesubtract(32767, -(32767))) ' safesubtract(x,-y) =
safeadd(x,y)
h = safesubtract(32767, 32767)
h = 0

As you can see, this is a result of truncating it every time...

What if we just use Longs instead, and round at the end?

Comment author: @pkmnfrk

Now, had I actually looked that the attack settings in this case, I would have
learned that it's *supposed* to heal the monster. <_<

Anyway, I converted the battle routine to use a long, right up until it actually
inflicts the damage, at which point it rounds (and caps as per my bitset), and
uses safesubtract to change the stat.

Only problem is that I'm still getting that seg... eh? It stopped happening when
I removed the debug lines... oh well. Comitting now.