Page 1 of 2 12 LastLast
Results 1 to 20 of 23

Thread: Enchantress' Attributes Guide (Table Format)

  1. #1
    Member Eleanor's Avatar
    Join Date
    Nov 2010
    Posts
    61
    Thanks Thanks Given 
    0
    Thanks Thanks Received 
    1
    Thanked in
    1 Post

    Lightbulb 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

  2. The Following User Says Thank You to Eleanor For This Useful Post:


  3. #2
    Junior Member
    Join Date
    Dec 2010
    Posts
    32
    Thanks Thanks Given 
    0
    Thanks Thanks Received 
    0
    Thanked in
    0 Posts

    Default

    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?
    Last edited by Apraxhren; 01-21-2011 at 08:04 AM. Reason: Fixed M/s & Thanks.

  4. #3
    Member Eleanor's Avatar
    Join Date
    Nov 2010
    Posts
    61
    Thanks Thanks Given 
    0
    Thanks Thanks Received 
    1
    Thanked in
    1 Post

    Default

    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...

  5. #4
    Junior Member
    Join Date
    Dec 2010
    Posts
    32
    Thanks Thanks Given 
    0
    Thanks Thanks Received 
    0
    Thanked in
    0 Posts

    Default

    Quote Originally Posted by Eleanor View Post
    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 View Post
    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 View Post
    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.
    Last edited by Apraxhren; 01-22-2011 at 08:50 AM. Reason: Expanded on seeds

  6. #5
    Member Eleanor's Avatar
    Join Date
    Nov 2010
    Posts
    61
    Thanks Thanks Given 
    0
    Thanks Thanks Received 
    1
    Thanked in
    1 Post

    Default

    Quote Originally Posted by Apraxhren View Post
    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 View Post
    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 View Post
    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...

  7. #6
    Junior Member
    Join Date
    Dec 2010
    Posts
    32
    Thanks Thanks Given 
    0
    Thanks Thanks Received 
    0
    Thanked in
    0 Posts

    Default

    Quote Originally Posted by Eleanor View Post
    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.

  8. #7
    Junior Member
    Join Date
    Dec 2010
    Posts
    32
    Thanks Thanks Given 
    0
    Thanks Thanks Received 
    0
    Thanked in
    0 Posts

    Default

    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.

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

  9. #8
    Member JackDonkey's Avatar
    Join Date
    Jan 2011
    Location
    Parker, Colorado
    Posts
    127
    Thanks Thanks Given 
    0
    Thanks Thanks Received 
    0
    Thanked in
    0 Posts

    Default

    Wow this is quite amazing you guys!

  10. #9
    Member Eleanor's Avatar
    Join Date
    Nov 2010
    Posts
    61
    Thanks Thanks Given 
    0
    Thanks Thanks Received 
    1
    Thanked in
    1 Post

    Default

    Quote Originally Posted by Apraxhren View Post
    The thing I don't understand is setprecision() should truncate the number instead of rounding some.
    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 View Post
    Wow this is quite amazing you guys!
    Thank you! You made me prouder of my work! Haha!
    Last edited by Eleanor; 01-24-2011 at 09:56 AM.

  11. #10
    Junior Member
    Join Date
    Dec 2010
    Posts
    32
    Thanks Thanks Given 
    0
    Thanks Thanks Received 
    0
    Thanked in
    0 Posts

    Default

    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.

  12. #11
    Forum Adept Duke's Avatar
    Join Date
    Apr 2010
    Posts
    324
    Thanks Thanks Given 
    0
    Thanks Thanks Received 
    12
    Thanked in
    2 Posts

    Default

    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.

  13. #12
    Junior Member
    Join Date
    Dec 2010
    Posts
    32
    Thanks Thanks Given 
    0
    Thanks Thanks Received 
    0
    Thanked in
    0 Posts

    Default

    Quote Originally Posted by Duke View Post
    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 View Post
    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.

  14. #13
    Member Eleanor's Avatar
    Join Date
    Nov 2010
    Posts
    61
    Thanks Thanks Given 
    0
    Thanks Thanks Received 
    1
    Thanked in
    1 Post

    Default

    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

  15. #14
    Junior Member
    Join Date
    Dec 2010
    Posts
    32
    Thanks Thanks Given 
    0
    Thanks Thanks Received 
    0
    Thanked in
    0 Posts

    Default

    Yes it does apply to STR and HP as well. HP = (STR / 2) + 400
    Apio - Lvl 55 Enchantress, Dinde - Lvl 50 Archer, UnclePio - Lvl 10 Dex Bear

  16. #15
    Member Eleanor's Avatar
    Join Date
    Nov 2010
    Posts
    61
    Thanks Thanks Given 
    0
    Thanks Thanks Received 
    1
    Thanked in
    1 Post

    Default

    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...

  17. #16
    Banned
    Join Date
    Oct 2010
    Location
    Throwing Down
    Posts
    5,167
    Thanks Thanks Given 
    7
    Thanks Thanks Received 
    61
    Thanked in
    38 Posts

    Default

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

  18. #17

  19. #18
    Member Vanced's Avatar
    Join Date
    Feb 2011
    Posts
    58
    Thanks Thanks Given 
    0
    Thanks Thanks Received 
    0
    Thanked in
    0 Posts

    Default

    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*
    ~Elvix... UnGuilded... Insert cool picture and witty comment here!

  20. #19
    Guardian of Alterra Royce's Avatar
    Join Date
    Apr 2010
    Location
    Pennsylvania, USA
    Posts
    4,738
    Thanks Thanks Given 
    10
    Thanks Thanks Received 
    43
    Thanked in
    35 Posts

    Default

    Quote Originally Posted by Vanced View Post
    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).
    http://www.spacetimestudios.com/image.php?type=sigpic&userid=6183&dateline=1275696  601
    Quote Originally Posted by conradin View Post
    To doubt Royce, is to doubt your sanity...
    Quote Originally Posted by TwinkTastical View Post
    Royce is right, You are WRONG. Live with it.

  21. #20
    Member Vanced's Avatar
    Join Date
    Feb 2011
    Posts
    58
    Thanks Thanks Given 
    0
    Thanks Thanks Received 
    0
    Thanked in
    0 Posts

    Default

    Quote Originally Posted by Royce View Post
    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 ***!
    Last edited by Vanced; 02-17-2011 at 04:21 PM.
    ~Elvix... UnGuilded... Insert cool picture and witty comment here!

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •