[Theory] StellarForge tracks Stars through their entire lifecycle

[Bernaue]

UPDATED:

Incorrect Premise:
"Previous research by individual commanders (Jackie Silver, Alot and other Commanders [1]) claims that only AA-A boxels can contain a H size system, and that there should only be one H size system per boxel." [2][3]

Corrected Premise:
A common misconception existing regarding the mass code in a system name. IMO, this is due to lack of clarification in any existing documentation about system naming and boxels. [2][3]

We should start by addressing this issue. The mass code does not specify the mass of the system, but the starting mass of the boxel the system is in.
This means it can be treated as the upper bound of mass for the system, but does not define the lower bound.

Previous research by individual commanders (Jackie Silver, Alot and other Commanders [1]) claims that only boxels located at AA-A can have a mass of size H. [2][3]



Lingering Misconception:
The misconception also means that people often believe there can only be one system per sector with the H mass code in its name.
This is also incorrect and can be addressed with a clear explanation of how systems are named.


A system name is split into five parts: [Sector Name] [L0][L1]-[L2] [Mass Code][L Overflow Counter]-[System Number]
The layout is intentionally counterintuitive, so I have broken it down:

Sector Name	Easy enough to understand. The name of the sector the boxel and system are in.
L0, L1, L2	These are more complicated and will be explained in detail after this breakdown. All you need to know for now is they are part of how the boxel's location is represented.
Mass Code	The starting mass of the boxel the system is in on a scale of A to H, where A is the smallest and H is the largest.
L Overflow Counter	Yet again, a complicated part to be explained in detail after this breakdown. All you need to know for now is it is part of how the boxel's location is represented.
System Number	Each boxel has a mass that it distributes into randomly generated systems until it runs out. The first system is numbered 0, the second is numbered 1, the third is numbered 2, and so on...

So what are L0, L1, L2, and L Overflow Counter?

We should start with the fact that L0, L1, and L2 are a single number in base26 and displayed in reverse as letters, where A = 0 and Z = 25.
So what we see (YE-A) can be reverted back to a base10 number by following this example:
YE-A -> A-EY -> A, E, Y -> 0, 4, 24 -> 0 x 26 x 26, 4 x 26, 24 -> 0, 104, 24 -> 0 + 104 + 24 -> 128

But why did we do that?	Because it tells us that YE-A is boxel number 128.
Isn't there up to 128 x 128 x 128 A size boxels per sector?	Yes, and you might have already spotted the problem; Three base26 digits isn't anywhere near enough to count up to 128^3. 128^3 = 2,097,152 ZZ-Z = 17,576
So what does the game do when it reaches ZZ-Z + 1?	That's where the L Overflow Counter we've not talked about yet comes in. L Overflow Counter is a base10 number and it starts counting from 0. When the game reaches ZZ-Z + 1 it resets to AA-A and increments L Overflow Counter by 1.

That was quite the detour from the main point of this post, but it's important that we clarify that there can be more than one system with a boxel mass code of H in its name.



Unhelpful System Name Abbreviations:
There's still two really relevant problem to address, and this is the first one.
The game abbreviates system names that have 0 in. Here's some examples:
H0-0 becomes H
H0-1 becomes H1
And so on...



System Name Overflow:
The other relevant problem is how you can overflow the bounds of a sector when searching for a system name.
For example, Col 70 Sector BA-A H shouldn't exist because you can only fit one H size boxel per sector.
Unfortunately, due to how the game handles boxels, it sees this as a valid input and takes you to the H boxel in the next sector along.

I don't understand how exactly this issue works, but although the game will see BA-A H as a valid input, it isn't a valid system and the game overflows to the next sector along.

This issue is exasperated by a change to the galaxy map with Odyssey that will show virtual systems in your search results.



Why did Frontier make the virtual systems visible in the results if they lead to incorrect / overflow results?
That's because some of them are valid and lead to galactic POIs, e.g. Nebulas.

For example, Col 70 Sector has 66 systems in its H size boxel;

• 3 take you to actual systems.
• 8 take you to the centre of a nebula on the galaxy map.
• 55 take you to empty points in space on the galaxy map.

These results suggest that the StellarForge actually tracks Stars through their entire lifecycle.

Lifecycle

                  Star
                    |
                Supernova
         /          |          \
Neutron Star    Black Hole    Diffuse Nebula

Nebula Centres

COL 70 SECTOR AA-A H3     586 -426 -1079    RUNNING MAN NEBULA
COL 70 SECTOR AA-A H4     594 -432 -1072    ORION NEBULA
COL 70 SECTOR AA-A H5     650 -432 -1281    HORSEHEAD NEBULA
COL 70 SECTOR AA-A H6     626 -403 -1200    FLAME NEBULA
COL 70 SECTOR AA-A H7     540 -322 -1138    MESSIER 78
COL 70 SECTOR AA-A H8     624 -426 -1229    BARNARD'S LOOP
COL 70 SECTOR AA-A H9     596 -312 -1340    ORION DARK REGION
COL 70 SECTOR AA-A H10    608 -405 -1194    HORSEHEAD DARK REGION

References
[1] - https://forums.frontier.co.uk/threa...h-their-entire-lifecycle.621311/post-10263922
[2] - https://github.com/Intergalactic-As...master/ED_System_identifiers_notes_-_Rev1.pdf
[3] - http://disc.thargoid.space/Sector_Naming

Spoiler: Original Post

Previous research by IGAU and individual commanders claims that only AA-A boxels can contain a H size system, and that there should only be one H size per boxel. [1][2]

However, I believe that the Galaxy Map was changed since this research took place, and that we can now search for things that are not system names.

For example, Col 70 Sector BA-A H shouldn't exist according to existing research, or even reference an actual system. However, if we search for it in the Galaxy Map it takes us to the system Upsilon Orionis.

And there should not be a COL 70 SECTOR AA-A H66, yet if we search for it we are given a star as the result, and it takes you to an empty point in the galaxy map.

But the best part is not odd "impossible" names pointing to empty points in space, but several that show in the results as stars and take you to the centre of a nebula.

These results suggest that the StellarForge actually tracks Stars through their entire lifecycle.

Lifecycle

                  Star
                    |
                Supernova
         /          |          \
Neutron Star    Black Hole    Diffuse Nebula

Nebula Centres

COL 70 SECTOR AA-A H0-3     586 -426 -1079    RUNNING MAN NEBULA
COL 70 SECTOR AA-A H0-4     594 -432 -1072    ORION NEBULA
COL 70 SECTOR AA-A H0-5     650 -432 -1281    HORSEHEAD NEBULA
COL 70 SECTOR AA-A H0-6     626 -403 -1200    FLAME NEBULA
COL 70 SECTOR AA-A H0-7     540 -322 -1138    MESSIER 78
COL 70 SECTOR AA-A H0-8     624 -426 -1229    BARNARD'S LOOP
COL 70 SECTOR AA-A H0-9     596 -312 -1340    ORION DARK REGION
COL 70 SECTOR AA-A H0-10    608 -405 -1194    HORSEHEAD DARK REGION

References
[1] - https://github.com/Intergalactic-As...master/ED_System_identifiers_notes_-_Rev1.pdf
[2] - http://disc.thargoid.space/Sector_Naming

 

[Ian Doncaster]

Nebulae being one possible H-mass object is more obvious in the fully procedural sectors - Eol Prou AA-A h89 is probably the most famous one.

Whether this is a result of tracking star lifecycle or diffuse nebulae being a separate class of heavy object would probably need someone familiar with the code to answer.

Col 70 Sector BA-A H shouldn't exist according to existing research

And doesn't as the canonical name of a system - but you can extend the naming scheme outside the normal bounds of the canonical sector and the coordinate transformation algorithm will still work so the map references it and may find an actual star.

So for example Eol Prou AA-A h1 is a high mass black hole within Eol Prou - all normal.
Eol Prou BA-A h1 doesn't exist as such, but the BA-A transformation moves the coordinate search box one H-region to the right, so you get Eoch Pruae AA-A h1.
Eol Prou CA-A h1 moves the coordinate search another H-region right, so you get to Leamue AA-A h1, and so on.

With the appropriate understanding of the numbers, you can do things like get an address for Sag A* within Core Sys Sector (I saw someone do this once but it was years ago so I can't find the actual numbers now, and I'm not good enough with them to replicate it)

This has worked for years but I suspect the references above are only considering canonical naming rather than the many aliases a system can have.

 

[marx]

It wasn't IGAU, as the Forge's naming system (and others) were well established by Jackie Silver, Alot and other Commanders, years before we founded the squadron. (Note that I'm no longer in it.) The only thing that has changed with the search came with Odyssey and its search bar now listing even "virtual" systems on its candidate lists, so we can verify which ones are really there. The underlying mechanisms are the same though, and if you searched for hidden systems before, the game would take you to them anyway. Note that this is different from tricking the search to go outside a given sector by giving it incorrect names... but more on this later.

Let me go back to the basics first. First, within various spheres, the displayed name of a system is overridden from its proc. gen. name. This is usually around nebulae, but not always. (As another example, real-life clusters from various catalogues, especially NGC, can be found as open clusters in the game.) Having the word "sector" in the system name is a dead give-away of this. Now, the "coordinate letters" also change with this renaming: you don't end up with "Spiral Planetary Sector AA-A d" after going from "Pro Eurl AA-A d". Perhaps the best example is the "Bleia5 YE-A h30" nebula. (Note that the distant unknown permit lock spheres don't have the "Sector" word in them.)

Systems can have multiple names too, with one getting to the top of the hierarchy. In the ones that you wrote, as "Col 70 Sector AA-A h3" would be a rename already. Real-world catalogue stars that were imported from more than one catalogue also have all their names in the game, so searching for the different names will correctly take you to the same star if it's in HD and HIP both. Things can get messy with overlapping sectors in a few places around the bubble: for example, while there is a North America nebula, due to various overlapping rename spheres there, and the B352 Nebula's closest system was thus assigned to the North America Sector. Oops.

There are also singular manual system renames, like how "Ceeckia ZQ-L c24-0" is now displayed as "Beagle Point". The underlying name is the same though. (Interestingly enough, when the name was first introduced in a beta, the contents of the system were accidentally regenerated - most likely they forgot to add a displayed name override, and just modified the system name directly, thus changing the seed.)
Finally, in this part, systems that were manually added by Frontier (such as Sol!) can also have a proc. gen. name generated from their system ID, and the search will take you to them. In that case, it's "Wregoe AC-D d12-0".


Next, due to the way the search function works, it was always possible to "trick" it with names outside of the correct ranges, to go beyond the given sector. Like Ian Doncaster wrote above, you can get it to point you to Sagittarius A* from the Wregoe sector in the bubble. (I can't seem to find the exact example though, and it's not something I could tell you off the top of my head.) The search function won't pop you an error if you trick it to go outside the sector: instead, it'll take you to a system if it finds a suitable one near enough to where you told it to search.

Finally, it's pretty well established that the Forge tracks stars and their systems through their entire life. If memory serves, this has even been explicitly said by Frontier fairly early on, and as far as I know, to date there has been zero evidence that would have proven this false.
As you noted, generated nebulae are also products of this: you'll see the large nebulae as mass code H only, while the smaller planetary nebulae are all from mass code E. The only thing that did change was that Odyssey's new search not only worked with "virtual" or "hidden" systems as before, but now also displayed them in the new search bar, where it can give you a list of candidates. (This wasn't present before.) This was also very good for looking at the mass code H culling below the galactic plane - see here (the last question) for more detail.

Going by the Journal API docs, the nebula center systems are hidden systems that you can't visit, with either a "Nebula" or a "StellarRemnantNebula" main star. In the case of the planetary nebulae, the system you can visit (with the remnant main star) and the nebula you can see (with most likely the "StellarRemnantNebula" main star) are actually two different systems. You can see this by the displayed nebula name too: note that it will be one number off from the system instead. For example, the "Dryooe Flyou YT-A e1844" system has the "Dryooe Flyou YT-A e1845" nebula around it.


Hm. This turned out longer than I originally thought. I hope I covered everything relevant, but if you have any further questions, feel free to ask!

 

[marx]

Oh, a minor thing that slipped my mind: for the overrides around imported real nebulae, the game replaces the word "Nebula" with "Sector", which can lead to some fun results. My favourite is "Struve's Lost Sector", but there's also "Blinking Sector" and "Red Spider Sector", and, uh, "Spiral Planetary Sector".

 

[Bernaue]

Thanks @marx and @Ian Doncaster!

You've helped a bunch in clarifying some stuff that I haven't managed to find information on anywhere.

I'll rewrite op tomorrow with the corrections and extra info (with credits of course).

 

[marx]

Alrighty, time for a reply to your updated post then.

First off, why does the search allow you to feed it incorrect / out-of-bounds results? I think it's because Frontier have always wanted it to be as quick as possible, as that's important for users, and validating the input first would slow it down. There's also a case to be made for skipping this, namely that the typical usage case is that somebody searches for an actual system that they do know exists - either a non-procedural name ("Sol"), or a procedural system they've been to / seen. Of course, a player can also make a mistake, either by a simple typo or misremembering the procedural name... but then the search taking them to an incorrect system outside the sector might even be helpful, as it can show the user that they may have made a mistake.
So in my opinion, there isn't much of a case to be made for slowing down the search in order to validate whether the proc. gen. name was correct.
There's still a bit of filtering going on though: there are debug systems which aren't returned for search, nor are they shown on the galaxy map(!). For example, the TEST and TEST2 systems have sometimes appeared in betas as mission destinations. (I recall people saying that you can actually see these stars rendered in the skybox, but I've never tested that myself.)

Second, about AA-A h boxels: it might help if you think of the 1280 ly^3 cubes as sectors, and the mass code H boxels as the subsector that happens to be the same as the entire sector, because it's a 1280 ly^3 cube too.
Unfortunately, the "[English text] Sector" system name overrides are misleading here, because they aren't cubes aligned with the galactic grid (of boxels), but spheres of varying radius instead. In addition, they can reach outside of boxel boundaries too, and as I mentioned earlier, they might even overlap with other override spheres. You can see that happening a lot around the bubble. Jackie Silver's old map program illustrates this perfectly. (Well, while it's old, the only changes by Frontier since then were that specific renames of various stuff, the override spheres are the same.)

Moving back to searching a bit: the search bar also has some issues with searching sectors far away from where you are, especially if they have a low system count - typically near / at the edges of the galaxy. @ORANGEORANGE has an excellent post illustrating this here. It's worth reading the whole thing, but here's the relevant part for finding out if a sector has no systems:

OK, then how do I check if a star is in the sector? With the search bar, but not so fast. You can't just paste the sector name into the search bar and know straight away always. The following is the decision tree to determine if the sector is empty or not.

• If you paste the unrecorded sector name into the search bar and results appear, then you know that systems exist in that sector.
• If no results appear, then no conclusion can be made yet! That is because in low systems count sectors, the search bar is artificially suppressed!
  • Target a star in a neighboring sector. Now paste the sectorname followed by A. e.g. "Sectorname A". If results appear, then you know that systems exist in that sector.
  • If no results appear, repeat with B, then C, and so on, until you have exhausted the entire alphabet [A-Z]. If results appear for any letter, then you know that systems exist in that sector.
    • If after exhausting the entire alphabet there are still no results, then there are no systems in that sector.

The targeting a star in a neighboring sector is necessary to allow real searches. If "NO RESULTS FOUND" is displayed immediately, then the system did not actually search. If "NO RESULTS FOUND" is displayed after approximately 0.75 seconds, which should occur after targeting a nearby star, then the system did actually search and genuinely found no systems with "Sectorname X" as the starting string.

Granted, this is an edge case (sorry for the pun), but it's still good to know.

Also, about mass codes and stars. They are quite useful for determining the possible main star types of systems in a boxel: for more on this, see this thread. A possible problem, which I mentioned there too, is that the suppression zone can produce some "weird" (otherwise not produced) combinations.

Finally, about you referring to, and using, the "Col 70 Sector" systems: don't forget that that's a name override sphere, and not the actual sector (or AA-A h boxel) itself. The real name of the systems would be Synuefe instead... although it might also overlap into the Synuefai sector as well. If you want a cleaner case of override spheres spanning more than one sector, take a look at the EDAstro map for the PRAEI[1-6] permit lock spheres far to the North, it's eminently visible with them.
To be honest, because of these issues, and because of all the manually added stuff (including nebulae!), you're better off looking at more distant sectors which have no override spheres in them, than with looking around the bubble.


But anyway, all these are just extra details and information; the main point, namely that the Stellar Forge simulates the entire history of a star system and nebulae both large and small are generated during this, is correct. You can also see this in how planets (and moons) in the remnant systems tend to be like.