I just got a mission screen with my credits listed as : 6693135.800000001
The problem is the rounding of player.credits. In oolite the introduction of a rounding error happens when converting the credits to a JS number.
My question: Is this an oolite bug and should it do additional rounding before returning a value OR is this the responsibility for the script to do all the rounding of player credits?
Good question. I wouldn't call it an Oolite bug, to be honest. I guess a different way of putting it would be: Is there any chance, ever, that a script might require to show the player any credit value past the first decimal on a mission screen? If yes, then we leave it as is. If no, then we could consider rounding it to one decimal in code.
In any case, it is very easy to print a number with a determined amount of decimals shown. In your case, the credits value somehow went to 6693135.800000001. For ensuring that this number is displayed on a mission screen with one decimal only, one can do as an example
Good question. I wouldn't call it an Oolite bug, to be honest.
That depends how you look at it. Internally the player credits is maintained at a precision of one digits. (Actually as integer in deci-crecredits). So from the internal code it feels somehow as a bug that it can return a slightly different value.
I just thought it would be more convenient for scripts if the code would make sure no rounding errors would show up.
But the code player.credits.toFixed(1) is just as easy, as long as programmers are aware of the need of avoiding rounding bugs. For some reason I did not knew that JS command and always used Math.round(player.credits*10)/10
And a big advantage of player.credits.toFixed(1) is that it will also create numbers with one decimal like "34.0". So for showing the player.credits it even feels like a must to use.
This rounding issue is a bigger problem than just credits.
I've encountered similar problems with galaxy map X, Y (0-255) native coordinates returning long decimal numbers when they should be integers for systems.
And converting them to Light Year X,Y coordinates via:
X-LY = 0.4*Math.floor(X);
Y-LY = 0.2*Math.floor(Y);
...just seems to make the problem worse.
Would "player.credits.toFixed(1)" work for other variables like this.myownvariable.toFixed(1) for use for example to keep custom hud gauge variables rounded to 1 decimal place, for example when dealing with amount of fuel the player has and displaying it properly?
Take an idea from one person and twist or modify it in a different way as a return suggestion so another person can see a part of it that can apply to the oxp they are working on.
Take an idea from one person and twist or modify it in a different way as a return suggestion so another person can see a part of it that can apply to the oxp they are working on.