[Imbuing] Probem with Mana & Life Leech Intensities

[Zolaf]

Background Knowledge:
The Maximum Value for Mana/Life leech I have determined via an email with Mesanna. The new equation (which uoguide is wrong) is as follows:

Melee Max = min(100, max (31, 6.25*trunc(400 Base speed / (100 + SSI%)))
Ranged Max = trunc(0.5 Melee Max)

Question:
Normally on intensity calculation the equations follow a pattern:
Rounddown(Max Intensity * Imbued / Max Value , 0) or rounddown(110 * x / Melee Max or Ranged Max , 0)

This is not entirely the case for mana/life leech.

Answer: Thanks Basara!
The imbued values and the maximum imbueable intensity are truncated. You get a maximum of 25 "clicks" (options) in the imbue menu. So for a wep with a maximum of 68 mana leech (shown in menu) u actually have the following:

1 click = 1 * 68.75 / 25 = 2.72 (adds 2% to wep), rounddown (2.72 / 68.75 * 110 , 0) = 4 intensity
2 clicks = 2 * 68.75 / 25 = 5.44 (adds 5% to wep), rounddown (5.44 / 68.75 * 110 , 0) = 8 intensity
3 clicks ...
25 clicks = 25 * 68.75 / 25 = 68.75 (adds 68% to wep), rounddow (68.75 / 68.75 * 110 , 0) = 110 intensity

Possible UO Error: Example
Lets take a Melee Wep with a base speed of 3.25s.

Senario 1: Imbue 20SSI then 35 mana leech - Intensity = 134
Senario 2: Imbue 35 mana leech then 20SSI - Intensity = 121
Senario 3: Imbue 35 mana leech, 20SSI, then 35 mana leech again - intensity = 134

It appears there is an "error" in the coding of UO where the intensity of mana/life leech is only updated when you imbue it. So, in effect, if you wanted to have a higher mana/life leech value you only need imbue that mod first and then add the SSI second.

Having said that, inputting this into a spreadsheet (for my imbue calculator) is not possible. Instead, I put the most conservative option (Imbue SSI then Mana Leech).

 

[Basara]

It may be a rounding error. Luckily, having once been a computing student (I had hopes of becoming a CS/math teacher before health intervened), I can spot possible pitfalls in these.

Remember that, in many cases, the amounts aren't actually hit by "trunc"/"rounddown" functions until the very last step.

In other cases, you can be dealing with values that are already derived, and subject to a trunc or rounddown, that get hit a second time in the final equation to make the number go off.

An example in real life was a friend of mine that was working for the State of Tennessee, writing new code, county by county (starting with the larger ones), for proper division of tax & state/federal money between schools in the district, based on enrollment. In the process he found out that the previous standard rounded off numbers in 4 different places, before itself being rounded at the end. As a result, every year, nearly every district would be wondering either "where did this extra money come from that wasn't allotted?" or "How did we overspend when every school was at or under budget?" Given the size of the school districts, even a 0.1% error introduced by rounding was causing errors in EVERY school's allotment in the 4-5 digit range. (thousands to tens of thousands). In some cases, the difference was the equivalent of 2-3 teachers' salaries (plus or minus, and not the same from year to year could be a surplus 1 year, a deficit the next). He ended up writing the code out to where all the values were kept as-is until the final value was rounded - which took him a month to explain WHY it was preferable and better math - to math teachers, no less.

If you don't want to put the math in "Ask the Devs", you can always send it to them directly using the email link on the UO.com web page, and make it ATTN programming staff.

 

[Zolaf]

Further Information:

Here is the Email I received from Mesanna a year or so ago that shows how the maximum mana leech and life leech is calculated. I left this to keep it alive:

The differences are likely due to one or more of these:​

1> The intensity of the leech item properties is stored as an integer, and 25 is the max imbuable value. When displaying the item property information, the proc chance is calculated on the fly.
2> There is an intermediate calculation that does some interesting things with data type conversions and may cause discrepancy:
a. The “speed” of the weapon is its swing period in integer units of 1/4th of a second. E.g. if a weapon’s swing rate is 2.0s, its speed is 8.
b. We take that base speed and divide it by (1 + SSI%). With 30% SSI we divide by 1.3. The result is truncated back to an int value
i. E.g. 8 / 1.3 = 6.15, and is truncated to 6.
c. The speed value has a floor of 5 (no weapon can ever swing more often than once every 1.25 seconds…)
3> The proc chance is calculates as speed / 4 * intensity (using floating-point math, then truncated back to an integer). This value is capped at 100%
4> The halving for ranged weapons happens last, and also results in integer truncation.

So, running your example through:

Base speed of 4.5s means speed value is 18. With 45% SSI, speed is divided by 1.45. The result of 18 / 1.45 = 12.4. This is truncated to 12.

Max imbuable intensity for leeches is 25. So, 12 / 4 * 25 = 75 (for melee weapon).
Halving that for a ranged weapon gives 37.5, truncated to 37.