What says the ruins found today where ruins 2. maybe they where 3 or 4? we dont know
Alien archeology and other mysteries: Thread 9 - The Canonn
- Thread starter Ian Phillips
- Start date
- Status
What says the ruins found today where ruins 2. maybe they where 3 or 4? we dont know
The problem is its based on powers of 2 and that simply doesn't match the coords. -29 and -30 are not powers of 2
I'm doing a run allown -32 from -128 to 128 as well. then the same on 32 on 7 D
So in my research at the first ruins location, I found the following about one of the two "extra" obelisks: When starting with no scans (fresh mission), if I scan C38 with a Tablet then I will get the same scan data as I would if I scanned C13 with the Tablet. If I then try to scan C13, I don't get any data (nor an error). It *appears* (at least, it did it for me) that those two are interchangeable. I tried doing a similar substitution with G19 (trying it with all the combinations for G17, G18 and G20), but had no luck.
WE ARE CHAMPION !!!!! (handball )
LOL... the ruin is exactly the same.. in every detail, even the damage to the walls is a copy.
Im feeling....... like..... someone at Fdev can't be bothered.
I was honestly expecting the site to look different, at least different enough to have some degree of encoded information hinting towards a grander puzzle, worthy of the effort that this community has put into this Brain trust of a thread. But its just a copy and paste asset flip.
I am disappoint.
--
Im holding out for this being ANOTHER bug.
Im feeling....... like..... someone at Fdev can't be bothered.
I was honestly expecting the site to look different, at least different enough to have some degree of encoded information hinting towards a grander puzzle, worthy of the effort that this community has put into this Brain trust of a thread. But its just a copy and paste asset flip.
I am disappoint.
--
Im holding out for this being ANOTHER bug.
I think its bugged because sometimes you do not get a message so they become out of sync.
This is what I gathered on my 5 or 6 runs of the mission.
About the "the two that dont give data..." : actually they give data. Check my previous posts :
here : https://forums.frontier.co.uk/showt...9-The-Canonn?p=5075596&viewfull=1#post5075596
and here for more details :https://forums.frontier.co.uk/showt...9-The-Canonn?p=5075629&viewfull=1#post5075629
Hope that helps a bit.
Longitude is an arbitrary measurement, latitude is not.
I have a hard time thinking the devs would make us search these other systems without realizing a bug as significant as a total duplicate ruins site being that a DEV HAD to manually place i there, or maybe it was randomly generated. i dont know, but if this was meant for us to intentionally brute force discover all other sites and they use the same layout to make it easier to discover, but someone is seriously lacking imagination on the FDev team and im a little upset because this could be a very immersive story line, instead it seems cheap and wasteful, just a easy way to farm creds.
- - - Updated - - -
Maybe to humans,, What about the way aliens think. could be a total odd ball of a discovery
- - - Updated - - -
Maybe to humans,, What about the way aliens think. could be a total odd ball of a discovery
Do you have money troubles
Damn, looks like the BLoop (humour me!) will be setting over site 2 this evening:
Excuse my bad splice job there!
The moon chases BLoop down to the horizon.
Looks like Barnards Loop will also set over the large circler at this (2nd) site.
Would love to be there to confirm it, but I'm about to be AFK for 4 hours.
If anyone who is at the site (2nd ruins) and see's BLoop dropping below the horizon, I would appreciate it if they could post a screenie of it here!
Likewise with the moon setting at 2nd site.
Ideally, whilst I'm asking, from the tip of the "centre ridge", more or less the middle point of the ruins.
I may be back in time to do it myself, but then again, may not.
Excuse my bad splice job there!
The moon chases BLoop down to the horizon.
Looks like Barnards Loop will also set over the large circler at this (2nd) site.
Would love to be there to confirm it, but I'm about to be AFK for 4 hours.
If anyone who is at the site (2nd ruins) and see's BLoop dropping below the horizon, I would appreciate it if they could post a screenie of it here!
Likewise with the moon setting at 2nd site.
Ideally, whilst I'm asking, from the tip of the "centre ridge", more or less the middle point of the ruins.
I may be back in time to do it myself, but then again, may not.
Last edited:
Alright, since I will probably not have much time to work on this for the next week or two, I will post everything I have found out about the strings encoded in the sound the obelisks make.
First off, the 2 hours and 5 minutes recording I made yesterday gave us the following 55 strings: [Warning: huge picture]
Based on that and my last recording made at the same obelisk and roughly at the same time, I have come up with a logical way of how to separate the string into individual tokens.
Here is a picture of what the tokens look like:
I noticed that all of these tokens are in-fact time-aligned. And would you know it, they are time aligned to a 0.5 second beat. Then, using the big X token as a "start counting from here" kind of measure, I was able to effectively and relatively easily divide the whole string into separate tokens. Here is a picture of how that looks like:
the [END] here being the terminating block, which is 100% the same for every string.
So, naturally I already started to convert the alien strings into something us humans would be able to read. A very crude example is below:
The corresponding series of tokens for that string would be: LLHBLLVLHSVLHSLSLLLVB[END]
However, I think the length of the "L" tokens may be important.
If enough data is converted into this readable form, perhaps it would be much easier to find any patterns?
In any case, I will be leaving all of my data and thoughts here: https://www.dropbox.com/s/340v7uy01e4wlmd/28_01_2017_E1_Solo_2h5m.rar?dl=0
for anyone to use and ponder over. It contains all the strings individually and a couple more of token-ized strings.
Below are a few more of my *scribbles* of madness about the topic, but if you are serious about looking more into this, it is a good read anyways.
Now here is the big question everyone is probably asking by now: What are these strings any good for, anyways?
It is true that they do not seem to repeat in a loop, even after 2 hours of recording I don't think I saw any 2 strings being identical. However, what if these strings are somehow encrypted or maybe the data they contain is tied to what time it is, or perhaps the data is a set of distance and directional data for other sites? There are so many reasons why the data could be constantly changing, and whereas this will definitely make the cracking of this code significantly harder - it is not impossible (at least I would hope so... FD...), think of how the Enigma Machine was finally cracked during WW2 - the data was very well encrypted, typing 2 letters in a row would give different answers, basically... so I think we may be up against something similar.
If anyone gets any ideas or suggestions on how to approach this, then they are certainly most welcome... however as I said, I will unfortunately not be able to work on this for a while now.
First off, the 2 hours and 5 minutes recording I made yesterday gave us the following 55 strings: [Warning: huge picture]
Based on that and my last recording made at the same obelisk and roughly at the same time, I have come up with a logical way of how to separate the string into individual tokens.
Here is a picture of what the tokens look like:
I noticed that all of these tokens are in-fact time-aligned. And would you know it, they are time aligned to a 0.5 second beat. Then, using the big X token as a "start counting from here" kind of measure, I was able to effectively and relatively easily divide the whole string into separate tokens. Here is a picture of how that looks like:
So, naturally I already started to convert the alien strings into something us humans would be able to read. A very crude example is below:
However, I think the length of the "L" tokens may be important.
If enough data is converted into this readable form, perhaps it would be much easier to find any patterns?
In any case, I will be leaving all of my data and thoughts here: https://www.dropbox.com/s/340v7uy01e4wlmd/28_01_2017_E1_Solo_2h5m.rar?dl=0
for anyone to use and ponder over. It contains all the strings individually and a couple more of token-ized strings.
Below are a few more of my *scribbles* of madness about the topic, but if you are serious about looking more into this, it is a good read anyways.
Rules for these serial strings:
1) No token may appear twice in a row, the only exception to this is the horizontal lines and the "separator bar" in one specific case. In case of horizontal lines, the new horizontal line unit has a different pitch than the one preceding. In case of "separator bar", this can happen only just before the "terminating block", because the "terminating block" always starts with a "separator bar".
2) The tokens are time-aligned to a "beat" of around 0.5 seconds. Sometimes the token may be slightly off sync, however, in that case the surrounding tokens are out of sync as well, and the difference is easily seen. The biggest culprit of desyncing is the "vertical bar" token which very often seems to bleed over to the next token.
3) No string of tokens can be smaller than the terminating block neither in time length nor the token count.
4*) It is possible that the horizontal lines and the other tokens are not 100% self-excluding, however for the most part they do appear to be never really happening at the same time - the few cases where the horizontal lines start or end inside another token could simply be the game itself not ending the tokens properly.
Wild guesses on how to approach the data:
1) Start reading from the right, instead of the left, At least time-aligning the strings (then visually dividing them into tokens) is A LOT easier to do when approached from the right.
Observations:
1) The horizontal lines (except for in the terminating block) seem to mostly have lengths of 1.5sec, 2.5sec or 3.5 sec, however if I have not failed with actually seperating the string into tokens at some points(which is still possible, obviously), then rarely a 2sec or 3sec long horizontal line token also appears.
2) The low bar tokens are usually 1.5sec long, however a couple seem more like they are 2sec long.
3) If the above point is simply observer bias or something like that, then in some cases (usually for the longer strings) it seems like there is a 0.5sec "beat" missing from somewhere. So far the desync and the missing "beat" only happen when a lot of non-horizontal-line tokens are in succession.
V - vertical bar (1sec)
B - low bar (1.5sec || 2sec?)
H - high bar (1sec)
S - seperator bar (1.5sec)
L - horizontal line (1.5sec or longer), exception is in the terminating block where 2 1 second lines are observed.
(X - that big blob at the end of every string (3sec))
[obelisk]: [Mode]: [Metadata(which audio clip)]:
[END] = SLLLLX
E1: Solo: Clanga2h5m.flac: string1: LLHBLLVLHSVLHSLSLLLVB[END]
E1: Solo: Clanga2h5m.flac: string2: LVLLVHVLBHVLVHLSLBHLLL[END]
E1: Solo: Clanga2h5m.flac: string3: HLHBLBHLBLLHSVBSLBVL[END]
E1: Solo: Clanga2h5m.flac: string4: LVLLLBVLBLLLLSVLBLBH[END]
E1: Solo: Clanga2h5m.flac: string5: LLLLHVBHVBVSLLVBHLLHLBVLHLLS[END]
E1: Solo: Clanga2h5m.flac: string15: SVHLLLLB[END]
E1: Solo: Clanga2h5m.flac: string55: BLHBLSHLLLSBVSVLVBLVHLLSLBLBLVBVBHLLHLHVLSLLHL[END]
Alternatively: BLHBLSHLLLSBVSVLVBLVHLLSLBLBLLVBVBHLLHLHVLSLLHL[END]
1) No token may appear twice in a row, the only exception to this is the horizontal lines and the "separator bar" in one specific case. In case of horizontal lines, the new horizontal line unit has a different pitch than the one preceding. In case of "separator bar", this can happen only just before the "terminating block", because the "terminating block" always starts with a "separator bar".
2) The tokens are time-aligned to a "beat" of around 0.5 seconds. Sometimes the token may be slightly off sync, however, in that case the surrounding tokens are out of sync as well, and the difference is easily seen. The biggest culprit of desyncing is the "vertical bar" token which very often seems to bleed over to the next token.
3) No string of tokens can be smaller than the terminating block neither in time length nor the token count.
4*) It is possible that the horizontal lines and the other tokens are not 100% self-excluding, however for the most part they do appear to be never really happening at the same time - the few cases where the horizontal lines start or end inside another token could simply be the game itself not ending the tokens properly.
Wild guesses on how to approach the data:
1) Start reading from the right, instead of the left, At least time-aligning the strings (then visually dividing them into tokens) is A LOT easier to do when approached from the right.
Observations:
1) The horizontal lines (except for in the terminating block) seem to mostly have lengths of 1.5sec, 2.5sec or 3.5 sec, however if I have not failed with actually seperating the string into tokens at some points(which is still possible, obviously), then rarely a 2sec or 3sec long horizontal line token also appears.
2) The low bar tokens are usually 1.5sec long, however a couple seem more like they are 2sec long.
3) If the above point is simply observer bias or something like that, then in some cases (usually for the longer strings) it seems like there is a 0.5sec "beat" missing from somewhere. So far the desync and the missing "beat" only happen when a lot of non-horizontal-line tokens are in succession.
V - vertical bar (1sec)
B - low bar (1.5sec || 2sec?)
H - high bar (1sec)
S - seperator bar (1.5sec)
L - horizontal line (1.5sec or longer), exception is in the terminating block where 2 1 second lines are observed.
(X - that big blob at the end of every string (3sec))
[obelisk]: [Mode]: [Metadata(which audio clip)]:
[END] = SLLLLX
E1: Solo: Clanga2h5m.flac: string1: LLHBLLVLHSVLHSLSLLLVB[END]
E1: Solo: Clanga2h5m.flac: string2: LVLLVHVLBHVLVHLSLBHLLL[END]
E1: Solo: Clanga2h5m.flac: string3: HLHBLBHLBLLHSVBSLBVL[END]
E1: Solo: Clanga2h5m.flac: string4: LVLLLBVLBLLLLSVLBLBH[END]
E1: Solo: Clanga2h5m.flac: string5: LLLLHVBHVBVSLLVBHLLHLBVLHLLS[END]
E1: Solo: Clanga2h5m.flac: string15: SVHLLLLB[END]
E1: Solo: Clanga2h5m.flac: string55: BLHBLSHLLLSBVSVLVBLVHLLSLBLBLVBVBHLLHLHVLSLLHL[END]
Alternatively: BLHBLSHLLLSBVSVLVBLVHLLSLBLBLLVBVBHLLHLHVLSLLHL[END]
Now here is the big question everyone is probably asking by now: What are these strings any good for, anyways?
It is true that they do not seem to repeat in a loop, even after 2 hours of recording I don't think I saw any 2 strings being identical. However, what if these strings are somehow encrypted or maybe the data they contain is tied to what time it is, or perhaps the data is a set of distance and directional data for other sites? There are so many reasons why the data could be constantly changing, and whereas this will definitely make the cracking of this code significantly harder - it is not impossible (at least I would hope so... FD...), think of how the Enigma Machine was finally cracked during WW2 - the data was very well encrypted, typing 2 letters in a row would give different answers, basically... so I think we may be up against something similar.
If anyone gets any ideas or suggestions on how to approach this, then they are certainly most welcome... however as I said, I will unfortunately not be able to work on this for a while now.
Last edited:
I don't think you understand what you are replying to.
This is a headline feature. Launched with this image which in itself gives away a vast number of surprises and interest.
It's not the junior devs that need questioning. The person in charge of this entire line of project should be at Braben's place right now explaining what has gone on to avoid losing their post. I would be spitting blood and fire if this was my game and it had gone out live like this - all that was needed was for the responsible senior dev in charge to go into Open post launch and fly to each site to check each one was there, working and different.
Nobody did it. At all. That's pretty obvious - every cmdr has seen the same thing and gotten the same result so anyone going to check this stuff would have found the same.
Last edited:
Latitude is based on the fixed positions of the poles as the axis of rotation and therefore based on absolute physical properties.
The measurement units might be arbitrary but the basis of the measurement is not regardless of thought modes.
Longitude on the other hand can have an arbitrary zero point anywhere around the globe.
nice work Commander !
my problem with that is that ruin site 1 and ruin site 2 are almost a straight line from Meene. So I reckon if ruin site 1 was supposed to be 2 then ruin site 2 we just found is actually ruin site 3 and there is another ruin site 1 between Meene and ruin site 1 and the fourth will be after ruin site 2 which should be 3.
Er, more whiskey please!
Well, it would appear my angst toward FD is justified and shared. hopefully they will address this awful development tomorrow. Until then, I say make youselves some money off this nonsense.
Last edited:
- Status