What's up with all the decimal places since the update?

dharbert

There are now decimal places in the description of pretty much everything where there was none before.

For example, my Lord's Longsword says it deals 37.0 cold damage. It used to just say 37. It's the same with every other weapon, armor, and skill.

Also, the duration of Devouring swarm says it's 5 seconds, but the tooltip says 6.0 seconds. So which is it?

ben_ESO5

Maybe something to do with the next step in the champion system? Just a guess. Somewhere they posted that all stat numbers will be going up by a magnitude of ten (or was it 100?). So your 3000 health will become 30,000 health, so that the incremental advancements in the champion system *look* more noticable.

ers101284b14_ESO

ben_ESO5 wrote: »

Maybe something to do with the next step in the champion system? Just a guess. Somewhere they posted that all stat numbers will be going up by a magnitude of ten (or was it 100?). So your 3000 health will become 30,000 health, so that the incremental advancements in the champion system *look* more noticable.

Yeah it was 10. Because 1% of 1 isn't noticeable but 1% of 100 is or something like that. They explained at one point during the Guild summit.

PBpsy

Zos decided that the average IQ of the users is 5 points above that of a rotten carrot and they may possibly comprehend the concept of decimals.

Nestor

It was also due to rounding issues. if the calculation was to add .6, then 1 could be added instead giving a 40% increase to the buff so now things are increased or decreased as they should be.

Breg_Magol

Nestor wrote: »

It was also due to rounding issues. if the calculation was to add .6, then 1 could be added instead giving a 40% increase to the buff so now things are increased or decreased as they should be.

I have rounding issues ... I've been trying the Paleo diet to try to get rid of the biggest rounding issue I have; my belly.

Now Let me get this straight ... if I add .6 then 1 can be added giving an increase of 40% to the buff!? But that's EXACTLY what I DON'T want!
I'm trying to get 0% of the buff ...

Look, I know I have the IQ of a rotten cabbage but can you please explain this rounding issue again ... like you're explaining to a 6 y.o.

My body is my temple ... and it's pretty roomy at the moment :P

Gillysan

Devouring Swarm was mentioned in the patch notes. They mention a lot of skills in the patch notes. You might want to go look through them.

dharbert

Gillysan wrote: »

Devouring Swarm was mentioned in the patch notes. They mention a lot of skills in the patch notes. You might want to go look through them.

I'll take a screencap of it as soon as the server is back up. I know there was a nerf to swarm, that's not the issue. Basically, one part of the swarm description says the duration is 5 seconds, but the tooltip says the duration is 6.0 seconds. It can't be both.

driosketch

ben_ESO5 wrote: »

Maybe something to do with the next step in the champion system? Just a guess. Somewhere they posted that all stat numbers will be going up by a magnitude of ten (or was it 100?). So your 3000 health will become 30,000 health, so that the incremental advancements in the champion system *look* more noticable.

I'm actually hoping they decided to go with adding the decimal to everything rather than multiply everything by 10.

Nestor

Breg_Magol wrote: »

Look, I know I have the IQ of a rotten cabbage but can you please explain this rounding issue again ... like you're explaining to a 6 y.o.

Say some calculation in the game to give you a buff gives .6 as an answer. However the database field was configured as an Integer. Integer fields can only hold whole numbers. Which means if you enter the value of .6, it will be accepted as a 1. 1 is better than .6. Now, you might be thinking that .4 difference is meaningless as a value in the game, and your right. But what if that .6 was used further on in the calculations to determine the total amount of the buff? There could be big difference in the answer if .6 was used rather than 1. So, by making the numbers 60 and 100, then the results of the equation are as intended.

There are many reasons why you can't change a databases number type after creation (from integer to decimal in this case) so to regain the missing fractions, it is easier to multiply everything by 100 (or what ever value). Then all the number fields can remain as is, but the underlying values give the intended result in the equations. Also, the Precision of the Decimal field, or the amount of numbers you have to the left of the decimal place is fixed at database creation. So, another reason why this change can help get around shortcomings in the database creations.

http://publib.boulder.ibm.com/infocenter/cmod/v8r4m1/index.jsp?topic=/com.ibm.ondemand.planningmp.doc/ars1p17189.htm

Back when I was designing databases we use to spend hours fretting over this wondering if any value was going to ever be a fraction or decimal. Because, once defined, it is not changed, ever as you lose the values in those fields. You have to create a new database and import the existing data into the new fields. Can't just build a new table either, as all the calculations are contained in the queries, for the most part anyway.

firstdecan

Nestor wrote: »

Breg_Magol wrote: »

Look, I know I have the IQ of a rotten cabbage but can you please explain this rounding issue again ... like you're explaining to a 6 y.o.

Say some calculation in the game to give you a buff gives .6 as an answer. However the database field was configured as an Integer. Which means if you enter the value of .6, it will be accepted as a 1. 1 is better than .6. Now, you might be thinking that .4 difference is meaningless as a value in the game, and your right. But what if that .6 was used further on in the calculations to determine the total amount of the buff? There could be big difference in the answer if .6 was used rather than 1. So, by making the numbers 60 and 100, then the results of the equation are as intended.

There are many reasons why you can't change a databases number type after creation (from integer to fraction for instance) so to regain the missing fractions, it is easier to multiply everything by 100 (or what ever value). Then all the number fields can remain as is, but the underlying values give the intended result in the equations.

http://publib.boulder.ibm.com/infocenter/cmod/v8r4m1/index.jsp?topic=/com.ibm.ondemand.planningmp.doc/ars1p17189.htm

I don't think linking to IBM technical documentation is explaining like explaining something to s six year old, even if the documentation is geared towards first week CS students.

@Breg_Magol, I don't understand the issue either. The devs are going to make the numbers bigger so people can feel better about them. After all, bigger is better, and since math is hard people will just assume the bigger numbers are more meaningful. This bologna about making a 1% difference impactful is a non-starter. Whether it's 1% of 60 or 1% of 600, 1% is near meaningless and needs to be combined with another 9% to be impactful.