Hi,


    I have your tool. In tool I used auto synchronization. Today (18.10.2022, 3:46 pm) your tool calculated 3452 spins. I checked some positions in tool and in game and it seems they are the same, so tool works

    I also downloaded 'big bang' planets-SI2-U1.xml.gz file from your site (SI_Tool). And problem is with date in this file.


    As I understand file shows planet start position index of it's orbit at start day of '03.02.2013 10:53'. So if planets change it's positions once a day then number of days between today and that start date should be equal to spins in your tool. But 3544 days have passed between that day '03.02.2013 10:53' and today '18.10.2022 3:46 pm', not 3452 as tool shows.

    If I would like to have that 3452 spins then the start date would be '06.05.2013' (between that date and today there is 3452 days).

    So the question is if that file is wrong with date?

    ты не правильно думаешь

    нужно ввести координаты планет 1.1,2.2,3.3,4.4 на сегодня и тогда все синхронизируется

    Quote from dark angel

    ты не правильно думаешь

    нужно ввести координаты планет 1.1,2.2,3.3,4.4 на сегодня и тогда все синхронизируется

    Yes I did it. I entered all (001:001:01), (002:002:02), (003:003:03), (004:004:04) planets. And tool works fine. But I want to create my own tool and I need to know how this planet rotation works. To calculate planets position right now, today, I need a point of reference (xml file). Number of days between date in that file and today should be equal to number of spins in the tool. But it's not :D

    • Official Post

    The Problem with this rotation is that you (as tool developer) has to be sure that every day this rotation has to be executed correctly. We had some days (maybe this is the difference of >90days) where this rotation isn't happening.

    Bald_Eagles tool finds out the rotation count where these 4 planets has exactly the position. So if our rotation calculation is working the same way, beside skipping of targets which are occupied, then the tool can say how many spins he needs to get exactly this point

    (i don't look into the code, is is what i think is done by bald_eagles tool)


    Better question is, what happend when these 4 planets has 2 times exactly the same position Bald_Eagle ? If this is happening after 300days and also after 6852 days? Is your tool looking for a estimated duration from this 2013=>2022 (9y+) or is he checking for any rotation?


    but, when spaceinvasion miss 90+ rotation, this sync functions dosnt care about this, this functions just looks for a exact same state.

    (i hope i don't tell seomthing stupid here :) - but this is how i expect this could work)



    btw: Bald_Eagle if you like, you can join our discord too, we could create a talk section there also for your tool

    Quote from Dschibait

    btw: Bald_Eagle if you like, you can join our discord too, we could create a talk section there also for your tool

    You're right. Or at least it makes a lot of sense. I was not aware that sometimes rotation did not occur. Then it must be 92 days from start of the game.
    So if that's true I have my answer: "Date is correct but spins number in tool is smaller then real number of days cause there were days with no rotation".

    Also answering your question:

    Quote from Dschibait

    Better question is, what happend when these 4 planets has 2 times exactly the same position Bald_Eagle ? If this is happening after 300days and also after 6852 days? Is your tool looking for a estimated duration from this 2013=>2022 (9y+) or is he checking for any rotation?

    For the syncronization you need all four planets. I checked their orbit tables that you gave me. Their sizes are 59, 70, 73, 110 (it's how many different positions each orbit has). The 'least common multiple' of thoes numbers is 3 316 390. So if I'm right the same combination of this four orbits in normal situation would appear again in 3 316 390 days :D Of course as I already know sometimes this orbits jump little bit faster but it is probably very rare anyway. And even if that happens that would be problem only for one day, the next day syncronization should work fine (if it looks for first match) :D

    • Official Post

    i wasnt not sure if this is correct, so we are no developers when we would think to much and just write a programm for that:



    result


    Quote

    found same state after 3316390


    that's it - you are right and its about many years, i think we can live with that. To get a more detailed result, we need to take the positions and real calculations - i think, the risk that it happend much earlier isnt high.



    edit:

    but you are wrong, if this is happening the rotation for these are continued in that earlier state (for about XX-FALSE-XX days and not the XX-TRUE-XX days amount) which ends up that any other planet rotation in the universe could be wrong. (and not on just one day)

    Quote from Dschibait

    edit:

    but you are wrong, if this is happening the rotation for these are continued in that earlier state (for about XX-FALSE-XX days and not the XX-TRUE-XX days amount) which ends up that any other planet rotation in the universe could be wrong. (and not on just one day)

    What I meant is that in normal situation same coordinates for this four planets would happen again after that 3316390 days. But because of that system where two planets hit same spot their coordinates can jump forward this can possibly happen ealier then 3316390 days :D
    Let's assume that's the case and we had some coordinates (of this four planets) in day 1000 and in day 2000. Then if we search in day 1000 everything will be fine, synchronization will show to us 1000 spins. But if we are in day 2000 the synchronization will show us 1000 again so it will be wrong (cause for real we are 2000 days from start).

    And if I understand you right then of course if next day you only make one more spin so in tool you will have 1001 spins you still will have wrong data (cause for real it's day 2001 not 1001). But if you do the synchronization again (at day 2001) then tool will show proper number of 2001 spins cause the coordinates of four planets weren't seen before :D

    I hope I understood you well.

    • Official Post

    if you have a match then the next day will change nothing on that match, its move another day until you have a next match for an earlier state.

    so if you have any of these combinations once, you will get no further days / date anymore... you will just hit the same existing positions. And the problem with that it couldn't produce errors, because other galaxies dont move exactly to this one (because of the skips)


    If you say that you skip about 9years of rotation (without checking) and you take the next step, you would have the correct result, means after these 3,316,390days we could just check for the next "stage" or "epoch" or what you like to call this.


    i already got a blame post from a friend about this php code, now we like to play golf with that :D


    PHP
    <?php
for($i=1,$o=$s=[59,70,73,110];++$s[0]%$o[0]+(++$s[1]%$o[1])+(++$s[2]%$o[2])+(++$s[3]%$o[3])!=0;++$i){}
echo "\n\n found same state after $i \n\n";

    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)

    Thank you for your answer. Everyting works just as I expected.

    I already recreated whole rotation system and to get the current positions of planets in orbit.
    I also did as you suggest and created a new reference file cause rotating all 37093 planets 3450 times each it's taking couple seconds (couple seconds too long :D).

    So thank you for your answer and your work, it's great job and awsome tool.

    • Official Post
    Quote from Bald_Eagle

    That's why we need reference coordinates, to get the exact number of steps.

    could you explain (i don't looked into your tool so deeply) what a player has to do each day. Is this 4 coordinates copying step a thing what you have to do each day or do your tool supposed the state of the unvierse in a time difference?

    If this 4 coords copying is nessesary i would like to go the next step and implement for this a automatic json call to your script (we just has these for si classic, but i think its just a little step to also get this done for si2) - and i would give you the 4 coordonates during a login call that you exactly know the position of a universe.




    But if you - interpolate - the state, then its not such much "daily" work to get the tool running for a player :)

    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)

    • Official Post
    Quote from Bald_Eagle

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

    you can done normal http(s) calls to a page, then i would go that (its faster, if we implement the json auto calls (registered tool like you call it), we can switch back from this solution)


    https://spaceinvasion2.bitmeup.com/api/planet/sync/


    this is a json

    [

    {

    "coords" => [Coordinates], "g" => [GALAXY-XY], "s" => System-XY, "p" => Planet-XY

    }

    ...

    ]


    Example for today:

    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.

    • Official Post
    Quote from Bald_Eagle

    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.

    no, i think there is no planet without any collision :(

    what i could do is sending you the amount of rotations (like you calculate / try to find out) - i just have to increase this number for each successful rotation job i done at 4am - is this helping you?

    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 ;))

    • Official Post

    ok, didn't tested it fully, but it is just a increasement of a value :) i think that shouldnt be soo risky.


    same url, new structure see here: