T5SS and hex numbers

[dalthor]

Right now, looking at sector data on TravellerMap, Core is located at 0,0, and everything else is relative to it.

I wrote a jump route finder, and load multiple data files. I converted the HEX field to a BIGHEX field, consisting of 6 digits. Using the +/- modifiers from datasets (for example Daibei is located at -1,2) results in NEGATIVE hex numbers for anything Spinward and/or Coreword from the Core sector.

IMTU I've located Core at Kk - column K, row k, which equates to 11,11. Some other locations are Ij = Corridor, Jk = Dagudashaag, Jm = Daibei, In = Dark Nebula, Ll = Delphi, and Hj = Deneb. I went with an odd number to literally center the Core sector on the sector map.

Note that a 6-digit hex limits me to about 23 x 23 sectors mapped AND loaded into the pathfinder - SIGNIFICANTLY larger than current mapped space on TravellerMap; I can go 10 sectors in any direction from Core, and stay within that numbering system. This is the equivalent of a hex map 736 hexes wide by 920 tall.

The method to calculate the relative (bighex) number comes out to this:

' covert a letter grid coordinate to numeric equivalent, based on ASCII codes
' ucase converts a string to uppercase, and ASC(<char>) returns the number of the
' character in the ASCII table. Subtract 65 to convert the letter to a number  
' from 0 (A) to 25 (Z)
' GridXY and HEX are hardcoded here for example purposes

GridXY = "Kk"    ' this equates to Core sector
HEX = 2118      ' and the hex for Capital

xPos = Asc(UCase(Mid$(GridXY, 1, 1))) - 65       ' xPos will be 11
yPos = Asc(UCase(Mid$(GridXY, 2, 1))) - 65       ' yPos will be 11

' Split the hex number
x1 = HEX / 100
y1 = HEX mod 100
        
BigHex = (xPos * 32 + x1) * 1000 + (yPos * 40 + y1)

In my database, the Entry for Capital looks like this (header included):

BIGHEX HEX  HAME                 UWP       B  Z PGB AL
341418 2118 Capital              A586A98-F B  - 605 Im

This generates a unique hex number for each and every hex, and lets my jump route calculator function correctly. And yes, I could do the same thing by "adding" a fudge factor of +11,+11 to the original x,y location.

Is there any consideration being given to "updating" the sector files for the location of the sectors relative to Core?

Has there been any discussion about relative hex numbers?

My approach is pretty simple...comment or thoughts are appreciated.

 

[tjoneslo]

IMTU I've located Core at Kk - column K, row k, which equates to 11,11. Some other locations are Ij = Corridor, Jk = Dagudashaag, Jm = Daibei, In = Dark Nebula, Ll = Delphi, and Hj = Deneb. I went with an odd number to literally center the Core sector on the sector map.

This is similar to the CORE map:
http://www.ocean-of-storms.com/core/astrogat/textmap.htm

Which places Core sector at location fG:
http://www.ocean-of-storms.com/core/astrogat/fG.htm

I've also build a route finder, and found that there is no significant advantage to including a larger hex location in the data. Since I'm doing this via computer, I can map the sector/hex location to the larger map size and not be limited by silly things like number of digits in the location.

This is an interesting reference for doing mapping/route finding on hexagon grids:

http://www.redblobgames.com/grids/hexagons/

 

[inexorabletash]

Is there any consideration being given to "updating" the sector files for the location of the sectors relative to Core?

Not updating per se, but there's been discussion (primarily by robject) about coming up with a galaxy-wide coordinate scheme, equivalent to the canonical (but hard to use) Ring/Ray system. This leads to challenges like "skinny"/"fat" sectors/subsectors as you move coreward/rimward, and "rotating" sectors as you move spinward/trailing.

T5 data tends to simply use "SSSS-XXYY" for any reference (e.g. owned worlds); it does require a name->location lookup and math, but it's human-readable and computers are good at drudgery. On the map site you can use URLs like http://travellermap.com/go/spin/1910 rather than having to remember bigger numbers.

You're probably aware of http://travellermap.com/doc/api#systems which is mostly implementation details rather than any suggestion for standardizing coordinate schemes.