Encumbered AGI Penalty

[AndMetal]

I've been working on correcting the AGI calculation (Client::CalcAGI()) for when a client is encumbered:

        sint16 str = GetSTR()*10;
        if(weight > str) {
                //ratio is wrong (close), but better than nothing
                val -= (weight-str) * 100 / 1500;       //WR said /1875
        }

And was able to calculate using the Titanium client that on an Iksar Monk (any level) with a base Str of 75 & base Agi of 120 it should be this:

val -= ((weight - str) * 100 / 1250) + 1;	//since we're using ints, we're depending on this being rounded down (floor'd) automatically

However, once I put 5 points into Innate Strength (verified no other AAs trained), the calculation was off: at 90/85 weight (so 5 over), the client was showing 116 AGI & the server was showing 115 AGI using the new calculation.

I've been meaning to find out how the (linear) slope has changed (from -0.8), but it's a pretty time consuming process to add 40 pp (which equals 1 weight) & record the results dozens of times.

I guess I wanted to see if someone (with more free time than I do) would be willing to help me calculate this out.

EDIT: After a quick calculation, 10 STR from AA changed the slope to -0.71428571428571. On average, 1 STR contributes -0.010666666666667 to the slope, but 1 STR from AA appears to only contribute -0.008571428571429.

[ChaosSlayerZ]

speaking of WEIGHT
do stacked items still do not add up their weight to total? (stack of 20 pelts with 3.5 per pelt, weight 3.5 regardless if you have 1, 5, 15 or 20)

[AndMetal]

Originally Posted by ChaosSlayerZ

speaking of WEIGHT
do stacked items still do not add up their weight to total? (stack of 20 pelts with 3.5 per pelt, weight 3.5 regardless if you have 1, 5, 15 or 20)

That's because it's how the client (at least Titanium) calculates it.

[ChaosSlayerZ]

Originally Posted by AndMetal

That's because it's how the client (at least Titanium) calculates it.

umm but its wrong...
I mean on LIVE since day one the weight from stacked items was added up, didn't it?

[AndMetal]

As far as I know, no. But a lot of stuff, like Pelts, didn't used to be stackable. This was always a pain for me because I would hold on to them because I had several GM Tailors in my guild that needed pelts. They were changed to be stackable on the 7/24/2001 patch, which helped a TON with weight:

.....................................................................

------------------------------
July 24, 2001  3:00 am
------------------------------

** Item Changes **

- Silver Chitin Hand Wraps' haste effect has been repaired.
- The Smite scroll no longer lists Enchanters as a class that can use 
it.
- The Augment Death scroll no longer lists Shadowknights as a class 
that can use it.
- Many pelts have been made stackable. Those that are not stackable now 
are quest items that will not be made stackable.

[trevius]

Originally Posted by ChaosSlayerZ

umm but its wrong...
I mean on LIVE since day one the weight from stacked items was added up, didn't it?

Even if items did add up individual weight from each item in a stack on Live, they don't in our clients. And, since there is no way to update the weight of the client, there is no reason to bother debating it. Though, I am 99% sure that stacks never added weight individually for each item in a stack. I had 220+ in almost all tradeskills on Live, so I have dealt with my fair share of stacks :P

And yes, AndMetal, I remember that patch as well. It was awesome when they finally did that.

Not to get too far off-topic, but something I mentioned to AndMetal really points out just how much the client controls weight; Coin Purses. This is probably one of the oddest finds I have seen so far when dealing with items. Coin purses reduce weight of coin on a player by the amount that is shown on the weight reduction of the bag. But, the tricky thing about coin purses is how they work. At first I tried to copy some in the items table, but those didn't work at all. Then, I thought maybe they needed "Coin Purse" in the name, but that wasn't it either. Then, I tried moving the coin purses I had made into the same range with all other coin purses in the database, between 17201 and 17230 item ID, and that worked... Partially. It turns out that coin weight reducing items are hard coded on a per Item ID basis in the client! So, each item ID from 17201 and 17230 has a pre-defined coin weight reduction amount set on it in the client code. I mentioned this in the wiki here under the BagWR field note when I figured it out:
http://www.eqemulator.net/wiki/wikka...uDBSchemaitems

The reason I bring up coin purses is because if you are coding to handle weight as close as possible to match the client, we will need to hard set each of these item IDs to reduce coin weight by the correct amount. Many of these IDs already have coin purses set for them and you can find them all by doing a "#fi coin purse". Once you have the list, you just need to check the WR setting on each bag there, and we can have at least those particular ones handled properly. For the rest of them, we would need to create items using the rest of the IDs and then test to see how much coin weight each one reduces by.

Coin purses aren't used often, but they are pretty cool. This isn't a high priority or anything, but I figured it was worth mentioning somewhere so people would know!

[AndMetal]

Just an update, I've been working on this some more, and I think I've got it figured out. Basically, every time we double our weight, our AGI is cut in half. That also means that when we triple our weight, that puts us at 0. Here's the rough equation:

//linear equation: y = m * x + b
//m = (-(val + mod)) / (GetSTR() * 2)
//x = (weight / 10) - GetSTR()
//b = val + mod
sint16 str = GetSTR();
sint16 total_agi = val + mod;
AGI = ((-total_agi) / (str * 2)) * ((weight / 10) - str) + total_agi;

[AndMetal]

Just finished testing this out. Here's a diff of the changes:

Index: Y:/svn/trunk/EQEmuServer/zone/client_mods.cpp
===================================================================
--- Y:/svn/trunk/EQEmuServer/zone/client_mods.cpp	(revision 780)
+++ Y:/svn/trunk/EQEmuServer/zone/client_mods.cpp	(working copy)
@@ -979,19 +979,22 @@
 
 sint16 Client::CalcAGI() {
 	sint16 val = m_pp.AGI + itembonuses.AGI + spellbonuses.AGI;
-	
 	sint16 mod = aabonuses.AGI;
-	
-	sint16 str = GetSTR()*10;
-	if(weight > str) {
-		//ratio is wrong (close), but better than nothing
-		val -= (weight-str) * 100 / 1500;	//WR said /1875
-	}
-	
+
 	if(val>255 && GetLevel() <= 60)
 		val = 255;
-	AGI = val + mod;
+
+	sint16 str = GetSTR();
 	
+	//Encumbered penalty
+	if(weight > (str * 10)) {
+		//AGI is halved when we double our weight, zeroed (defaults to 1) when we triple it. this includes AGI from AAs
+		float total_agi = float(val + mod);
+		float str_float = float(str);
+		AGI = (sint16)(((-total_agi) / (str_float * 2)) * (((float)weight / 10) - str_float) + total_agi);	//casting to an int assumes this will be floor'd. without using floats & casting to sint16, the calculation doesn't work right
+	} else
+		AGI = val + mod;
+
 	if(AGI < 1)
 		AGI = 1;

I'm real out of date to SVN, so it may be a little while before I can get this committed, but if someone else wants to update it for me, feel free.

[Congdar]

I was wondering about your testing... your initial post mentioned you used a monk. Since monks have an innate weight penalty at anything more than 20 at level 65(PoP timeframe) i'm wondering if you took that into consideration or not. Maybe it would be better tested with a warrior?

[AndMetal]

Originally Posted by Congdar

I was wondering about your testing... your initial post mentioned you used a monk. Since monks have an innate weight penalty at anything more than 20 at level 65(PoP timeframe) i'm wondering if you took that into consideration or not. Maybe it would be better tested with a warrior?

Monks have an AC penalty based on their weight, but it shouldn't affect the actual Agility.

Just to make sure, I created an Ogre Warrior (level 1) with 150 base STR & 75 base AGI and the server is matching up with the client.