Maths quiz, solution required.

Can you please fill in the missing number to this sequence?

10 , 17 , 24 , 31 , 38 , 45 , ? ....

10 is the commander and 7 is how much we get from each metal spot. However logic tells us the next number should not be 51... But it is.

Maybe a homage to area 51 or one of the devs really hates the band the B-52s.

Edit: 177 goes to 185 too.

Your logic is flawed. Use Math. The next number is 52

EDIT: I should check this in game lol

62

actually is 62 45+7=52(thats the metal production)+10(commander production)=62

Maybe metal extractors don't give exactly 7, but something like 6.8-6.9?

What would be the use it would be only harder to calculate i think it´s 62 however i could be wrong

Hahah i know the next number is 52, however it is 51 in the game. Well if the number is a decimal it would reoccur later, but it doesnt. Just check pa stats, it's easier.

THE MATHS

Someone really screwed that up lolz

Uber be like

The UI seems to be given those exact values, so I guess somewhere in the native code is some sort of rounding at work.

So it would seem.....

from IMDb quotes, Office Space:

Peter Gibbons: [Explaining the plan] Alright so when the sub routine compounds the interest is uses all these extra decimal places that just get rounded off. So we simplified the whole thing, we rounded them all down, drop the remainder into an account we opened.
Joanna: [Confused] So you're stealing?
Peter Gibbons: Ah no, you don't understand. It's very complicated. It's uh it's aggregate, so I'm talking about fractions of a penny here. And over time they add up to a lot.
...
Peter Gibbons: Um... the 7-11. You take a penny from the tray, right?
Joanna: From the cripple children?
Peter Gibbons: No that's the jar. I'm talking about the tray. You know the pennies that are for everybody?
Joanna: Oh for everybody. Okay.
Peter Gibbons: Well those are whole pennies, right? I'm just talking about fractions of a penny here. But we do it from a much bigger tray and we do it a couple a million times. ​

I think clopse discovered how the AI is planning to retire. By stealing a fraction of the output of the 6th MEX we all build in each game!

Maybe its not so much rounding, as much as it is that somewhere the values are given as integers, cutting off any decimals.

Ahh, those pesky gnomes! They're stealing my metal!

I think someone needs to take a quick look at the variable types.

Source: I'm up to 50% through the Python course on CodeAcademy, so I am now an expert.

I actually did try to figure this out, and came across some stack exchange posts that touch near the topic, mentioning boundaries and edge cases to watch for when trying to avoid using the multiplication operator in code (using bit shifting instead, and such). It seems like such simple math that wouldn't apply though. I'm thinking it's some quirk more related to the 'ticks' used, and some non-integer math involved in that. I vaguely recall some thread or bug report about the ticks not adding up perfectly.

I don't think we can tell, because the javascript callback gets a clean 51 already. So whatever happens it happens in native code, probably even on the server.

@thewrongcat:
Javascript only knows exactly one type "number". It's basically a double, so it is prone to rounding errors, however all integer math is exact in it. Doesn't matter though as I said above.

doesnt sound like a simple double or float problem with these small ranges. However, the server runs at 10 ticks per second, and 1/10 cant be represented in any base-2 number. (Thats why financial stuff usually multiplies by 100 and uses integers)

And why the fps is most likely to be driven by ms. 100ms per frame is a clean nice value.

Edit: Forget that first one, I ment: Wasn't it like 9.5 or 9.95 ticks per second?