Snap @William @toddumptious All we need now are 16 responses : )
3 Likes
Hey hey hey, Iâm a little late today so I might have missed someone else saying it, but did System count 161 entries because itâs counting its own entry? The glitched photo it posted yesterday with the title âsync 17:04â? 17:04 was a sync time that at least 5 operators captured yesterday
5 Likes
Time captured at 17:16:02 UTC+1 (16:16 UTC) 06:48 in-game (margin error of +2 seconds)
And got one captured at 17:16:16 UTC+1 for the magical 16:16:16 UTC reporting 06:59 in-game time @William
4 Likes
Same as me every time.
1 Like
Wow. If your assumption is right, one of these primes wouldnât appear in the windows list.
Someone suggested it may have counted the top row of the table. I think they asked about it in an email to System.
4 Likes
I checked, and they all match up with known Operators. But it does show that System attempted to sync with us at least once, at one of the times that was predicted by the flow charts (even though it chose kind of a random timeâŚ)
I wonder if thereâs clues hidden in that glitched image but am definitely not smart enough to figure it out myself
3 Likes
Yeah, there are 160 rows of actual data excluding the headers.
The 161 referenced on the structural analysis page may be a typo, or you could be right, System may be counting their own connection attempt. Interesting flavor at the very least!
Also! Iâve compiled a list of all missing UTC times that have either been excluded, or that we havenât submitted yet. As we go throughout the day, maybe we can try to get some of these in!
I imagine Archie is probably aiming for a complete 24-hour cycle?
MISSING UTC TIMES:
01:36
03:44
04:16
04:48
05:04
05:20
05:52
06:24
06:40
06:56
07:28
07:44
08:16
08:32
08:48
09:04
09:20
09:36
09:52
10:08
10:24
10:40
11:12 through 15:44
16:16
21:04
22:24
edit: But donât focus ONLY on these times, because The Architect made it clear that System needs multiple data points for each UTC time, so keep submitting what you can when you can!
With that said, these are the times which only have ONE submission so far:
SINGLE-SUBMISSION UTC TIMES (we need more):
0:32
0:48
1:04
1:52
2:08
2:24
2:40
3:12
4:00
6:08
16:32
21:20
21:36
21:52
22:08
22:40
9 Likes
Moving a conversation over that follows this email
So be prepared
5 Likes
This is good news, a lot of us already have the data recorded for 00:00 UTC so might be a good one to aim for.
Unless there is a better one to include that suits all timezones that doesnât have people in work or fast asleep.
1 Like
Same UTC isnât the best idea from Architect. There is always a part of the Operators who will need to be ingame in the middle of the night or during working time.
2 Likes
I dont think he means for us to pick just one, just requested that we sync the same UTC from many points. Having a lot of data tied to several UTC times or the ones that have the highest attach rate might be more beneficial to System.
We could submit several UTC that have many points tied to them already/or will soon, perhaps. Thatâs what Iâm suggesting here anyway
1 Like
As I can understand in Archiesâs message, he thinks that System want to know what time it is everywhere in Euclid at the same time, same UTC then, to understand the âwhole shared dream universeâ. And same UTC will naturally be boring for a part of us. Of course if it needs only 10 or 20 thatâs not a big trouble but if 100âŚ
1 Like
The last Mail from System is possibly an answer to my own mail few mn before:
Hello System,
After reading your exchange with the Architect yesterday, we had started gathering data on â0/0â timestamps taken during synchronization moments throughout the shared dream. However, the Architect is now asking us to do this ALL AT THE SAME UTC TIME. Is that really what you need? I wonât deny that itâs not strictly impossible, but you will inevitably get far fewer results for the simple reason thatâno matter which UTC time is chosenâit will be inconvenient for some operators (due to night hours, work shifts, etc.). So, I wanted to know if we should discard the data already collected (since it wonât be at the âright UTC timeâ), or if the Architect perhaps misunderstood your request and the data is valid as long as the reading is taken at a sync point and at â0/0.â
If you could confirm or clarify this one way or the other, that would be perfectâso we know how to proceed.
Your Operator 41
So we donât formally use the same UTC.
1 Like
Isnât this what we did 18 hours ago? Was that not enough data?
A post was merged into an existing topic: 
Contact Coordination - Emails To The Architect
Maybe the players who have differences in time are using mods or save edits and stuff causing their instances to be out of sync?
i am unsure as i play on PlayStation, but maybe mods to the game do things towards the predicted code output and causes problems with the time sync.
Imagine how all the players who have multiplayer turned on feel when and after the pc player who shows up with their 1000 + part corvette that they have copy pasted from a list. Something like that would probably cause a lot of unintended problems, or if the designer was nasty the problems could be on purpose.
Time Sync may not be affected by mods and save edits at all, i donât know for sure, i donât code.
2 Likes
I have noticed that people reporting time differences/inconsistencies (for those who also have timestamps on their screenshots filename) are taking their screenshots beyond the 16 second margin of error which in some cases can put them a full 40 mins or an hour of in game time ahead than what is expected. E.g for 00:00 UTC some people took their screenshots at 00:00:56 (hh:mm:ss)
6 Likes
I guess it also depends how they are taking screenshots, and if there is any lag, or they are trying anticipate the lag of taking the shot.
Its far easier to just watch your mobile phone tick over the exact time and instantly just look at the in game time in the visor, and note it. Far more accurate, no lag trying to take the screenshot, its not really needed.
Anyway, going a bit off topic.
5 Likes