Giles.floydub17_ESO wrote: »
Often Devs learn the details of how their game works from players like Asayre.
Are you for real?
Giles.floydub17_ESO wrote: »
Often Devs learn the details of how their game works from players like Asayre.
Are you for real?
You realize how foolish you sound, right?
What you said would be like claiming that an author learns the details of how their language works from their readers.
What you said would be like claiming that Orville and Wilbur Wright learn the details of how a plane flies from pilots.
What you said would be like claiming that Robin Williams learned how comedy works from people who watched his movies.
What you said would be like claiming that Henry Ford learned the details of how cars work from people who drive them.
The more I try to wrap my head around your claim, the more I feel that your backwardness may cause me to have a massive stroke.
@ZOS_GinaBruno We need a method of giving posts a thumbs-down.
sekou_trayvond wrote: »If I'm understanding this correctly, this is nothing new.
I first was "informed" of this math back when I was creating a blazing shield tank last year- that being, all CP is rounded to the nearest integer.
Odd? Definitely.
Misleading? Meh. The math involved here is inconsequential to a vast majority of players.
It does demonstrate one of the irksome facets of CP: it's just this large wall of mathy text that I assume makes the eyes of large swaths of players glaze over.
Uriel_Nocturne wrote: »If these "jump points" are indeed the truth of the matter; mix that with the massive front-loading of CP values, and you get a game that is even more so: "ESO: The ONLY MMORPG where you get weaker the more you play!"
Merlin13KAGL wrote: »It's a truncation error from the conversion to integer format, integers generally being faster to process internally.
Sadly this could easily be fixed by storing the % values shifted by a factor of 10, and then dividing by 10 after the calculation to get the end result. The (correct) math ends up the same, but nothing is lopped off in the intermediate calculations.
It's how you can do percentage math and deal with values less than whole numbers using a system that can only process integers. You simply need to make sure the type has enough bits to hold the intermediate result. (DINT vs INT, etc).
Sure, it adds one more calculation to things involving CP's, but I doubt one additional calculation would kill the server. The side effect would be when all calculations would be converted over this way, as inevitably, they'd get one of them NKR (Not Quite Right).
For people arguing that losing that partial percentage isn't a big deal, they're half right. Where it comes into play is at that 99 mark. Maybe not such a big deal on that star, but do that in 3 places and you're missing out on the opportunity to have nearly 75 in a different one.
That is potentially huge.
Merlin13KAGL wrote: »It's a truncation error from the conversion to integer format, integers generally being faster to process internally.
Sadly this could easily be fixed by storing the % values shifted by a factor of 10, and then dividing by 10 after the calculation to get the end result. The (correct) math ends up the same, but nothing is lopped off in the intermediate calculations.
It's how you can do percentage math and deal with values less than whole numbers using a system that can only process integers. You simply need to make sure the type has enough bits to hold the intermediate result. (DINT vs INT, etc).
Sure, it adds one more calculation to things involving CP's, but I doubt one additional calculation would kill the server. The side effect would be when all calculations would be converted over this way, as inevitably, they'd get one of them NKR (Not Quite Right).
For people arguing that losing that partial percentage isn't a big deal, they're half right. Where it comes into play is at that 99 mark. Maybe not such a big deal on that star, but do that in 3 places and you're missing out on the opportunity to have nearly 75 in a different one.
That is potentially huge.
Quite so.
It is a good opportunity to politely ask @ZOS_GinaBruno to see if she can get an answer from the Devs? Maybe from @ZOS_RichLambert?
Is this an unintended glitch? If so, will it be corrected in the future?
At the moment, according to the calculations observed by these players above, anyone putting just a single point into one of the main CP stars will get actually 0%.
Thank You and Regards!
Giles.floydub17_ESO wrote: »
Often Devs learn the details of how their game works from players like Asayre.
Are you for real?
You realize how foolish you sound, right?
What you said would be like claiming that an author learns the details of how their language works from their readers.
What you said would be like claiming that Orville and Wilbur Wright learn the details of how a plane flies from pilots.
What you said would be like claiming that Robin Williams learned how comedy works from people who watched his movies.
What you said would be like claiming that Henry Ford learned the details of how cars work from people who drive them.
The more I try to wrap my head around your claim, the more I feel that your backwardness may cause me to have a massive stroke.
@ZOS_GinaBruno We need a method of giving posts a thumbs-down.
NewBlacksmurf wrote: »Merlin13KAGL wrote: »It's a truncation error from the conversion to integer format, integers generally being faster to process internally.
Sadly this could easily be fixed by storing the % values shifted by a factor of 10, and then dividing by 10 after the calculation to get the end result. The (correct) math ends up the same, but nothing is lopped off in the intermediate calculations.
It's how you can do percentage math and deal with values less than whole numbers using a system that can only process integers. You simply need to make sure the type has enough bits to hold the intermediate result. (DINT vs INT, etc).
Sure, it adds one more calculation to things involving CP's, but I doubt one additional calculation would kill the server. The side effect would be when all calculations would be converted over this way, as inevitably, they'd get one of them NKR (Not Quite Right).
For people arguing that losing that partial percentage isn't a big deal, they're half right. Where it comes into play is at that 99 mark. Maybe not such a big deal on that star, but do that in 3 places and you're missing out on the opportunity to have nearly 75 in a different one.
That is potentially huge.
Quite so.
It is a good opportunity to politely ask @ZOS_GinaBruno to see if she can get an answer from the Devs? Maybe from @ZOS_RichLambert?
Is this an unintended glitch? If so, will it be corrected in the future?
At the moment, according to the calculations observed by these players above, anyone putting just a single point into one of the main CP stars will get actually 0%.
Thank You and Regards!
@Zyrudin
It's been this way tho...maybe ppl are just now noticing it because the percentages are harder to raise for each full %
NightbladeMechanics wrote: »These are caused by rounding errors. I doubt ZOS even knows they exist, so I wouldn't call it misinformation.
Regardless, they make a tiny difference in stats and give hardcore theorycrafters one more thing to test and number crunch to optimize builds. The game would be less exciting without some unexpected math under the hood from time to time, but I do agree that unexpected performance shouldn't make a major difference (which these don't).
My thought too, and its pretty common to do internal currency calculations in cent or ever 1/1000 dollars then divide and format before presenting it.Merlin13KAGL wrote: »It's a truncation error from the conversion to integer format, integers generally being faster to process internally.
Sadly this could easily be fixed by storing the % values shifted by a factor of 10, and then dividing by 10 after the calculation to get the end result. The (correct) math ends up the same, but nothing is lopped off in the intermediate calculations.
It's how you can do percentage math and deal with values less than whole numbers using a system that can only process integers. You simply need to make sure the type has enough bits to hold the intermediate result. (DINT vs INT, etc).
Sure, it adds one more calculation to things involving CP's, but I doubt one additional calculation would kill the server. The side effect would be when all calculations would be converted over this way, as inevitably, they'd get one of them NKR (Not Quite Right).
For people arguing that losing that partial percentage isn't a big deal, they're half right. Where it comes into play is at that 99 mark. Maybe not such a big deal on that star, but do that in 3 places and you're missing out on the opportunity to have nearly 75 in a different one.
That is potentially huge.
Bombashaman wrote: »