Railcraft

Railcraft

34M Downloads

Incorrect time left readout on worldspikes

Pherret0 opened this issue ยท 6 comments

commented

Upon putting in fuel the time left in the GUI is inaccurate.

Having set in config for fuel to last a small amount of time (ender pearls = 0.02) then adding an ender pearl into a worldspike it lists the time left as 0.033 hours.

It would be expected that the shown value would match that in the config.

The server was running at normal tickrate and wasn't encountering any issues. Therefore the time should have been accurate.

commented

"this is an approximation only, actual duration is affected by number of chunks loaded and tick rate"

Possibly the reason.

commented

It is only the readout that was inaccurate though. The actual time expected was spot on to within half a millisecond. I'm guessing its something within how the text in the GUI is doing rounding. I also checked that and am pretty sure the rounding itself is off if it is to increments of 0.017ish. If that does turn out to be the issue and the rounding is there to prevent it changing too often then my way of looking at it would be potentially just decreasing the amount of decimals in the gui and making sure it updates more frequently so as to keep it accurate at small values.

commented

Hmm... are we talking tooltip or gui time remaining report?

The gui time remaining report converts the ticks remaining to an integer minute value, then divides that by 60.0 to get the result.

commented

But this is still an approximation, because one fuel tick is removed for every chunk loaded (except in carts apparently). Resulting in the counter decreasing faster than it would indicate.

Probably some screwy math in there thinking about it. lol

commented

Yeah the gui of the worldspike. My best guess is some rounding that isn't accurate enough for the amount of decimals which just makes it seem strange. potentially because the minute value is an integer. If that is the case then if you wanted the same amount of decimals then maybe some kind of float or decimal (I've not done any java for too long. Can't remember if thats a thing. I mean basically an integer but with a decimal point shifted into it somewhere). I think it must be some screwy math on the integer conversion. I'll take a look in a bit (currently prioritising some other mod problems, the fun of making a large modpack singlehandedly) and if that is the case I can try to remedy it by either changing the amount of decimals displayed in the GUI or fixing the math depending on if you have a preferance. But i can definitely confirm that the math issue isn't with the actual approximation itself as the real amount of time that it lasted was exactly as it should have been given the config options. It was 100% GUI related

commented

Syncing floats and longs across the gui is tricky. I have methods for doing it though, if that's the problem. Not that I remember the exact method myself.