RV Sonnenkreis - Decoding Universal Cartographics

[Esvandiary]

I figure it's about time I posted in here...

I've been working on something Jackie's put on the backburner for now: determining how the sector names are chosen, and (hopefully) being able to identify exactly where they are in the galaxy from their name alone.
Perhaps unsurprisingly, that has turned out to be ... quite far from simples.

The names are built up from segments/phonemes, and there are (as far as I can tell) always either three or four phonemes that make up a name (e.g. Eodgols is "Eo" + "dg" + "o" + "ls").
The names appear to come in several classes which are handled differently:

Class 1a: single word, 4 phonemes (e.g. Eodgols)
Class 1b: single word, 3 phonemes (e.g. Froawns)
Class 2: two words, 4 phonemes total (e.g. Blu Ain)

Class 1
Class 1a and 1b sectors appear to follow one of several defined patterns as they move left-to-right across space at the same height. The prefix stays the same, with the last phoneme changing (Vegnuae, Vegni, Vegnao, Vegnau, ...)
Which sequence gets used appears to depend on whether the first letter of the sector name is a consonant or a vowel (likely so the names don't get too tongue-twistery). Not 100% sure on this, but I haven't found a counterexample yet.

The one exception is when a 1b set gets to the end of its suffixes. In that instance, a "d" is appended in the third slot, and it becomes a 1a, continuing rightwards with four phonemes. (e.g. Floanth, Floaphs, Floadue, Floadai)

You'll note the italics on some of the systems in that last example. This is due to the other part that makes this very unsimples: class 1 and class 2 runs occupy the same space. How it chooses whether any given sector is class 1 or class 2, I currently have no idea whatsoever. Suggestions very much appreciated.
What this means is that any sector effectively has two names: the name it actually has, and the name for the class that didn't get chosen. Byaa Theia is also Smojiae, Dryaea Aub is also Flyauwns.

This also makes it much harder to work out the sequences, because half of any given run is stuck under a load of Shrongio that you don't (currently) care about.

Class 2
Oh boy. Class 2 appears to always be four phonemes, and the way these are put together is... fun. I think Jackie's mentioned checkerboards in the past, well these are checkerboards within checkerboards three layers deep.
Short version: The first part of each word - phoneme 1 and 3 - is relatively persistent; they'll continue throughout a run (and often even continue at the stack above). Phonemes 2 and 4 will change using a pattern that I haven't yet had enough drinks to try and explain fully, but suffice to say: the pattern refreshes fully every 64 sectors.

Fortunately, phonemes 2 and 4 appear to follow the same rules as the suffixes for class 1, meaning they're predictable. Using this, I've managed to successfully compute names across a gap of ~40 sectors, and even have the run continue correctly to the next stack upwards in the same row (in a case where phonemes 1 and 3 were still the same).

Sequences I've got so far:
S1: ["oe", "io", "oea", "oi", "aa", "ua", "eia", "ae", "ooe", "oo", "a", "ue", "ai", "e", "iae", "oae", "ou", "uae", "i", "ao", "au", "o", "eae", "u", "aea", "ia", "ie", "eou", "aei", "ea", "uia", "oa", "aae", "eau", "ee"]
S2: [ ... , "gh", "lks", "sly", "lk", "ll", "rph", "ln", "", "rsts", "gs", "ls", "vvy", "ly", "rks", "qs", "rps", "gy", "wns", "lz", "nth", "phs"]

Things I haven't worked out yet
- Some of the sequences: I think S2 is missing some at the start, and there's at least one more, with "b", "c", "d" etc
- How the heck it decides which class to use for any given sector
- The width of the galaxy: some runs continue to the next stack up, which means they have to wrap somehow. Haven't got enough useful data yet to work out where the cutoff point is. Really hope it's consistent...
- How class 1 names are chosen (how does it decide that "Eumo" is at 1k out, a stack above the galactic plane?)
- Some other stuff I've forgotten

Hopefully this makes at least some sense...
I've got what code I've written so far as part of my existing tools (EDTS). The file I'm doing everything in is here (you might need to manually pick a newer commit if I've done more on it though). It's vaguely documented, but it's also still very WIP and everything may change.

 

[marx]

Ooh, very interesting. I've been wondering about this recently while surveying the southern edge of the galaxy. However, I think there are shorter region names too. But I might be wrong about their phonemes: so, how many are in "Viqs", "Soad" and "Blaed"? For example, is the first one three (v+i+qs), or is it two (vi+qs)?

Also, what you've written shares some interesting similarities with how FE2 generated systems and their names. More info on that (including disassembled code) here. I for one quite like how they changed from unique system names to unique sector names. I am somewhat afraid that ED also uses a random seed to determine the name to use for any given sector, though - but then, there are often similarly-named regions next to each other.

 

[Esvandiary]

Ooh, very interesting. I've been wondering about this recently while surveying the southern edge of the galaxy. However, I think there are shorter region names too. But I might be wrong about their phonemes: so, how many are in "Viqs", "Soad" and "Blaed"? For example, is the first one three (v+i+qs), or is it two (vi+qs)?

Looks like three in all cases:

>>> import pgnames
>>> pgnames.get_fragments("Viqs")
['V', 'i', 'qs']
>>> pgnames.get_fragments("Soad")
['S', 'oa', 'd']
>>> pgnames.get_fragments("Blaed")
['Bl', 'ae', 'd']

I've just updated the URL in my post to a new version - I realised that in the version I originally posted, the full list was in a separate file that I hadn't committed! D'oh.
I've put the full list into the main file now.

Also, what you've written shares some interesting similarities with how FE2 generated systems and their names. More info on that (including disassembled code) here. I for one quite like how they changed from unique system names to unique sector names. I am somewhat afraid that ED also uses a random seed to determine the name to use for any given sector, though - but then, there are often similarly-named regions next to each other.

It's been a while since I've read that Jongware page, sounds like I should give it another look! Thanks for the link.
Yeah, from what I've seen so far I think you might be right about the random seed for which one to use... I haven't found any discernable logic so far, other than "whichever one I want it to be to work out more of this sequence, not that one"

 

[Jackie Silver]

I checked back through my old stuff and found these, I've got a nagging feeling I got (a little) further so will keep looking. Unfortunately I've got files scattered all over the place on different computers and memory sticks!

Phonemes

Sector board

I keep saying I'll update the sector map further. At the very least I ought to extend it to cover the ones we're passing through on DW!

 

[Esvandiary]

I checked back through my old stuff and found these, I've got a nagging feeling I got (a little) further so will keep looking. Unfortunately I've got files scattered all over the place on different computers and memory sticks!

Phonemes

Sector board

I keep saying I'll update the sector map further. At the very least I ought to extend it to cover the ones we're passing through on DW!

Very useful - that's got quite a few bits that I didn't have yet.

I definitely think it's worth checking more above/below the plane and out near the edges. It's all relatively well-behaved near the middle!
Specifically, I dare you to make sense of the sector names out on the very far eastern edge, east of Dryau Aowsy. (Even more specifically, Dryue Flye and Dryeou Flaae, as well as the Dryua Ploe out of nowhere - you'll see what I mean)

Edit: Quick note from one of your spreadsheets: I think the galaxy may be 64 sectors wide (sector starting at -41025 --> sector starting at 39615).
Edit 2: Scratch that, just spotted a few stars west of -41025

OK, furthest west I've found is at about -42210 (Sphiesi HX-L d7-0)
Furthest east: ~40505 (Ood Fleau ZJ-I d9-0)

65 sectors. That throws a spanner in the works

This may all be moot. One observation I made is that the galaxy map stops scrolling westwards at X=-49985, which is the edge of a cube. Confusingly, however, where it stops scrolling eastwards (X=50015) is not the edge of a cube.
The -Z axis also lines up (it stops at Z=-24105, 19 sectors from the "zero" one at Z=215). +Z doesn't match (it ends at 75895, which is 1/8 of a cube).
The Y axis doesn't seem to match at all from what I can tell (Y=-10985 to 9015).

More evidence for this: going outwards in Z from the near side of the galaxy, the class 2 sector prefixes follow the usual checkerboard pattern. Starting from as far in -Z as we can see, that pattern goes:
Ph, Hyp, Ph, Eo, Dry, Eo, Dry, Hyp, Ph, Hyp, Ph, Pl, Pr, ...
Note the pattern - we're "starting" halfway through it. If we continue that pattern back to its logical start:
Eo, Dry, Eo, Dry, Hyp, Ph, Hyp, Ph, Eo, Dry, Eo, Dry, Hyp, Ph, Hyp, Ph, Pl, Pr, ...
... guess where the first "Eo" starts? Z=-24105!

So, at least for Z, I believe the pattern starts at the very end of the galaxy, not where the first stars show up.
I don't know if I agree with that as far as X goes, but I don't really yet have enough evidence either way. What I've seen so far mildly points to there being a cutoff in the east before the "hard" stop at 50k, but that could just be confirmation bias on my part.

Further edit: If anyone can work out how Class 1 (single-word) names decide which list of suffixes to use... That'd be very helpful.

 

[Jackie Silver]

Here is a slightly updated version of the on-plane sectors map. I plan to map the Core region more thoroughly including the various sectors above and below the plane, but it's time-consuming. Hopefully that will give us more insight as to the 3d nature of the name progressions. Esvandiary, you've managed to find stars much higher and lower on the plane than I could. I thought there were only five or six layers of sectors.
(I always think of "north-south" as y, "east-west" as x and "up-down" as z, but I probably shouldn't, or confusion will ensue...)

Here is the latest update to the ship's log. I've finally finished updating all the old systems that didn't have radius and temperature measurements and have checked and corrected yet more mistakes. I've added some more details on proc-gen S and MS stars from universal cartographics.

This is my latest take on the evolution of young stars.

It looks like there's a boundary ("baron") at 210 MYr after which TTs become VZ stars, approximately bounded on its upper edge ("ace") by Mass = 4.5 * (age**-0.3)
After 240 MYr ("snoopy") the VZ stars become main sequence stars, bounded by ("pumpkin") at Mass = 54 * (age**-0.4) on its upper edge, above which there's only stellar remnants.
Remnant nebulae tend to be found between 250 MYr and 300 MYr which suggests that 250 MYr is another boundary, possibly an enforced limit on the age of evolved stars.

Black holes and neutron masses have been doubled to represent the mass of the progenitor, in-line with previous findings based on the mass code boundaries. It's possible the values are slightly off but they should be close.

I've been trying to gather more data on high mass TTs and low mass B0 VZ stars to firm up the position of the "ace" line. There's a stray main sequence star between 210 and 240 MYr, I need to recheck that. I'm on the lookout for any more low-mass primary VZ stars we can get, to see whether they also fit. Any nebulae which are lower or higher than the band indicated would be interesting to see - I don't think the existence of this band precludes them in any way, but still.

I'm not sure what's going on with the thin band of main sequence stars at the high-mass end of the VZ area. Need more data for that.

Incidental music: The Stone Roses (self-titled), The Charlatans (Between 10th and 11th)

 

[Esvandiary]

Here is a slightly updated version of the on-plane sectors map. I plan to map the Core region more thoroughly including the various sectors above and below the plane, but it's time-consuming. Hopefully that will give us more insight as to the 3d nature of the name progressions. Esvandiary, you've managed to find stars much higher and lower on the plane than I could. I thought there were only five or six layers of sectors.
(I always think of "north-south" as y, "east-west" as x and "up-down" as z, but I probably shouldn't, or confusion will ensue...)

For clarity: I've only found stars in six sectors in the up-down p) axis, starting at -3865 through to starting at 2535 (and those mentioned ones are only populated sparsely, if at all). My numbers in my last post, other than the ones mentioning specific stars, were for how far the galaxy map lets you scroll before stopping.
I've just had a quick look this morning (and I'll look more thoroughly this evening), but I might have a start of an idea of how the progressions work. Still have many foibles to work out, mind. If I don't find any glaring counterexamples this evening I'll edit this post to write it up.

Edit: Yeeaaaahhhhhh! Never mind the write-up for now, I should go to bed. But I'll leave you with this...

λ python pgnames.py search2 "Praea Scrua"
1,30
start1 = o, start2 = oe
idx = 39
MATCH: Sector(0, 1, 30), [-65.0000, 1255.0000, 38615.0000]

Progress!

More edit: and after integrating Jackie's code...

λ python pgnames.py search2 "Prae Flyao XC-Q b10-3"
-2,30
start1 = ua, start2 = ua
-1,30
start1 = ua, start2 = e
MATCH: Prae Flyao, Sector(5, -1, 30), origin: [6335.0000, -1305.0000, 38615.0000]
Est. position of Prae Flyao XC-Q b10-3: [6885.0000, -295.0000, 38845.0000] (+/- 10Ly)

Now to add the required data so it can actually work for any set of prefixes...

 

[Jackie Silver]

Very curious to know how you're getting on, Alot! I've been continuing to map sectors and try to find sequences, but I'm hoping you've got it all worked out...

 

[Esvandiary]

Very curious to know how you're getting on, Alot! I've been continuing to map sectors and try to find sequences, but I'm hoping you've got it all worked out...

Good timing This just popped out of my testing mode...

Totals: OK = 25644, bad = 13, none1 = 39235, none2 = 0, notPG = 65279

That's the result of throwing the entire system list from EDDB at it (which is sourced from EDSM), with a few filters to remove sector names that look like PG ones but aren't (e.g. Col 359, Snake, ICZ etc)
"OK" means it determined it was part of a PG sector, found it and the EDDB/EDSM position fell within the determined sector position.
"Bad" means it did the above process, but the position didn't fall within the sector (more on that later).
"None1" means it determined it was a one-word PG sector, but didn't have the data to process it. That's currently all one-word sectors, I haven't got a good enough understanding of how those are placed yet.
"None2" means it found a two-word PG sector, but didn't have data to process it.
"NotPG" means what it sounds like - it didn't match the PG sector regex, so probably a named system.

Which means... Out of a little over 25000 sectors it can currently process, it got all but 13 of them correct!
... except on closer inspection, it turns out my tool was absolutely correct in all those cases, and the EDSM data was wrong. Perfect score.

Now I've got this far, I'll do more of a write-up in the morning, but a few bits for now on assumptions I've made that so far have held:
- The galaxy "starts" at X=-49985, and likely at Z=-24105. No idea on Y, but my tool isn't bothered, if there's data for extra Y levels it'll use it.
- That 64-long repeating pattern? It repeats again after 64. Checkerboards for days. (This explains the weird stuff over on the arm directly east of Dryau Aowsy)
- For any given prefix (first word or second word), the position at which the pattern starts is consistent. Note, however, that each prefix (usually) has two positions that it can start from, depending on the Y value.

This gave me enough that the data needed to calculate it all was reasonable... There are definitely more patterns in there (and thus the potential for more automation and less data), but they seem just inconsistent enough to be unhelpful.

Anyway, the source for the version I just pushed is here... It's a mild mess at the moment, but it should work.
Most of the scripts in there are irrelevant, the new ones for this are: pgnames.py (the main logic), pgdata.py (reams of data) and sector.py (a simple sector class)

Simple invocation looks like...
python pgnames.py search2 "Dryau Aowsy CT-G d11-5220"

There are lots of useful functions in the class itself, but everything's a bit of a mess. Here's me trying a few things just now:
>>> import pgnames
>>> from vector3 import Vector3
>>> from sector import Sector
>>> pgnames.c2_get_name(Sector(0,0,11))
['Bl', 'u', 'Ai', 'n']
>>> pgnames.get_sector("Dryau Aowsy")
Sector(0, 0, 14)
>>> s = pgnames.get_sector(Vector3(500,-400,15000))
>>> pgnames.c2_get_name(s)
['Bl', 'ae', 'Ph', 'oe']

Anyway, I'll write more about this in the morning, I've spent enough time in the galmap this evening that I'll be seeing gridlines on the way to bed.

 

[Jackie Silver]

Impressive! Can you reproduce the whole galaxy map? Kicking myself for not getting the data from EDSM. I must know the details!

(+virtual rep)

(Doh, I should read closer - we do need more info on the one word sectors, then? I got some more info on the progressions but I should start looking at the EDSM data.)

 

[Vitamin Arrr]

So here's a hypothesis: perhaps they chose to do suppression due to the fact that in many areas closer to Sol there are a fair amount of hand-placed systems from the HIP, HD, BD, TYC, NGC catalogs, which (the further you get from Sol) contain increasingly only giants (and often enough black holes and neutron stars).

Often at the intersection of the randomly named 1024 LY^3 sectors you'll have spherical sectors of radius 512 LY named NGC #### Sector, or M## Sector, (or similar), that should feature a cluster of catalog stars (that are mainly giants) interspersed with procgens etc. (I say "should" because FD got lazy on many of these, it seems, and has ommitted most of the catalog stars, even ones that are accepted as being part of the cluster and whose location is known to a high degree of precision. Perhaps "lazy" is not the best term since I'm sure they work hard, as evidenced by the accurate placement of Eta Carinae right inside its nebula where it belongs .. cough.)

I am guessing their thinking was that if they didn't suppress the procgen biggies in sectors heavy with hand-placed/catalog-placed biggies (HIP, HD, etc.), then we'd end up with tilted ratios in those; but farther out from Sol where the catalog pickins are slim, they turned up the Forge to compensate on the massive end of the scale.

I've been gathering data from a few particularly young such "intersection" sectors (very young clusters according to Wikipedia). I'm finding the youngest age of the procgen star systems (esp. F and E lettered ones; there tend not to be H's and few G's to be consistent with the advertised age of these sectors.

I'm still compiling data on it but I have found stuff like: http://www.elitegalaxyonline.com/object-view/?object_id=13948
... a 114-million-year-old Class F procgen star.

I'm heading back out, so let me know what kind of data mining you want me to do in these "corner clusters".

 

[Esvandiary]

Impressive! Can you reproduce the whole galaxy map? Kicking myself for not getting the data from EDSM. I must know the details!

(+virtual rep)

(Doh, I should read closer - we do need more info on the one word sectors, then? I got some more info on the progressions but I should start looking at the EDSM data.)

I just edited my previous post with a bit more info. (A bit, not a lot yet )

The more data we have on the one-word sectors the better; I spotted a few could-be-patterns whilst they were getting in the way of me looking at two-word ones, but I'm still slightly at a loss there.

I can reproduce the whole galaxy map for two-word names, yep!

 

[iain666]

I say "should" because FD got lazy on many of these, it seems, and has ommitted most of the catalog stars.

It may be more that a lot of catalogue stars have very poorly constrained distances - I think FD have arbitrarily hand placed some of the more well known stars with large error bars on their distance but have just left most of them out because we only have a very vague idea where they actually are - however certain we are of what line they lie on.

 

[Esvandiary]

OK, attempt at an explanation for the two-word system incoming... I'm going to have to refer back to the code at times I think, I've probably forgotten the bits I worked out near the start

Quick terminology for clarity: a word is... well, a word ("Dryao"), a prefix is the first part of a word (whether the first word or the second!), a suffix is the other half of a word.
A "run" is a sequence of 64 systems going from -X to +X, in a recursively-growing checkerboard pattern described in the c2_run_states variable. This is probably a good time to mention that FD seem to really like recursively-growing checkerboard patterns. They are everywhere. So many times I've got a bit more data to find that yep, that big checkerboard actually had a bigger checkerboard outside it. Freakin' Matryoshka dolls, I swear.
One other thing: I did my sector coords with zero at the "base" offset coords at [-65, -25, 215]. This has the slightly odd side-effect that Sol is actually in sector (0, 0, -1).

Best as I can tell, each Z slice is a self-contained unit, unaffected by what's either side of it except for deciding the set of prefixes which will be used in that slice. I don't claim to know enough to completely rule out continuations between Z slices, but I haven't seen any compelling evidence for it.
As mentioned, each Z slice has a set of prefixes (both for word 1 and word 2), decided in a checkerboard pattern going from -Z, starting at Z=-24105. The checkerboard pattern is relatively simple, my code for it is shown below:

Spoiler

c2_positions_y0z_offset = 19
c2_positions_y0z = [
(("Eo", "Dry"), ("Th", "Eu")), # SPECULATION
(("Hyp", "Ph" ), ("Th", "Eu")),
(("Eo", "Dry"), ("Ae", "Ai")),
(("Hyp", "Ph" ), ("Ae", "Ai")),
(("Pl", "Pr" ), ("Th", "Eu")),
(("Bl", "By" ), ("Th", "Eu")),
(("Pl", "Pr" ), ("Ae", "Ai")),
(("Bl", "By" ), ("Ae", "Ai")),
(("Eo", "Dry"), ("Ao", "Au")),
(("Hyp", "Ph" ), ("Ao", "Au")),
(("Eo", "Dry"), ("Chr", "Br")),
(("Hyp", "Ph" ), ("Chr", "Br")),
(("Pl", "Pr" ), ("Ao", "Au")),
(("Bl", "By" ), ("Ao", "Au")),
(("Pl", "Pr" ), ("Chr", "Br")),
(("Bl", "By" ), ("Chr", "Br")),
(("Ch", "Pyr"), ("Th", "Eu")),
(("Syr", "My" ), ("Th", "Eu"))
]

The observant might note that those prefixes are the ones used around Y=0, which isn't where the pattern starts. I stored it in this way for familiarity/easily being able to find the right indexes, since I knew I'd need some sort of mapping later anyway.
Let's take one as an example... (("Bl", "By"), ("Ae", "Ai")). This means going in consecutive sectors "forwards" in Z you'll get Blu Aewsy, Byeia Aewsy, Blu Ain, Byeia Ain. Due to the one-word names popping in you won't actually see all of those, but Blu Ain and Byeia Ain might look familiar to some explorers. Note that some of the checkerboards in these algorithms go the other way - going [0,0], [0,1], [1,0], [1,1] rather than [0,0], [1,0], [0,1], [1,1] as this one does.

Right, so now we can take each Z slice as an individual unit. This is where it starts to get tricky, and it took me quite a while to get a handle on what was going on.
Important to know from the start: the order of prefixes is important; I think I've got the full set (count is 111), but happy to be corrected. There are also several different lists of suffixes; one-word and two-word names partially follow the same lists, but in some cases the two-word lists are subsets of the full list.
The discoveries that allowed me to make this work: firstly, everything starts at X=-49985, and secondly, each prefix only has 2-3 different "start points" that it can ever start a run from. Blu Thua is at X=0, so is Blu Ain. The "Blu" is in the same place on both, despite them being thousands of Ly apart. Those start points are generally multiples of 8 suffixes apart (and that sometimes even holds between different lists of suffixes). The start points are also completely independent of the other word in the name.

That got the data requirements down to a manageable level: there aren't that many prefixes that are actually used in the two-word names, even across both words. So I got a few examples, proved that it worked, and worked out the run starts for all of the visible prefixes. Given the patterns found in the prefix/suffix starts I could probably hazard guesses about the values beyond where there are stars, but I've mostly left them empty for now.
I did this by using a script which would print out the full run when given a potential starting name. Thus, I could adjust the start name until all the visible sector names matched the ones generated in my list in the right positions.

There are still a few oddities; a few prefixes (Eae, Phl, Fly, Ae) appear to use their own special sublists of the ones they should be using, which took a while to nail down.
Naturally, this is almost certainly still imperfect - feel free to throw weird systems at it and see what breaks.

I'll endeavour to add some more comments to the code soon... Right now the commenting is relatively light and probably more useful for me than anyone else. Latest version so far is here.
Also apologies for all the crucial bits of information that I've inevitably forgotten to include... I've been neck-deep in this for quite some time, so I've probably assumed lots of knowledge that nobody else actually has yet.

Any questions? ... *opens floodgates*

 

[Jackie Silver]

Here is the latest version of my on-plane sector map. Here is the latest version of the suffix lists.
I'll keep trying to flesh them out.

Alot, I'm humbled. And happy.
It may be that the one-word sector name beginnings are chosen from such a long list that we simply need to find them all, though it does seem to repeat in places (e.g. WREGOE near Sol, WRUETHOO on the other side of the galaxy) and there's a general alphabetic sense to it.

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?
If you have the time (I appreciate they're tedious to do!) you could do one of the hopefully unbiased complete surveys of systems that I've been doing - pick a random star within the cluster (I've been getting the ones closest to points where the coordinates are divisible by 100, so that the survey isn't skewed by my picking a shiny star to begin with) and then survey all systems within jump range of that system. It would be interesting to see whether the ratios of system types - i.e. the IMF of the cluster - are consistent within these handplaced clusters, because there are huge variations elsewhere.

 

[Esvandiary]

Here is the latest version of my on-plane sector map. Here is the latest version of the suffix lists.
I'll keep trying to flesh them out.

Alot, I'm humbled. And happy.
It may be that the one-word sector name beginnings are chosen from such a long list that we simply need to find them all, though it does seem to repeat in places (e.g. WREGOE near Sol, WRUETHOO on the other side of the galaxy) and there's a general alphabetic sense to it.

Thanks!

Just for reference, I think I have the suffix lists down for class 1 also, although I may of course be completely wrong. I need to try it out on some of the more challenging sectors.
The main thing I'm missing for class 1 is just context... Seeing how the names progress at different Y levels especially - I've seen one case where Pueloe was two stacks directly above Kueloe, which hopefully is not a coincidence!
I'm hoping that armed with the knowledge about starting at X=-49985, I can get some more sense out of class 1 now.

I've updated my code with some additional comments (and a few changes to some rather misleading variable names ) here... The actual pgdata script containing all my prefix/suffix lists, as well as the class 2 Y mappings, is here.

Edit: Forgot to mention... Any insight as to how it chooses which of the consonant-ish suffix lists to use for any given name would be very appreciated. I'm still completely stumped on that...

 

[Jackie Silver]

I've seen one case where Pueloe was two stacks directly above Kueloe, which hopefully is not a coincidence!

Next to that we have FROARKS above FLOARPS; RKS is 2 places before RKS in the suffix list. I'm guessing that the PUELOE above KUELOE is a point where the prefix list is in sync with the suffix list, and that around this point things get progressively more out-of-sync?

 

[Esvandiary]

Next to that we have FROARKS above FLOARPS; RKS is 2 places before RKS in the suffix list. I'm guessing that the PUELOE above KUELOE is a point where the prefix list is in sync with the suffix list, and that around this point things get progressively more out-of-sync?

I was somewhat tempting fate by saying that; myself and a group of friends have a jokey saying when solving puzzles: "it can't be a coincidence!" ... because it almost always is.

From what I've seen so far class 1 is definitely a little more ... unpredictable.
For instance, going along a run we have Vegni, Vegnao, Vegnau ... Weqo. On the plus side the prefixes/infixes in that instance do repeat (it goes Veq-, Vegn-, Weq-, Wegn-), but it seems to have picked a suffix out of mid-air to switch at.

Oh well, I'm sure all will be revealed in due course.

 

[Athan]

So here's a hypothesis: perhaps they chose to do suppression due to the fact that in many areas closer to Sol there are a fair amount of hand-placed systems from the HIP, HD, BD, TYC, NGC catalogs, which (the further you get from Sol) contain increasingly only giants (and often enough black holes and neutron stars).

Often at the intersection of the randomly named 1024 LY^3 sectors you'll have spherical sectors of radius 512 LY named NGC #### Sector, or M## Sector, (or similar), that should feature a cluster of catalog stars (that are mainly giants) interspersed with procgens etc. (I say "should" because FD got lazy on many of these, it seems, and has ommitted most of the catalog stars, even ones that are accepted as being part of the cluster and whose location is known to a high degree of precision. Perhaps "lazy" is not the best term since I'm sure they work hard, as evidenced by the accurate placement of Eta Carinae right inside its nebula where it belongs .. cough.)

I am guessing their thinking was that if they didn't suppress the procgen biggies in sectors heavy with hand-placed/catalog-placed biggies (HIP, HD, etc.), then we'd end up with tilted ratios in those; but farther out from Sol where the catalog pickins are slim, they turned up the Forge to compensate on the massive end of the scale.

I'd been assuming that when generating the stars in a given volume of space the game first checks for any absolute overrides (hand placed stars), then PG's until each volume of space is at the correct density (given both the absolute overrides and these PG'd stars), then checks for any name overrides, then otherwise applies the PG names.

Point being that how many stars are in a given sector/volume of space will be determined by an algorithm, and 100% override stars take precedence on achieving that density. So, it's not "oh we have X hand-placed stars here, let's manually tune down the number of PG stars".

 

[Jackie Silver]

I realised I was mistaken there anyway, as the FROARKS - FLOARPS thing is over only one up-down level and the PUELOE - KUELOE is over two levels. Doh.