Game Mechanics: Stats/Resists apparently not capped serverside

[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]

Originally Posted by Daldaen [You must be logged in to view images. Log in or Register.]

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]

Originally Posted by Technique [You must be logged in to view images. Log in or Register.]

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]

Originally Posted by Technique

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.