The score is always a whole number,but I am dividing it by a number (which has a value of 0.5, 1 or 2 ) to scale the score, but the resulting number is always a whole number. Interestingly in this case I'm just dividing by 1, but I'm guessing once I divide by a number it changes from an integer to a float.

For reference, here is how the score is calculated:

turn_score = 0
_i = 0
virus_score = 1
while _i < virus_counter do
virus_score *= 2 // each virus cleared in one turn awards an increasingly large score
turn_score += virus_score
_i++
end
// divide by "drop_rate_scaler" to award more points when on higher difficulty
turn_score /= drop_rate_scaler
// add this turn's score to total score
score += turn_score

if i floor the number along the way, it shows up without a decimal point in the simulator as well:

// divide by "drop_rate_scaler" to award more points when on higher difficulty
turn_score /= drop_rate_scaler
turn_score_int = floor turn_score
// add this turn's score to total score
score += turn_score_int

Whoa, this ended up being a really meaty issue (that revealed an even meatier issue).

I have a solution. But it comes at a performance cost on actual hardware.

Basically to mimic the Lua’s number formatting, I have to track the lifetime of any number that is divided or added to, subtracted from, or multiplied by a float. This requires wrapping each arithmetic operator in another function so the JavaScript bridge has a way to maintain that history.

But this would affect the speed of every arithmetic operation regardless of whether the numbers flowing through them were destined to be displayed or not. I’m not comfortable with that trade-off.

I think the solution here is just to note in the docs where the web player and Lua runtime differ. In this case, integers are integers until divided or otherwise mathed with another number that is or has been a floating point number. If an integer is desired then you must floor the number before display.

Oh, and the meatier issue is that the Lua runtime uses a single-precision floating point format while JavaScript uses double-precision. Which probably won’t be an issue for the math Pulp games will demand.

I have updated the JavaScript runtime to match the Lua formatting for floats (eg. instead of 3.142857142857143 the web player will now match the Lua truncated length of 3.142857).

Oh wow! Having to floor a number to make it look nice in a display is definitely a small price to pay for avoiding a performance hit on every arithmetic operation!