Is standard rounding available in Roll20

I am a bit confused after this topic , which seems to imply that a roll function in Roll20 is automatically rounded, which seems not to be the case in my campaign. For instance: /r 50/12 yields 4.1666666667 instead of the expected 4. I understand the floor and ceiling functions as per the Roll20 docs , but I need standard rounding. I am using a crunchy system - one which recalcs Load penalty throughout combat - and the flow of combat is better served by keeping track of actual load (weight) in a token bar and dividing by endurance within an ability/macro . /r 1d100 - @{Penalty:Fatigue} - @(Penalty:Injury} - (@{Load} / @{Endurance}) -&gt;88 - 20 - 10 - (50/12) = 58.8333333333333336 How do I get that formula to return 59? References: <a href="https://app.roll20.net/forum/post/186589/why-does-" rel="nofollow">https://app.roll20.net/forum/post/186589/why-does-</a>... <a href="https://wiki.roll20.net/Dice_Reference#Rounding_Ro" rel="nofollow">https://wiki.roll20.net/Dice_Reference#Rounding_Ro</a>...

have you tried /r floor(1d100 - @{Penalty:Fatigue} - @(Penalty:Injury} - (@{Load} / @{Endurance})) does it not work with @variables? using your example numbers /r floor(88 - 20 - 10 - (50/12)) returns 53 ..(vs 53.833333336) or wrapped in ceil() if your rounding up or if Im missing the point totally, and you mean you need to round to nearest, no roll call for it yet, would need an API script I believe.

I need to round to the nearest in order to stay consistent with the rules. Were I to round down (floor) the world wouldn't come to an end, but I there would be no end to the number of times I'd have to explain it and there might be an unforeseen issue mixing virtual and live events. It doesn't make sense that it would need a script as it is a rather basic mathematical function available in any calc. More likely is that I am doing something wrong or overlooking the obvious.

William is correct, there is currently no round to nearest function but the API (a Mentor level feature) can probably do it.

We have floor and ceil, just not round.

Is that a function that's likely to be added soon? I don't mean to be negative, but without it there's more functionality in hangouts and a google spreadsheet.

Rounding a positive number is just floor(x + 0.5) . Rounding a negative number is ceil(x - 0.5) . I don't know of a means to test a number's sign with the tools available to base and supporter accounts, but if you're dealing with only one or the other (or can fanangle your calculations to only need one of the other), then floor and ceil are sufficient.

I am not a Dev so cannot comment on when or if it may be added.. However, looking at your requirement I think I have figured out how to mathematically work out rounding using your macro. /r 1d100 - @{Injury} -@{Fatigue} -floor(@{Load}/@{Endurance})*[[ { 10000*(1d1-1+ (@{Load}/@{Endurance})-floor(@{Load}/@{Endurance})) }&lt;4999]] - ceil(@{Load}/@{Endurance})*[[ { 10000*(1d1-1+(@{Load}/@{Endurance})-floor(@{Load}/@{Endurance})) }&gt;5000]] Breaking it down we have: /r 1d100 - @{Injury} -@{Fatigue} -"rounded value of @{Load}/@{Endurance}" To calculate the rounded value you use the following equation: floor(A/B)*[[ { 10000*( 1d1-1+ (A/B)-floor(A/B) ) }&lt;4999]] - ceil(A/B)* [[ { 10000*( 1d1-1+ (A/B)-floor(A/B) ) }&gt;5000]] Note: the minus sign between the left and right inline terms is due to the macro you have above. It could just as easily be a plus sign. Breaking it down further we have: floor(A/B)*[[ { 10000*( 1d1-1+ (A/B)-floor(A/B) ) }&lt;4999]] This section tests to see if the formula is less than or equal to 0.4999 (if you want more decimals you can add more). If it is less than or equal to 0.4999 then it will round down. If it is greater than 0.4999 then the value will be zero. ceil(A/B)* [[ { 10000*( 1d1-1+ (A/B)-floor(A/B) ) }&gt;5000]] This section tests to see if the formula is greater than or equal to 0.5. If it is greater than or equal to 0.5 then the value will be rounded up. If iit is less than 0.5 then the value will be zero. Both sections are mutually exclusive. Note: There is a gap if the decimal value in the floor section happens to be greater than 0.4999 and less than 0.5 (such as 0.49991). But, that is unlikely to happen and if you want greater accuracy you can increase the number of digits involved. If for some reason this does not work please let me know. Edit: cleaned up a bit of the explanation.

Gauss, that is a successful work-around. Thank you for putting up with my frustration.

No worries, I like figuring puzzles like this out. :)

I would suggest doing either Floor (x+0.5) or Ceiling (x-0.5), where x is your value, either way get's your rounding to exactly where you want it regardless of it's decimal value. That's one of the ways it's normally down in coding environments anyway. Another is using if statements, which would be a bit more complicated to explain to a noncoder, and such methods may not be available in the system anyway.

For positive numbers ceiling(x-0.5) won't work because at (x.5 - 0.5) it will leave just "x" rather than "x+1". However, looking at floor(x+0.5) it should work just fine and is a simpler solution than my own. At values of "x" to "x.4999" it will round down while at values of "x.5" to "x.9999" it will (effectively) round up to "x+1".

I would love conditionals, but assume I need to upgrade to Mentor for that.