RV Sonnenkreis - Decoding Universal Cartographics

[Esvandiary]

Jackie: Out of interest, are there any restrictions on what values should work with the "reverse" function originally in your 'scatterplot9' script?

I ripped it out and put it into EDTS without changing the logic, but occasionally some of the figures it comes out with are quite... unlikely
Specifically, I'm currently sat at a star ending in "IQ-Y d4", which comes out as (3240, 3160, 440), which is way outside the original sector.
For reference, the actual relative position of the star in its sector is approximately (690, 195, 120).

 

[Jackie Silver]

Jackie: Out of interest, are there any restrictions on what values should work with the "reverse" function originally in your 'scatterplot9' script?

I ripped it out and put it into EDTS without changing the logic, but occasionally some of the figures it comes out with are quite... unlikely
Specifically, I'm currently sat at a star ending in "IQ-Y d4", which comes out as (3240, 3160, 440), which is way outside the original sector.
For reference, the actual relative position of the star in its sector is approximately (690, 195, 120).

Bear with me, I will check.

(edited to add) Ignore my earlier, still looking.
There's a mistake in the code somewhere. Doh.
Breaking for tea, will do it from scratch later.

 

[Esvandiary]

Bear with me, I will check.

(edited to add) Ignore my earlier, still looking.
There's a mistake in the code somewhere. Doh.
Breaking for tea, will do it from scratch later.

No worries, I've known that feeling oh so well over the last week or so... It works perfectly, until you find the case that it doesn't work perfectly for.

Edit: I've found the problem! It's my mistake...
I forgot that the first number is "silent" if it's 0, so I was putting 4 in as number1 when in fact it should have been number2. It gives a good approximation if I use 0 as the first number.

Just pushed a version of my tools with a fixed regex that treats number1 as the optional one, not number2.

Apologies for sending you on a hunt for a problem that didn't exist!

Edit: Daaamn... Just added some profiling. On my desktop...

One-time initialisation on script load to re-organise some data into more querying-friendly form, at the cost of 2MB of RAM: 50ms
Average time taken to convert a single system name to approximate galactic coordinates: 250 microseconds (!)

Tasty.

 

[Vitamin Arrr]

A New Expanded Procgen Names Spreadsheet

BTW I created a 320 x 320 x 80 LY spreadsheet of A-sector procgen names in google drive. I would have made bigger, but I started running up against the limits of spreadsheet technology LOL.

Anyway this is good enough to give you the name of any C sector or larger within the smallish procgen sectors and it's a lot more sectors than what is in the ODS file that's in the main post of this thread.

Note: it's inverted, so that 0-0-0 is in the upper left, not lower right as it should be. I CBA to change that. LOL. You'll just have to do head logics.

If I get bored one day, I may add to this and somehow make a full 1280x1280x1280 grid.

https://docs.google.com/spreadsheets/d/1G6jin_BtWZftwRN-ACeGhgaBRXeMeNwUnPDyOcTdu1o/edit?usp=sharing

Decoder App Progress Update

Also, the decoder iOS app is coming along, have been working a lot so haven't had time to really perfect it yet, but this weekend I dove back into it to fix some crashes and clean up the UI a little bit. So I may put that out there fairly soon.

I've been trying to resolve some discrepancies that I may have found with the sector name decoding algorithm... still not sure if it's the algorithm, or just me. But it seems like it will be off sometimes. I've ruled out the idea that the border between "small hand-placed sector" and "normal procgen sector" could be a "fuzzy" or "overlapping" thing... no, borders are very strict, with no overlap really. The next question is whether there's any offset between the "starting point" for B-sectors, C-sectors, D-sectors, G-sectors in the hand-placed guys (you don't seem to get F- or H- in here). Let me know if you have any thoughts on that.

Also I'd like to give it the capability to e-mail a CSV file of all discoveries and maybe include the sector name decoding and absolute coordinates entry etc. We'll see where it goes.

Hand-Placed Sector Survey Update

I've been looking at some hand-placed sectors for Jackie to see what bias they might contain against the normal generation algorithm. I've also been looking to see how they work in relation to the sector naming conventions.

I also discovered (probably not the first to notice this though) that the "Col ##" sectors are like the hand-placed small NGC-### or M## sectors, but they are much bigger in radius, about 3x the size. The three small ones I measured are 400 LY in diameter, vs. 1180 on the one big guy that I measured. Another thing to note is that the center-point of the spherical hand-placed sectors tends to be the POI for the thing, (which is typically a handful of giants that you or I will NOT be the first discoverer of, sigh).

I'm in M-36 now, and at first I was excited to see they actually seemed to do it justice with a relatively large cluster of huge, blue stars (unlike NGC-1664 which only had like five of the seventy or more stars it's supposed to have). Sadly they've all been discovered, mostly by a certain International Moderator on this forum (unsurprising considering how it's only 4200 LY from Earth and the cluster is extremely prominent in the sky from anywhere around here).

Anyway, at 25 million years old, M-36 is one of the youngest clusters known outside of Tifrid. So I randomly picked a starting point relatively off the beaten path of the main cluster of hand-placeds, and began my survey there. From there, I will just go to the closest undiscovered system on my Navigation panel and record all available data on what stars I find there.

Jackie, how many would you consider a statistically relevant sample size? And do you want data on secondary stars or just the primaries?

 

[Vitamin Arrr]

Jackie: Out of interest, are there any restrictions on what values should work with the "reverse" function originally in your 'scatterplot9' script?

I ripped it out and put it into EDTS without changing the logic, but occasionally some of the figures it comes out with are quite... unlikely
Specifically, I'm currently sat at a star ending in "IQ-Y d4", which comes out as (3240, 3160, 440), which is way outside the original sector.
For reference, the actual relative position of the star in its sector is approximately (690, 195, 120).

The thing is, you have to enter that as "I Q Y D 0" and leave out the 4. On systems on the first row, there's an invisible zero (internally, it's really IQ-Y D0-4, but they drop the zero, just to be cute I guess).

When I enter it that way, I get the sector bounds:

640-720, 160-240, 80-160

That is consistent with your stated coordinates of 690, 195, 120.

 

[Esvandiary]

The thing is, you have to enter that as "I Q Y D 0" and leave out the 4. On systems on the first row, there's an invisible zero (internally, it's really IQ-Y D0-4, but they drop the zero, just to be cute I guess).

When I enter it that way, I get the sector bounds:

640-720, 160-240, 80-160

That is consistent with your stated coordinates of 690, 195, 120.

Yeah, I worked that out not long afterwards, and facepalmed appropriately.

Happily, every single "wrong" system from the EDSM data I've checked so far is wrong on EDSM's end, not mine... Only about 15 left to check, so looks promising!
I think my favourite one so far is a system that in-game is at Y=-25.000, but in EDSM is at Y=-25.03125. That's enough to put it into a different sector, which flagged it in my test!
I'm sure AnthorNet will love me throwing a big list of wrong data at him... I think I won't bother with the rounding error one since it's basically not wrong at all.

I haven't done much more looking at the single-word sector names yet, I think I might wait until grid lines and words like "Dryue" and "Ploe" don't haunt my dreams...

 

[Jackie Silver]

Jackie, how many would you consider a statistically relevant sample size? And do you want data on secondary stars or just the primaries?

I've mostly been collecting 50, or in a couple of cases 100 systems from a sector. The nav panel shows the closest fifty systems, provided those fifty systems are all in jump range, so I was heading to a start point, noting down the systems in the navpanel list, and then flying round them. I've been getting the system name, spectral type of all stars in the system and the general data (age/mass/radius/temperature) of the primary star only, plus I've been noting down how many asteroid belts / gas giants / terrestrials there are.

TBH a bigger sample size would be better, because this doesn't give much chance of seeing the distribution of more massive stars, but 50 systems at a time was the limit of my patience.

I haven't done much more looking at the single-word sector names yet, I think I might wait until grid lines and words like "Dryue" and "Ploe" don't haunt my dreams...

I'm super-stressed at the moment. I was this close to opening fire on someone (I won't say why) at the waypoint earlier*. Don't know how I've gotten into this awful mood but I need a short break.

I did rewrite my "read this system name into a position" code until it worked, so at least that was a good thing. I managed to confuse myself when I mashed two bits of code together and forgot I'd used the same global variable name for a different thing in each. Stoopid, but it clears up my earlier confusion when I was trying to understand what was happening.

CMDR Rikk has been flying ahead in a Clipper with roughly equivalent jump range to my Python (well, slightly better) and reports it as difficult but possible (and probably possible for lower jump ranges too) so I'll probably just jump quietly for a while in the direction of Out.



*If I truly was unscrupulous of course I wouldn't let on.

 

[Vitamin Arrr]

I've mostly been collecting 50, or in a couple of cases 100 systems from a sector. The nav panel shows the closest fifty systems, provided those fifty systems are all in jump range, so I was heading to a start point, noting down the systems in the navpanel list, and then flying round them. I've been getting the system name, spectral type of all stars in the system and the general data (age/mass/radius/temperature) of the primary star only, plus I've been noting down how many asteroid belts / gas giants / terrestrials there are.

TBH a bigger sample size would be better, because this doesn't give much chance of seeing the distribution of more massive stars, but 50 systems at a time was the limit of my patience.

OK will do. Note that Nav Panel only shows 50 systems when you're not in a super-dusty, low-visibility area. Sometimes if you're in a dark cloud you only see a handful sometimes.

 

[Vitamin Arrr]

The app based on Jackie's sector lookup code is coming along. Now with autocomplete, input validation, and nearby zone lookup Still got some bugs to work out and despaghettification of this code. Once it's presentable I'll post on github or whatever.

Spoiler

 

[Vitamin Arrr]

I did rewrite my "read this system name into a position" code until it worked, so at least that was a good thing.

On a side note... curious what changes you made and what aspect of this was not working before. I have been noticing what I might call a slight margin of error in the predictions of the algorithm, but I wasn't sure whether to chalk that up to the weird logic of handplaced sectors or some kind of stellar drift built into the forge... or a bug in the algorithm...

 

[Ziljan]

Vitamin - I have a very strong suspicion that the generation works slightly differently for the primary and secondary stars, because I often see secondary stars with age values that they never have when they are primaries - most notable the He Ae/Be which are always (?) age 2 MYr when primary but can have other ages when secondary. It's as if something which drives evolution across all stars in the system is tied to the evolution of the primary?

The primary star has the most mass, so it evolves faster than the other stars in the system. This evolution can involve mass exchanges between the main and secondary star(s). These mass exchanges can lead to the primary or secondary moving to a new classification while retaining its system wide age.

Michael Brooks recently revealed that the evolution of a system within the stellar forge is tied to it mass, age, and its position within the Galaxy. All the other factors of variation and population distribution flow from the initial mass function they used.

 

[Vitamin Arrr]

Ziljan- what I'm looking into for Jackie is whether or not these hand-placed sectors have a different distribution of star ages/types when it comes to the procgen stars, as compared with the generic, procedurally-named sectors. So far after surveying 22 in M36 I see nothing out of the ordinary...

Since a spot like M36 is supposed to be a hotbet of star birthing maybe we'd expect lots of 2 million year old stars... but that's not what I'm seeing so far...

 

[Ziljan]

If you look back even further in this thread, and another that Jackie posted a few weeks ago, there are definitely ages for stars that are a bit too old for their stated mass/evolution, unless they had experienced a midlife weight gain.

The exact ages for stars in proc gen star forming regions are not quite right since you'd expect them all to be roughly similar in age. Part of the wide spread in ages could be explained by older unrelated stars drifting into the nebulae, but that doesn't account for younger blue stars in a cluster that are still dramatically different in age. Braben mentioned recently on a lave radio interview that they were looking into fixing some errors in the stellar forge. Maybe this is one of them?

Also, these stars that share a common parent nebula should have roughly the same metallicity since they are made from the same material distribution, but by all available metrics for metallicity, there is a sizable variance in star forming regions.

edit: as for the hand placed systems, I think they have a much tighter distribution of ages within star forming regions. However it's important to remember that the estimated ages of catalogue stars are going to be impacted by our knowledge of them as a whole, whereas the proc gen stars will would have a smoother and wider distribution curve because they are generated statistically and without necessarily respecting their local relation to an existing nebula (which they should, but they don't seem to).

 

[Jackie Silver]

On a side note... curious what changes you made and what aspect of this was not working before. I have been noticing what I might call a slight margin of error in the predictions of the algorithm, but I wasn't sure whether to chalk that up to the weird logic of handplaced sectors or some kind of stellar drift built into the forge... or a bug in the algorithm...

I'd messed up my own copy of the script. Then I wrote it again from scratch and messed that up when I merged it with another one. Eventually I got it right, but it's not doing anything differently. Just me being dim.

The primary star has the most mass, so it evolves faster than the other stars in the system. This evolution can involve mass exchanges between the main and secondary star(s). These mass exchanges can lead to the primary or secondary moving to a new classification while retaining its system wide age.

Michael Brooks recently revealed that the evolution of a system within the stellar forge is tied to it mass, age, and its position within the Galaxy. All the other factors of variation and population distribution flow from the initial mass function they used.

That would be interesting, I suppose there's all sorts of ways that mass transfer could happen. My take on the Forge is usually to assume it's being simpler than it later turns out to be... Do you have a link for Michael's information, I haven't seen it.


I was looking at the progression of the first phonemes in the one-word sector names that being with consonants - there is a definite repeating sequence and I was able to get some small fragments of it. If I can work up the energy I'll have a go at it later today. Progress of a sort. I wasn't able to confirm how it progresses between one west-east line of sectors and the ones above/below and north/south of it, but that should be possible.
Alot, did you manage to convert the JSON data from EDDB into a sector map at all (or is there one somewhere)? I don't want to duplicate the effort if you've already done that!

 

[Esvandiary]

I was looking at the progression of the first phonemes in the one-word sector names that being with consonants - there is a definite repeating sequence and I was able to get some small fragments of it. If I can work up the energy I'll have a go at it later today. Progress of a sort. I wasn't able to confirm how it progresses between one west-east line of sectors and the ones above/below and north/south of it, but that should be possible.
Alot, did you manage to convert the JSON data from EDDB into a sector map at all (or is there one somewhere)? I don't want to duplicate the effort if you've already done that!

Sounds good re. the phonemes - I think I have a handle on the sequence within runs, I just haven't worked out how it chooses when to cut to a new run sometimes. I also have no idea how it decides where to jump into the list when it jumps between consonant prefixes and vowel prefixes... The subsequent phonemes don't seem to be related at all from what little I've looked!
In fact, the "I haven't yet worked out ..." list is still very long indeed.

As for converting EDDB data into a sector map, I'm not quite sure I follow what you mean... Do you mean actually visualising where the mapped EDDB systems are, or reorganising the data, or something else entirely? Either way I don't think I've done anything like that

 

[Jackie Silver]

Sounds good re. the phonemes - I think I have a handle on the sequence within runs, I just haven't worked out how it chooses when to cut to a new run sometimes. I also have no idea how it decides where to jump into the list when it jumps between consonant prefixes and vowel prefixes... The subsequent phonemes don't seem to be related at all from what little I've looked!
In fact, the "I haven't yet worked out ..." list is still very long indeed.

As for converting EDDB data into a sector map, I'm not quite sure I follow what you mean... Do you mean actually visualising where the mapped EDDB systems are, or reorganising the data, or something else entirely? Either way I don't think I've done anything like that

Heh, yeah, I've got no particular handle on how it decides which type of name to use - colouring the sector map by the different types gives some tantalising might-bes but nothing concrete. I was thinking of taking the EDDB data, extracting the sector locations from it (by checking into which 3d area a star in that sector falls, then assigning that star's sector name to that box) and then outputting a spreadsheet map of the sectors.

 

[Esvandiary]

Heh, yeah, I've got no particular handle on how it decides which type of name to use - colouring the sector map by the different types gives some tantalising might-bes but nothing concrete. I was thinking of taking the EDDB data, extracting the sector locations from it (by checking into which 3d area a star in that sector falls, then assigning that star's sector name to that box) and then outputting a spreadsheet map of the sectors.

Ahhhh, are you thinking to make the hunt for how the one-word names work a bit easier? I like it
I haven't done anything like that, no, but I could do if you like - EDTS (the tool suite my PG stuff is added to) has tools for reading/parsing the EDDB data so it'd be pretty easy to do.
I've also already got my test mode which checks all of the EDDB data to determine its coordinates, so it shouldn't be too hard to modify it to throw sector names out.

I can have a go at that, if you like?

 

[Ziljan]

Do you have a link for Michael's information, I haven't seen it.

The most recent dev interview on exploration including a few tidbits on upcoming changes, and verification on existing pet theories and wishes of mine including:

-driving SRV = exploration rank increase, higher the the further you are from Sol (but slow/supplemental gains in any case)
-exploration will become more risky in the future, including both natural and "unnatural" hazards. Shields recommended . And possibly weapons [heart]!!!
-AFMU were supposed to have weight, but they don't, and probably never will, whoops, lol (always wondered about it)
-The purpose of distant permit sectors... Dun, dun, dun
-The infinite range of the ADS was a mistake, and made exploration "too easy" but it seems we're stuck with it [noob][blah]:O[redface][downcast]
-Michael Brookes researches astrophysical journals/papers for his basis of knowledge in shaping the stellar forge [heart][heart][heart]
-The population, distribution, and even the number of the stars is a direct result of a highly detailed initial mass function and an input initial mass for the Galaxy. Does not say if this mass included dark matter (?).
-the properties of a system are based on the mass, age, and location of the system in the Galaxy

http://youtu.be/Gaoem7l1Qwg

I think they could "fix" the ADS situation by making high powered discovery scanner pings detectable by Thargoids. So sure you can still get infinite range, but you may also draw some unwanted and rather deadly attention to yourself. Maybe also a good way to pick a fight in the black? Lol.

 

[Jackie Silver]

Ahhhh, are you thinking to make the hunt for how the one-word names work a bit easier? I like it
I haven't done anything like that, no, but I could do if you like - EDTS (the tool suite my PG stuff is added to) has tools for reading/parsing the EDDB data so it'd be pretty easy to do.
I've also already got my test mode which checks all of the EDDB data to determine its coordinates, so it shouldn't be too hard to modify it to throw sector names out.

I can have a go at that, if you like?

Yes please, sounds good if you've got the tools ready to go.

 

[Esvandiary]

Yes please, sounds good if you've got the tools ready to go.

Et voila! This is a collection of CSVs, one for each Y slice. Full width and height, so lots of blanks around the edges.
The order is left-to-right in X and top-to-bottom in Z (i.e. the last row is Z=-24105, not the first).
I've restricted it to only show the one-word names to make it easier to track them; I can make one with all of them too if you like!