Stats/Resists apparently not capped serverside

[Technique]

It's possible to buff them above 255 or debuff them below 1, despite what the client displays.

At a glance this doesn't alter derived attributes such as HP or mana, but it does affect debuffs, as amounts are being subtracted from the actual stat value rather than the capped value, and I'd imagine it also affects any other calculation that doesn't impose a cap on stat inputs.

[Jaxon]

That sounds like it's working as intended. Addition and subtraction are commutative.

[Technique]

Addition and subtraction are commutative.
News flash, Euclid: subtraction is noncommutative.

If one of the most basic laws of math is beyond your comprehension, then it's no surprise you don't understand the bug report either.

[Daldaen]

So if my Magic Resist totals 315, and I get hit by Malosini, it still will show and function as 255, because 315-60 is 255?

[kaev]

Subtraction is a mirage concocted to confuse the gullible. Just add negative numbers as and when necessary, throw in the occasional multiply by (-1) where you need it, and keep your parenthesis sorted, you'll be commutative all the way home and forever free of operator precedence..

[Erati]

Pretty sure that resists are not suppose to exceed 255 and what should happen in Dald's example is your Magic Resist would be 195.

you are saying it currently adds it all up beyond 255 - the question is whether those numbers are figuring in to the resist calculations or if this is simply screwing up debuff type calculations

[Daldaen]

Eh I tend to think that the situation I listed is functioning as it should.

You're capping at 255, but in actuality you have 315 MR, the debuffs should remove from your actual not from the hard cap. I'm *pretty* sure that's how it works on live but I could check.

[Jaxon]

Oops you're right.

Anyway what I was getting at is debuffs lower your resist stats, they don't lower your resist cap.

[Raev]

It's possible to buff them above 255 or debuff them below 1, despite what the client displays.

At a glance this doesn't alter derived attributes such as HP or mana, but it does affect debuffs, as amounts are being subtracted from the actual stat value rather than the capped value, and I'd imagine it also affects any other calculation that doesn't impose a cap on stat inputs.

how did you decide this?

[Technique]

I undertook the incredibly novel task of buffing particular stats/resists with spells of known value and then debuffing the same stats/resists with spells of known value and observed the results. Rocket surgery, I know.

[Daldaen]

But I believe that's how it should work.

If you're a bard sitting on 400 MR, a Tash/Malo shouldn't drop you under 255. It should just take away from your real MR value and whatever that value is, is your MR... Unless it's still above 255, in which case it just caps at 255.

Think of debuffs like taking off pieces of gear with stats. Removing a Tranix Crown when you're at 275 MR total won't change your 255 at all.

If you believe it should function beyond this I would be interested to see some evidence.

[Technique]

But I believe that's how it should work.If the classic server implementation used only a byte to store stat/resist values, then it obviously shouldn't work like that.

I don't recall if this was determined in the resist discussions of last year, but if we're not assuming this then why were resists capped at 255 in the first place?

[kaev]

If the classic server implementation used only a byte to store stat/resist values, then it obviously shouldn't work like that.

I don't recall if this was determined in the resist discussions of last year, but if we're not assuming this then why were resists capped at 255 in the first place?

Using one byte for current working value doesn't preclude 16-bit math for calc/recalc. Pretty sure Verant devs had some problems with this sort of thing, there was some pretty wonky shit happened back in the day depending on what order you did stuff. For an unrelated but relevant example of Verant devs not understanding how their own code worked, I remember reading about FoH stacking multiple instances of same Mage DS on Velious tanks by dicking around with buff order and bardsongs.

IOW, without commentary from back in the day there's no way for us to know at what point(s) in the calc/recalc the cap was applied back then.

[Raev]

If the classic server implementation used only a byte to store stat/resist values, then it obviously shouldn't work like that.

I had to think about this a bit, but I'm fairly sure this is incorrect. Which is why you shouldn't be quite so snippy about being asked to present 'obvious' evidence.

You seem to be mentally implementing this as a running counter: resistMagic = (char)min(255, max(0, (int)resistMagic + buffValue)). Unfortunately this won't work. Imagine we start with a character of max resists and cast GRM which is then dispelled:

Initial value: 255
With GRM: 255+55 -> 255
GRM fades: 255 - 55 -> 200 (!!)


So either the resist magic value was computed from scratch every time a new buff was applied (and this would for sure have been using 32 bit math (not 16 bit kaev you nut) to avoid overflow) and then clamped to an 8 bit range to save memory or the value was stored as a 16 bit integer internally and clamped to 255 for game balance reasons.

TLDR: Daldaen's interpretation seems the most reasonable to me, and it's probably not an accident that P1999's implementation matches this.