Wenn you leave the table cell by clicking on another cell (without pressing <Enter> first), do you wish to retain the currently visible value or should it be reset to the value it was before changing the cell? Leaving the cell without pressing <Enter> would amount to a cancel action, so arguably the latter is 'correct', but the former would be more convenient.

    Solar cells are not affected by speedups/speeddowns - they produce exactly the same amount of energy in vacation mode as out of it.

    Unless you get shown on your in-game Economy view that your solar cells deliver 100x more energy with speedup that without it I maintain the current behavior is correct. Please check your numbers against the in-game values.


    The second behavior I'm fighting against almost as long as Java exists. When you click into another cell while the first one still has the editor, the editor should close and a new one should be created. That doesn't happen. Please press <Enter> (affirm) or <Esc>, <Tab> (abort) before you click on another cell.

    Tremendously!
    Instead of computing it I can just request it - and it would always be correct :) !

    If you do not use todays counter of 3455, I need a new set of base coordinates that works with your counter.


    Please do include the galaxy rotation counter (even if the galaxies did not rotate yet).


    (I could already totally work with your above solution, but this new one is so much more painless ;))

    One more idea. If the coordinates are requested automatically, they need not be easily remembered.

    Are there, by any chance, planets in SI2 whose orbits do not intersect with others (can be computed individually?). If there are a few of them (orbits need to be diverse and preferably as long as possible)) they could be used to compute the current counter very efficiently.

    The complete resynchronization is only necessary if you start new or lost synchronization over a long time (e.g. after vacation mode).
    The tool keeps track of the last entered value and you can increment it manually. You can check the current state against an arbitrary set of coordinates (e.g your planets). If you are unsure, you can use the 'auto sync'.


    However, as already noted it takes (considerable) time and would slow down startup if done unconditionally.

    It would be nice if the coordinates need not be obtained 'by hand' by copying them, but could be

    a) requested from an SI2 server via a global (non user/user session specific) URL

    OR

    b) pushed to a registered tool (like in SI classic) if explicitly requested (button press or similar)

    I'm at a loss as to the loss of the ~90 days (there has been a period when the planets didn't revolve, but 90 days seems excessive), but it works as you outlined.


    All orbital positions were recorded at one point in time (specifically, time="03.02.2013 [10:53]). Between that day and now the planets have been moved a certain number of times (in theory once per day, but obviously that has not been the case).

    In a practical world you could determine the current position of one planet by just knowing the starting position of that planet and the number of increments (inversely you could infer a number of increments (modulo orbit length) from current and starting position). Not so in SI2! Because the orbits intersect (they rarely do in the 'real' world). In SI2, when two planets happen to occupy the same spot in space, instead of going out in a blaze of glory, they neatly sidestep each other and move to the next free position. That means, to get the position of one planet, you need to put not only that planet through its paces, but the whole system (one step at a time). You basically have to revolve it 'by hand' once for every step between then and now. That's why we need reference coordinates, to get the exact number of steps.


    As to the periodicity, because of the aforementioned skips you have to step through the coordinates in each of the systems one day at a time. However, the orbits do not intersect every day. Even if they did, that would just mean two increases per day (effectively halving the orbit length), so you would end up with an LCM(59/2, 70/2, 73/2, 110/2) = 401940 ~ 1100 years - still a comfortable margin, I think.

    If you are uneasy with that, or computation is too slow, you can always create a new base table. (now that I think about it, I may want to do that as well, since calculating the rotates from scratch takes quite long already)