Enchantress' Attributes Guide (Table Format)

This is a guide on how the Enchantresses' primary attributes affect their secondary attributes

First of, a few notes before reading... PLEASE READ!

Primary Attributes:
Strength (STR), Dexterity (DEX), and Intelligence (INT)

Secondary Attributes
Hit, Critical, Dodge, Health, HP regen (HP/s), Mana, Mana regen (MP/s), Damage, DPS, and Armor

This was only done with the Enchantress... though I think the data will differ when compared with the other two classes.

This was done mostly in a secluded location in Glumdoll Cemtery where I would be free of buffs so as not to affect the data.

This was done stripped of any equipment and as a level 50.

The Dodge for the INT attribute was done upto INT 291 just to calculate the increment per point of INT on the Dodge attribute.

I started collecting the data during Pocket Legend's version 1.6 (53249) and rechecked every patch update until version 1.6 (53797)...
But please do inform me if there are any errors to my data
--------------------------------------------------------------------------------------------------------
Errors, Mistakes, Unfinished Work...

Sad to say but I cannot figure out the exact increment for some of the attributes so there will be a notice there says "(Still don't know)"

Some of the base numbers for the secondary attributes may be off by 0.01 but I made sure that the numbers were pretty close to each other...

and now I present you... my guide... Enchantress' Attributes Guide

Thanks for putting these numbers together!

Mana = (INT / 2) + 600 or .05 Mana per point on INT. It is not always exact as it is rounded to the nearest integer.

M/s = (INT + 39) / 50

Haven't looked at the others but are you including the possibility of the values being seeded like M/s?

Your welcome!

Now for your formulas... I've used that formula before but rejected it as I see too many inconsistencies with the data I gathered.

With the mana pool formula, if you apply the rule of rounding up to the nearest integer... The results will not match the data in the table...
For example, if you're going to use INT 30, the result would be exactly 615 which matches. When INT 31 is used, the result would be 615.5. If you apply the rule of rounding up, it matches. Now if you use INT 33, the result would be 616.5. If you apply the same rule, the result will not match the data.

With MP/s formula, still the same inconsistencies apply...
If you use INT 10, the result would be 0.98 which would match with the data if not rounded up...
If you use INT 11, the result would be 1 which would match with the data...
If you use INT 60, the result would be 1.98 which would not match with the data but if rounded up, it will...

Now tell me about the word seeded... Not familiar with it...
Oh and thank you for taking an interest in the table's missing formulas...

Quote:

---

Originally Posted by Eleanor

Your welcome!

Now for your formulas... I've used that formula before but rejected it as I see too many inconsistencies with the data I gathered.

With the mana pool formula, if you apply the rule of rounding up to the nearest integer... The results will not match the data in the table...
For example, if you're going to use INT 30, the result would be exactly 615 which matches. When INT 31 is used, the result would be 615.5. If you apply the rule of rounding up, it matches. Now if you use INT 33, the result would be 616.5. If you apply the same rule, the result will not match the data.

---

Once again you have my thanks, I noticed that it was not perfect however, I just figured it was a flaw in the game. It ends up being a little more interesting than that. I calculated all of the numbers that wouldn't match the data you collected and it turned out to be every other odd number of INT: 9, 13, 17, 21, 25, 29, 33, 37, 41, 45, 49, 53, 57, 61, 65, 69, 73, 77, 81, 85, 89, 93, 97, 101, 105, 109, 113, 117, 121, 125, 129, 133, 137, 141, 145, 149, 153, 157, 161, 165, 169, 173, 177, 181, 185, 189, 193, 197, 201, 205, 209, 213, 217, 221, 225, 229, 233, 237, 241, 245, 249. I don't know if that can be written in a single formula.

Quote:

---

Originally Posted by Eleanor

With MP/s formula, still the same inconsistencies apply...
If you use INT 10, the result would be 0.98 which would match with the data if not rounded up...
If you use INT 11, the result would be 1 which would match with the data...
If you use INT 60, the result would be 1.98 which would not match with the data but if rounded up, it will...

---

This one is more strange as 60 is the only number that would not calculate correctly. I think it may be an error in the programming language they are using.

Quote:

---

Originally Posted by Eleanor

Now tell me about the word seeded... Not familiar with it...

---

What I mean by seeded is that in the case of M/s it increases the first time at 11, but then after each 50(except at 60) for subsequent increments. Therefore I assumed the value used to increment M/s started(or was seeded) at 39, not 0. The reasoning, i think, is that they did not want you to have to wait till you had 50 INT to gain the first M/s, so each point of INT increments a value and that value determines M/s. Otherwise if we assume the value to increment M/s starts at 0 it is impossible(?) to fit the data into an equation.

Quote:

---

Originally Posted by Apraxhren

Once again you have my thanks, I noticed that it was not perfect however, I just figured it was a flaw in the game. It ends up being a little more interesting than that. I calculated all of the numbers that wouldn't match the data you collected and it turned out to be every other odd number of INT: 9, 13, 17, 21, 25, 29, 33, 37, 41, 45, 49, 53, 57, 61, 65, 69, 73, 77, 81, 85, 89, 93, 97, 101, 105, 109, 113, 117, 121, 125, 129, 133, 137, 141, 145, 149, 153, 157, 161, 165, 169, 173, 177, 181, 185, 189, 193, 197, 201, 205, 209, 213, 217, 221, 225, 229, 233, 237, 241, 245, 249. I don't know if that can be written in a single formula.

---

Unfortunately, a formula is absolute and it must agree with every possible data... It is rather strange though interesting... Haha!

Quote:

---

Originally Posted by Apraxhren

This one is more strange as 60 is the only number that would not calculate correctly. I think it may be an error in the programming language they are using.

---

I think so too... Although it would be easier to blame it on an error, I still would like to do further research into it... Maybe I need a bit more INT to test it out to see if there is a pattern to it just like I did with Dodge...

BTW, It's weird that INT plays a part in increasing Dodge... Haha!

Quote:

---

Originally Posted by Apraxhren

What I mean by seeded is that in the case of M/s it increases the first time at 11, but then after each 50(except at 60) for subsequent increments. Therefore I assumed the value used to increment M/s started(or was seeded) at 39, not 0. The reasoning, i think, is that they did not want you to have to wait till you had 50 INT to gain the first M/s, so each point of INT increments a value and that value determines M/s. Otherwise if we assume the value to increment M/s starts at 0 it is impossible(?) to fit the data into an equation.

---

Ahhh so that's what seeded means... Haha! Well at first I did, but as you can see, there's an inconsistency to that idea if applied in MP/s...

There are others however that the attributes are seeded... Like Dex and Hit...

Quote:

---

Originally Posted by Eleanor

I think so too... Although it would be easier to blame it on an error, I still would like to do further research into it... Maybe I need a bit more INT to test it out to see if there is a pattern to it just like I did with Dodge...

---

I agree, I want to figure this out also. The next time M/s should increase based on my formula is at 261, but ingame it changes at 260. :( (60 again?) After that it should again increase around 311 but the max INT you can get with the current gear is 300 and it is still 6 at 300 INT.

Going to play around with this some more today, I have an idea that may explain the problem with my MANA formula.

Double post but oh well, I THINK I may have figured out how the weird results for MANA are happening but why it is happening is still a mystery to me. It appears to be the result of a loss of precision, somewhere they are removing the decimal. I can recreate this with the following code in C++, which is what I believe the server software is coded in based on job openings they have posted:

Code:

---

#include <iostream>
#include <iomanip>
int main()
{
        using namespace std;
        int expected [] = {604,604,604,605,606,606,606,607,608,608,608,609,610,610,610,611,612,612,612,613,614,614,614,615,616,616,616,617,618,618,618,619,620,620,620,621,622,622,622,623,624,624,624,625,626,626,626,627,628,628,628,629,630,630,630,631,632,632,632,633,634,634,634,635,636,636,636,637,638,638,638,639,640,640,640,641,642,642,642,643,644,644,644,645,646,646,646,647,648,648,648,649,650,650,650,651,652,652,652,653,654,654,654,655,656,656,656,657,658,658,658,659,660,660,660,661,662,662,662,663,664,664,664,665,666,666,666,667,668,668,668,669,670,670,670,671,672,672,672,673,674,674,674,675,676,676,676,677,678,678,678,679,680,680,680,681,682,682,682,683,684,684,684,685,686,686,686,687,688,688,688,689,690,690,690,691,692,692,692,693,694,694,694,695,696,696,696,697,698,698,698,699,700,700,700,701,702,702,702,703,704,704,704,705,706,706,706,707,708,708,708,709,710,710,710,711,712,712,712,713,714,714,714,715,716,716,716,717,718,718,718,719,720,720,720,721,722,722,722,723,724,724,724,725,726,726 };
        for(int i=7;i<252;i++) {
                float mana = (i/2.0)+600;
                cout << setprecision(3) << "For INT = " << i << ", Mana is " << mana << ", Expected value is " << expected[(i-7)] << ", Actual value is " << setprecision(4) << mana << endl;
        }
}

---

and an image of the first 31 outputs where Mana is the calculated result, Expected is your data, and Actual is the same calculated result without limiting the precision. http://thoreau.frapteh.com/code.png

The thing I don't understand is setprecision() should truncate the number instead of rounding some. :confused:

Wow this is quite amazing you guys!

Quote:

---

Originally Posted by Apraxhren

The thing I don't understand is setprecision() should truncate the number instead of rounding some. :confused:

---

Well I don't know much about that but if you can get the approximate like what I did with the other attributes, why not?!

Quote:

---

Originally Posted by JackDonkey

Wow this is quite amazing you guys!

---

Thank you! You made me prouder of my work! Haha!

The curious case of mana can now be closed. I just read about a different type of rounding that is used in various programing languages(including C++) call Bankers rounding, or Round half to even. It is actually pretty common as it removes the typical upward bias that rounding all .5's up will have. This perfectly describes what is happening and is either an consequence due to the language implementation or the Developers intentional method of rounding. It is pretty much described in the name but using previous examples of INT = 31 we end up with 615.5 since 615 is odd it will round up to 616, whereas INT = 33 we have 616.5 it will round down. I am embarrassed that something so simple escaped my notice, but at least I have learned something.

As for the M/s problem, I have gotten nowhere. It does not seem to fit into a precision and/or rounding issue and I have even tried to find an alternative formula to no avail.

Never heard it called "Banker's rounding". Frankly, I'd expect bankers to round in their own favor each time, rather than even things out.

Statisticians, on the other hand, routinely round .5 to the even number so that rounding errors are more likely to cancel out in the long run.

Quote:

---

Originally Posted by Duke

Never heard it called "Banker's rounding". Frankly, I'd expect bankers to round in their own favor each time, rather than even things out.

---

To quote the Wikipedia article on rounding:

Quote:

---

Originally Posted by http://en.wikipedia.org/wiki/Rounding#History

The origin of the term bankers' rounding remains more obscure. If this rounding method was ever a standard in banking, the evidence has proved extremely difficult to find. To the contrary, section 2 of the European Commission report The Introduction of the Euro and the Rounding of Currency Amounts [12] suggests that there had previously been no standard approach to rounding in banking; and it specifies that "half-way" amounts should be rounded up.

---

Quote:

---

Originally Posted by Duke

Statisticians, on the other hand, routinely round .5 to the even number so that rounding errors are more likely to cancel out in the long run.

---

It makes so much sense I feel silly, it never entered my mind there were other ways to round.

Well this is the first time I've ever heard of Banker's rounding too so I guess there's a lesson learned too...

Aphraxen... You might also be able to apply it for STR and HP

Yes it does apply to STR and HP as well. HP = (STR / 2) + 400

Aaahhh... 1.7 has been out a few days and I haven't reached the max level yet...
Will try to update when I reach that... and still figure out some of the inconsistencies in my guide along the way...

Looks great! I woulda never figured this out...

Very amazing stuff you put together.

I am an admitted idiot, but after reading this over couldn't the m/s formula mystery simply be solved by a programming table (if/then statement). If int is X then m/s is Y?

*shrugs*

Quote:

---

Originally Posted by Vanced

I am an admitted idiot, but after reading this over couldn't the m/s formula mystery simply be solved by a programming table (if/then statement). If int is X then m/s is Y?

*shrugs*

---

No it's on a continuum. You can have fractional M/s. For intstance a new character Mage does not display 1M/s until 11 Int, but if you watch your mana bar you will see it rising because you have about 0.92 M/s (for mages it was Int X 0.02 + 0.78 last I checked).

Quote:

---

Originally Posted by Royce

No it's on a continuum. You can have fractional M/s. For intstance a new character Mage does not display 1M/s until 11 Int, but if you watch your mana bar you will see it rising because you have about 0.92 M/s (for mages it was Int X 0.02 + 0.78 last I checked).

---

Who said "Y" has to be a whole number... ;)

...being a smart *** is better than being a dumb ***!

Quote:

---

Originally Posted by Eleanor

Aaahhh... 1.7 has been out a few days and I haven't reached the max level yet...
Will try to update when I reach that... and still figure out some of the inconsistencies in my guide along the way...

---

Up to level 55 (271/272/277) here:
https://spreadsheets.google.com/ccc?...thkey=CKyen78I

nothing really new as those values have been attainable through gear before patch. I might buy some STR gear to push the values higher later.

Quote:

---

Originally Posted by Royce

(for mages it was Int X 0.02 + 0.78 last I checked).

---

That still has the problem at 60 and 260 that we ran into earlier.

Bump - Important thread.

So, I was messing with the spreadsheet (well, by copying the cells).

For turning the INT values to MANA values the following excel/google spreadsheet formula works and matches the listed and in game displayed values exactly:

=ceiling(INT/2+600, 1)-floor(mod(INT-2,4)/3,1)

I couldn't (quickly) find a "banker's" round in the function list.

Confused by this? All it does is the base formula (int/2+600) and adds 1 every 4.

Thing is, based on other rounded values found in the display of data on the screen, I wouldn't be surprised if the internal values weren't rounded at all -- in which case, just adding 600 to half your character's int is good enough. Or, for looking at effects items will have, just add half the int will get you a good enough value.

I'd expect about the same with the displayed values of M/s, too. That is to say, a simple formula that tracks the values might actually give a better indication of the internal value than the displayed value does.