Lsc info fix

[ah-OOG-ah]

Replace the linked lists of boxed longs with a simple array.

[Georggi]

Works on our server (Zvezdolet, cherry-picked on top of .103 tag). LSC no longer lags.

[Glease]

wouldn't this make hour long average a constant 0 if IO is below 72000EU/t? This would leads to unusable low precision at IV~early LuV IMO.

[Georggi]

wouldn't this make hour long average a constant 0 if IO is below 72000EU/t? This would leads to unusable low precision at IV~early LuV IMO.

No, it doesn't do that, here is an example of a base which had that level.

There is a problem which we've discussed, where for the first hour (after server restart for instance) the values are not precise, because division is by constant number of samples, instead of number of samples actually received
https://discord.com/channels/181078474394566657/603348502637969419/1315770149386846218

[combusterf]

wouldn't this make hour long average a constant 0 if IO is below 72000EU/t? This would leads to unusable low precision at IV~early LuV IMO.

It would look like it works, if energy comes and goes in in batches over the EU/t limit (e.g. laser hatches would do that), but I don't see it work for the actual scenario.

The fix is easy though: don't do the division where the += and -= are at, but instead at the getter.

[Georggi]

Yeah, nvm, looking at the code for the second time, it probably underreports due to that. Even though it seems correct.

[Georggi]

There is a potential long overflow problem (which I think exists in 2.7 as well), where if you UXV 16M laser hatch, which is 9*10^15, and multiply that by 72000 (max times you can sum), which if awfully close to 2^63)

[ah-OOG-ah]

There is a potential long overflow problem (which I think exists in 2.7 as well), where if you UXV 16M laser hatch, which is 9*10^15, and multiply that by 72000 (max times you can sum), which if awfully close to 2^63)

There shouldn't be any long over/underflow issues unless the EU input is greater than LONG_MAX in a single tick, as the average is identical to what you'd get if you took an average normally - it can't overflow unless there's at least one data point which exceeds LONG_MAX, because even if every datapoint was just under LONG_MAX, dividing N of those by N and then adding them back up isn't going to give you a result higher than LONG_MAX

wouldn't this make hour long average a constant 0 if IO is below 72000EU/t? This would leads to unusable low precision at IV~early LuV IMO.

This is almost certainly an issue though. I believe the fix would just be to use a double to represent it until double precision becomes a problem (which is 2**53 iirc).

[ah-OOG-ah]

wouldn't this make hour long average a constant 0 if IO is below 72000EU/t? This would leads to unusable low precision at IV~early LuV IMO.

It would look like it works, if energy comes and goes in in batches over the EU/t limit (e.g. laser hatches would do that), but I don't see it work for the actual scenario.

The fix is easy though: don't do the division where the += and -= are at, but instead at the getter.

This would work, but unlike using a double to accumulate it would have the overflow problem Georggi mentioned.

[Georggi]

There shouldn't be any long over/underflow issues unless the EU input is greater than LONG_MAX in a single tick, as the average is identical to what you'd get if you took an average normally

Sorry I haven't made myself clear. Yeah, in current implementation, because you divide right away, it's not a problem. If the division were to be done when getting the value, but if it was done in the getter, as combusterf suggested, it would be close enough to maybe be a problem.

Another case though (just for consideration). I think there can be a case with UMV (or a couple of UIV capacitors) it breaks a bit? outputLastTick and inputLastTick are already longs, so it's probably not for this PR (if at all needed), but the data there might be incorrect (lower than actual) and it's such an edge case that it probably should be ignored.