Magic

Magic

190k Downloads

Ceil/Floor function not working as intended.

NightScythe1 opened this issue ยท 2 comments

commented

2023-02-14_03 23 05
2023-02-14_03 22 56
2023-02-14_03 23 02
The ceil & floor functions are not seeming to round the values of 'generic_attack_damage' effectively.
The wand has the following in its config:

item_properties:
   item_attributes:
       generic_attack_damage: 7.2*((ceil(rand(0,50))/100)+1)

but the numbers continue to result in arbitrary values.

commented

Those screenshots were all from this config, right?

I'm having trouble getting anything other than 2-digit numbers, and they all look reasonable.

I am trying to figure out how you possibly got 10.864 though- 10.8 should be the max!

7.2*((Math.ceil(50)/100)+1) = 10.8

That said, there are basic limitations of floating-point math that make this hard :(

For instance, for the random number 5:

7.2*((Math.ceil(5)/100)+1) = 7.5600000000000005

This is just Javascript (for testing) but any language or platform will have similar issues, it is not possible to exactly represent every possible floating-point number.

That said, another floor/ceil combined with a multiply and divide should be able to let you round to whatever number of decimal places you want, like:

Math.ceil(10 * (7.2*((Math.ceil(5)/100)+1))) / 10 => 7.6

Let me know if that helps!

commented

Thanks for the detailed response! I did manage to overcome this by using a different formula for calculating the damage values:
generic_attack_damage: (ceil(rand(70,110))/10)
which wound up providing much clearer & more reasonable values (all within 1 decimal place as intended), my attempt in the initial config in the big report was pretty much me trying to convey "7.2 is the base damage, but multiply it by a random value between 1 to 1.5 for bonus damage" which is where the ((ceil(rand(0,50))/100)+1) came from. That's the format that was providing weird numbers as shown in the images, but I found simply setting a Ceil+Random lower & upper limit to the damage (as shown in this comment) never returned bad values and always showed them to the correct decimal I was aiming for. Might've just been a funky side-effect of my original imperfect/weird usecase haha, thank you though!