Difference between revisions of "Sector Naming"

From DISC Wiki
Jump to: navigation, search
Line 32: Line 32:
 
Let's use an example: '''Synookio DA-Q b19-7'''
 
Let's use an example: '''Synookio DA-Q b19-7'''
  
The sector name is '''Synookio'''. This uniquely identifies the sector of space this system is in, within the galaxy as a whole. (More on that later!)
+
The sector name is '''Synookio'''. This uniquely identifies the sector of space this system is in, within the galaxy as a whole. (More on that later!)<br/>
 
The system identifier is '''DA-Q b19-7'''. This specifies approximately where ''within the Synookio sector'' this system is.
 
The system identifier is '''DA-Q b19-7'''. This specifies approximately where ''within the Synookio sector'' this system is.
  

Revision as of 11:15, 16 May 2016

Sector Naming
Decoding the names and positions of procedurally generated star systems
Project Details
Status Mostly Complete
Primary Contributors Jackie Silver
Alot
Reference Code Alot's EDTS branch

Background

Before getting to the meat of the problem, it's important to have a good idea of how the procedurally generated parts of the E:D galaxy is laid out.

The galaxy is divided into sectors, each of which have a unique name; each sector is a cube, 1280x1280x1280Ly in size. Every procedurally-generated system in the galaxy belongs to exactly one PG sector, although due to the presence of hand-crafted content, a system may not bear the name of the PG sector it's actually part of.

For example, both Sol and Col 285 Sector FH-I b11-1 are actually in the Wregoe sector. The latter example is slightly confusing: despite having the same form as a fully procedurally generated system, the sector itself (Col 285) is hand-placed and "overrides" the Wregoe systems that would normally appear there.

These sectors do not align neatly to the coordinate space we know and love; the nearest sector "corner" boundary to Sol is at coordinates [-65, -25, 215]. The reason for this oddity is potentially explained by knowing that Frontier internally appear to use different coordinates which put Sol at [49985, 40985, 24105]. The boundary coordinates shown earlier match a coordinate system with such an origin (e.g. 49985-65 is a multiple of 1280).

Sectors are essentially an ordered list, starting from the "bottom-left-near" corner - that is, the corner where all coordinates are smallest. The list starts from this position, and goes left-to-right (X axis), then bottom-to-top (Y axis), then near-to-far (Z axis).

Within sectors, systems will be given a unique designation, specified by the sequence of letters and numbers after the sector name.

TODO: More here I haven't thought of?

Decoding a System Name

Let's use an example: Synookio DA-Q b19-7

The sector name is Synookio. This uniquely identifies the sector of space this system is in, within the galaxy as a whole. (More on that later!)
The system identifier is DA-Q b19-7. This specifies approximately where within the Synookio sector this system is.

The form of the system identifier is usually the same: [L1][L2]-[L3] [MCode][N1]-[N2]. The only exception is when N1 is 0 (described later), when the form becomes [L1][L2]-[L3] [MCode][N2].
L1, L2 and L3 are always single uppercase letters. MCode is always a single lowercase letter between 'a' and 'h', and N1 and N2 are numbers (of arbitrary size). Note that in dense sectors, N2 can get to very high numbers (in the thousands).

Boxel sizes by MCode
a 10Ly (2M/sector)
b 20Ly (262k/sector)
c 40Ly (32k/sector)
d 80Ly (4k/sector)
e 160Ly (512/sector)
f 320Ly (64/sector)
g 640Ly (8/sector)
h 1280Ly (1/sector)

The 1280x1280x1280Ly sector is split into sub-cubes, or boxels (as named by Vitamin Arrr). The MCode determines how large those boxels are; the table to the right shows the exact figures. For a given MCode, the boxels are essentially an ordered list of cubes, behaving exactly the same as sectors do. However, there is one slightly confusing aspect to this: for any given sector, the grid of boxels is always 128x128x128 in size, regardless of how large those boxels actually are. This can result in some combinations being completely invalid due to the boxel position actually being outside the current sector. This is, fortunately, easily detectable.

For a given MCode 'n', the bottom-left-near sector is AA-A n0-1; note that as described earlier, this would actually appear in-game as "AA-A n1". N2 is not relevant to the decoding - 1 is used as an example.

From here, we move left-to-right, incrementing the pattern starting with L1: AA-A n1, BA-A n1, CA-A n1, ...
When reaching the far edge 128 boxels later at XE-A n1, we move up a level and start again from the left with YE-A n1. Similarly, when reaching the end of the top stack, we move "out" one Z-axis column and start from the bottom-left again.

The pattern increments each letter while it can, in turn: AA-A, BA-A, CA-A, ..., YA-A, ZA-A, AB-A, BB-A, ..., YZ-A, ZZ-A, AA-B, BA-B, ...
When it runs out of letters completely, N1 finally comes into play: YZ-Z n0-1, ZZ-Z n0-1, AA-A n1-1, BA-A n1-1, ...

Due to the wildly different numbers of sectors in each mass code, the maximum valid N1 value can be very different: for a mass code of 'a' N1 can go as high as 119, whereas for 'g' and 'h' it can never be anything other than 0.

Reference code for calculating the within-sector offset of a given system identifier can be found in the get_star_relative_position function in pgnames.py.

The Sector Names

As previously mentioned, each sector has a unique name; there are two forms of these names: those with one word (e.g. Synookio), and those with two words (e.g. Dryau Aowsy). From here on, one-word names will be called class 1 names and two-word names will be class 2.

Both classes of name are made up of a common set of "phonemes", or word fragments. These are made up of several types of fragment: prefixes, infixes and suffixes. Infixes are only used by class 1 names; prefixes and suffixes are used by both.