Non OTU: LBB S3 Spinward Marches (re)mapping in 1105

[Grav_Moped]

The instances that I’d found were of the “do not roll” variety: three naval bases associated with starports below class B, and one scout base associated with a class E starport. I didn’t compare the allegiance of a world to the allegiance of its bases.

This is (or can be) simple: the bases include Class A or B starports without civilian construction capability. The lower-grade official starport is the most support that the Imperium -- or other hegemon -- allows outside the base(s).

 

[Spinward Flow]

Twelfth step revision: Imgur Link (3602 × 5209 png image) (recommend opening in new tab)

This increment includes editing of the Lunion UWP data to be compliant with LBB3.81 RAW standards.

---

Yet more editing fun this time around.
This time the "off by 1" error patterns including not only the +/- 1 factor in UWPs, but also some rather obvious numpad keystroke errors in transcription.

Ziabon and Gandr, as Asteroid Belt mainworlds gained the Satellite code (which I'm giving all Size: 0 mainworlds as part of this remap project), but it turns out that Quiru is also a Satellite (moon) mainworld according to Travellerwiki but this information is not recorded in the Sector data on Travellermap, so I fixed that as well.

The biggest change when reverting Travellermap data to LBB S3 UWPs has to be Tenalphi, which went from (A774722–E) on Travellermap (and the Milieu 1116 entry on Travellerwiki) to instead being (A774102-E) in LBB S3 ... which is a Population: +6 increase from 1105 to 1116. On a linear delivery scale, that amounts to a MINIMUM immigration delivery of ... ... in excess of 1 million persons per year!

Fun fact about Tenalphi/Lunion is that if the UWP was A774722 ... the TL +DM would be only +6, just from the starport ... meaning that the highest tech level for the world would be 6+6=C, not E. The only way Tenalphi can be TL=E is with a Population: 1-5 and a Government: 0 or 5 ... short of increasing the Population to 9+ ... which shouldn't be happening when starting from A774102-E according to LBB S3, a UWP that generates a TL +DM of +8 and yields a maximum of 6+8=E.

Rabwhar and Adabicci are not Amber Zones in LBB S3.
Penkwhar is a Red Zone, not an Amber Zone in LBB S3.
These changes make a difference to these worlds when it comes to the economics of merchant shipping, since there is no Major Cargo bound for Amber Zones, along with a reduction in passenger demand for Amber Zone destinations. Therefore, making Rabwhar and Adabicci have Green Zone classifications removes a serious trade barrier impediment to a J2 route between Lunion/Lunion and Lanth/Lanth.

---

Obviously, the rewrite of the Express Network routes through Lunion is the most obvious here when focusing on the Lunion subsector, which then spills over into the neighboring Sword Worlds and Mora subsectors.

One of the (many) considerations for "rewriting the lines" through Lunion subsector was to, in effect, "unsnarl" communications traffic needing to move through the subsector and to points beyond while maintinaing the operating principle of keeping as many worlds as possible within J2 of an Express Network "node" so that Scout/Couriers can be used to disseminate communiques outwards from the Express Network in a hub and spoke arrangement.

There's also the need to transmit communications between subsector capitals for administrative purposes, so delays in transmission across the Express Network are "undesirable" when executing its primary mission of keeping the subsector capitals "close enough together" that they do not drift too far apart from each other so as to keep the Third Imperium (more or less) cohesive.

So with the rewrite to the Express Network that I've done, you get the following high priority "artery" links between subsector capitals using J4 at every possible opportunity (never mind the lines, what's within J4 range?):

• Iderati/Five Sisters <J3> Flammarion/Sworld Worlds <J4> Caladbolg/Sword Worlds <J4> Wardn/Lunion <J3> Adabicci/Lunion <J3> Lunion/Lunion = 5 jumps for 17 parsecs
• Lunion/Lunion <J4> Strouden/Lunion <J2> Persephone/Lunion <J3> Marastan/Glisten <J3> Ffudn/Glisten <J4> Glisten/Glisten = 4 jumps for 16 parsecs
• Lunion/Lunion <J2> Resten/Lunion <J4> Ivendo/Lanth <J4> D'Ganzio/Lanth <J2> Lanth/Lanth = 4 jumps for 12 parsecs
• Lunion/Lunion <J2> Resten/Lunion <J4> Ivendo/Lanth <J2> Equus/Lanth <J3> Rhylanor/Rhylanor = 4 jumps for 11 parsecs
• Lunion/Lunion <J2> Resten/Lunion <J3> Mercury/Mora <J4> Fornice/Mora <J2> Mora/Mora = 4 jumps for 11 parsecs
• Lunion/Lunion <J2> Resten/Lunion <J3> Mercury/Mora <J4> Maitz/Mora <J3> Palique/Mora <J3> Katarulu/Trin's Veil <J4> Trin/Trin's Veil = 6 jumps for 19 parsecs
• Mora/Mora <J2> Fornice/Mora <J4> Mercury/Mora <J3> Resten/Lunion <J4> Ivendo/Lunion <J4> D'Ganzio/Lanth <J2> Lanth/Lanth = 6 jumps for 19 parsecs
• Mora/Mora <J2> Fornice/Mora <J4> Mercury/Mora <J3> Fosey/Mora <J4> Icetina/Lanth <J4> Rhylanor/Rhylanor = 5 jumps for 17 parsecs

So ... because of the "shape" of the arrangement of stars and the locations of systems on the Express Network, Iderati/Five Sisters is (ironically) -1 jump and -2 parsecs "closer" to Lunion/Lunion than Trin/Trin's Veil is.

Important point here being that the "rewrite" of the Express Network through the Sword Worlds, Lunion and Mora subsectors makes it possible to connect Lunion/Lunion with Lanth/Lanth, Glisten/Glisten, Rhylanor/Rhylanor and Mora/Mora within 4 jumps, while also reducing the number of jumps needed between Mora/Mora and both Lanth/Lanth and Rhylanor/Rhylanor from 7 down to 5-6 due to the shift from Carey/Mora to Mercury/Mora (which also offers better hub and spoke J2 Scout/Courier coverage in the region) and dropping Capon/Lunion from the network.

---

Also, since I was looking at the Express Network in Lunion+Mora subsectors in detail, I decided to take another look at the "Klingon Hook" extending from Risek/Rhylanor up to Dhian/Aramis and on to Inthe/Regina ... and realized that the pathing of the connection made remarkably little sense for this branch.

Dhian is a type C starport, and there are precious few of those on the Express Network. In fact, Dhian has 2 star systems 1 parsec away with a type B (Inthe) and type A (Paya) starport, so Dhian is actually the "worst choice" for an Express Network node within the region. However, if Paya/Aramis was on the Express Network instead of Dhian/Aramis, that would put 2 worlds (Focaline/Aramis and Violante/Aramis) within J2 Scout/Courier range of an Express Network hub and spoke distribution point, so there would be greater coverage advantages to be found there for the IISS Communication Office mission.

Consequently, I've slightly reworked this branch of the Express Network beyond Risek/Rhylanor as another example of the kind of "compounding off by 1" errors that prompted a rework of routes through the Sword Worlds, Lunion and Mora subsectors for a better "more logical" fit. Putting Paya/Aramis on the Express Network, with its type A starport and naval base just makes too much sense from a logistics and communications standpoint ... enough so that I'm kind of surprised I never noticed this point before. Yes, it "redraws the lines" of the Express Network in the area, but such a minor shift actually brings a lot of benefits to the area, so I'm going to keep this change.

---

Next time ... Mora subsector!

 

[Kakistocrat]

Option 1: No. The remarks field does not have the space or the coding for that level of detail.

In both Traveller⁵ sector file formats, each field’s width is not fixed; the tab-delimited format accepts whatever width is found between two tab characters, and the column-delimited format’s field widths are determined by the widths of the hyphen runs on the separator line. If you’re using the SEC file format, then the Remarks field has a minimum width of 10 characters, with no mandated maximum width. If you’re using the “Sunbane” file format, though, then that has a maximum width of 16 characters.

Option 2: Yes, [the Sa code for an asteroid belt is] unaccompanied … merely as a signal that there’s more data elsewhere to look up at the system level. It’s then that system level info that spells out where the belt’s population clusters, but you get that process (and set the expectations for it) rolling by using the Satellite code in the Sector data in the Remarks section.

Couldn’t the same be said for non-asteroid belt mainworlds as well, that they can have more data (such as satellites of their own) to look up at the system level? If someone is curious about which worlds in a system have satellites, they’d head to the system level data without needing a code in the sector data remarks to nudge them that way. Wouldn’t the same apply to someone who is curious about the system level data (such as a list of populated asteroids) of asteroid belts?

In the case of Sol’s asteroid belt, some of its asteroids even have satellites of their own, e.g. the asteroid Sylvia has two satellites, Romulus and Remus, but both of them have diameters of less than 25 km.

 

[Kakistocrat]

[“Do not roll” bases for certain starport classes] is (or can be) simple: the bases include Class A or B starports without civilian construction capability. The lower-grade official starport is the most support that the Imperium — or other hegemon — allows outside the base(s).

It depends upon what the intended goal is: to correct mistakes in published system data, or to accept published system data as they are and come up with explanations for system generation discrepancies. My goal was primarily the former rather than the latter.

 

[Spinward Flow]

If you’re using the “Sunbane” file format, though, then that has a maximum width of 16 characters.

I've discovered, experimentally, that the Sector data file format offered on the Travellermap Poster Maker page is the column delimited (fixed character count lengths). So when I ask it to give me Spinward Marches (the default, which is supposed to be 1105) so that I can copy the raw data file into something I can save as a plain text (.txt) file on my computer between editing sessions ... I get a column delimited fixed character count length for each data field format.

I know this because whenever there is an "off by 1" error in the character count length for a data line entry, when I ask for a render of a Poster View, instead of getting an image, I get an error specifying which world data line is the offender by not having the correct number of characters in its respective data fields. The error doesn't tell me "where" in the data line the error is ... it just tells me it's there (somewhere).

"You're the user, YOU FIGURE IT OUT!"

Fortunately, the number of permutations for what could be messing up the character line length is a pretty short list (almost always the Trade Codes and Remarks, but not always if I needed to edit the bases or zoning for a system). It's a little tedious to correct when it happens, and it's almost always a result of auto-correct trying to be "too helpful" (in ways that actually aren't), so I've learned to work around this behavioral quirk of the text editor I'm working with to minimize the opportunities for this kind of "off by 1" error from happening.

Couldn’t the same be said for non-asteroid belt mainworlds as well, that they can have more data (such as satellites of their own) to look up at the system level?

Yes ... but ... the UWP is recording the MAINworld in the system (wherever that is).
The primary population center (and thus, mainworld) can always be a moon of a solar orbit body. So if the Solomani "evacuated" from Terra in order to conserve it as a nature preserve and relocated the overwhelming supermajority of the population from Terra to Luna (for example), then Luna would become the "mainworld" in the star system and be a Satellite of Terra.

If someone is curious about which worlds in a system have satellites, they’d head to the system level data without needing a code in the sector data remarks to nudge them that way. Wouldn’t the same apply to someone who is curious about the system level data (such as a list of populated asteroids) of asteroid belts?

Yes and yes ... but those are details beyond the immediate scope of a mainworld UWP recorded in subsector/sector listings for each star system (such as LBB S3). The mainworld UWP barely scratches the surface of what a more thorough survey of a star system would provide.

to correct mistakes in published system data

This is also the approach that I'm taking.
I'm not assuming that what is published in LBB S3 is "gospel" handed down from ON HIGH engraved into bonded superdense alloy tablets using mining lasers ... never to be questioned under any circumstances (all sing...).

For one thing, I KNOW BETTER ... and I can tell just by looking that LBB S3, as good as it is as a resource, that it IS NOT PERFECT (let alone perfected) in the state it was published in back in 1979.

At best ... I can "improve upon" LBB S3 with the tools that are (now) available to us.
But I'm never going to take the position of maximum hubris and think that what I'm doing ought to be a REPLACEMENT for LBB S3.

If what I'm doing winds up being preferred over LBB S3 as a point of reference then that would be more than enough for me ... but I'm never going to take the position that LBB S3 is "obsolete" and therefore must be "banished" and never spoken/thought of/referred to ever again.

 

[Spinward Flow]

Thirteenth step revision: Imgur Link (3602 × 5209 png image) (recommend opening in new tab)

This increment includes editing of the Mora subsector UWP data to be compliant with LBB3.81 RAW standards.

---

Four Amber Zones are Green Zones.
Only 1 world is a Satellite.
Another world is tidally Locked to its star.

Fenl's Gren required an adjustment to its Population to increase it from 3 to 4 in order to have a total population of 20,000 of which 80% are Chirpers in order to have a human population of 4000. According to Travellerwiki, the Thin atmosphere is tainted with airborne parasites that are lethal to humans so having a population that is majority Chirpers makes plenty of sense to me.

Otherwise, pretty bog standard twiddling of data fields to bring the map data more in compliance with LBB S3 (as usual).

---

Next time ... one of my personal favorite places in the Spinward Marches, the Five Sisters!

 

[Kakistocrat]

I’ve discovered, experimentally, that the Sector data file format offered on the Travellermap Poster Maker page is the column delimited (fixed character count lengths). So when I ask it to give me Spinward Marches (the default, which is supposed to be 1105) so that I can copy the raw data file into something I can save as a plain text (.txt) file on my computer between editing sessions … I get a column delimited fixed character count length for each data field format.

I know this because whenever there is an “off by 1” error in the character count length for a data line entry, when I ask for a render of a Poster View, instead of getting an image, I get an error specifying which world data line is the offender by not having the correct number of characters in its respective data fields. The error doesn’t tell me “where” in the data line the error is … it just tells me it’s there (somewhere).

“You’re the user, YOU FIGURE IT OUT!”

That sounds like the “Sunbane” format. If the returned sector file has a multiline header, with the last header line being

....+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8​

then it’s the “Sunbane” format.

Yes, generic error messages like that can certainly be frustrating. Have you written to Joshua Bell, the creator of the Traveller Map site, to see if he would provide a more detailed error message there (i.e. to provide both the line number and the column number where the error was detected)? His e-mail address can be found on the About the Traveller Map page.

Yes … but … the UWP is recording the MAINworld in the system (wherever that is).
The primary population center (and thus, mainworld) can always be a moon of a solar orbit body. So if the Solomani “evacuated” from Terra in order to conserve it as a nature preserve and relocated the overwhelming supermajority of the population from Terra to Luna (for example), then Luna would become the “mainworld” in the star system and be a Satellite of Terra.

Yes, and in that case providing the Sa code for Luna as a mainworld would make sense, to clarify that Luna rather than Terra is the mainworld, just as the Sa code does for Regina vs. Assiniboia. For an asteroid belt mainworld, though, an Sa code provides no clarifying information; its As code already shows that it is an asteroid belt.

Yes and yes … but those are details beyond the immediate scope of a mainworld UWP recorded in subsector/sector listings for each star system (such as LBB S3). The mainworld UWP barely scratches the surface of what a more thorough survey of a star system would provide.

Yes, and the details of that more thorough survey would be found in the system level data. Anyone interested in more than a mainworld’s UWP would head to the system level data to find that information, so why would an additional code be needed to nudge someone to look there for such data?

At best … I can “improve upon” LBB S3 with the tools that are (now) available to us.
But I’m never going to take the position of maximum hubris and think that what I’m doing ought to be a REPLACEMENT for LBB S3.

If what I’m doing winds up being preferred over LBB S3 as a point of reference then that would be more than enough for me … but I’m never going to take the position that LBB S3 is “obsolete” and therefore must be “banished” and never spoken/thought of/referred to ever again.

I completely share your view; I view my minor tweaks as improvements to, not replacements for, Supplement 3, and I’m absolutely certain that different tweaking heuristics would be no less valid than the ones that I’d chosen.

 

[Spinward Flow]

then it’s the “Sunbane” format.

Given the way the Poster Maker API functions when given edited datasets, I'm convinced that I'm dealing with the column delimited format detailed HERE and the formating for which is codified HERE. Since that makes for the Best Fit with the behavior I'm seeing when I make an error and the API "breaks" on that error, that's my assumption for how the data is encoded and interpreted.

Took some trial and error in the beginning to figure out how it all "worked" in order to make things behave like I wanted them to, but I got the hang of it with some practice.

For an asteroid belt mainworld, though, an Sa code provides no clarifying information; its As code already shows that it is an asteroid belt.

Guess I'm just viewing it from the "more nuanced" viewpoint, where the Sa code can also be used to indicate to Navigators that there is additional context needed when jumping. STRICTLY speaking, the addition of the Sa code is "unnecessary" since the entire belt is going to be orbiting a star ... except that it's perfectly possible for even asteroids to have moons (as we now know, thanks to the DART mission). And if asteroids can have moons, they can also have space stations in orbit around those asteroids (and their moons?).

Point being that it is both "safer" and a "no harm, no foul" to include a Sa code automatically with an As code to further emphasize the importance of accurate navigation, imo. Just one of those "be extra careful with your calculations" kinds of heads up notices.

 

[Spinward Flow]

Fourteenth step revision: Imgur Link (3602 × 5209 png image) (recommend opening in new tab)

This increment includes editing of the Five Sisters subsector UWP data to be compliant with LBB3.81 RAW standards.

---

A few interesting things of note to talk about this time going on in the subsector update.

Goethe and Quhaiathat are Green Zones, not Amber Zones in LBB S3.
Quhaiathat is actually a Cold mainworld beyond the habitable zone of its star.
Jinx is a Satellite moon of one of the two gas giants in the system.

Andor[y] and Candory present their own interesting set of problems, since these worlds were part of the LBB S3 publication in 1979, well in advance of Alien Module: 5 Droyne published in 1985. In this particular instance, I'm thinking that an update to AM: 5 Droyne standards for UWP and for transliteration of mainworld names (just like I did with the Zhodani controlled worlds) seems most appropriate.

Given a choice bewteen Andor and Andory, I definitely prefer the latter (to better avoid confusion with anything from Star Wars) ... even though LBB S3 was published in 1979 and the film Return of the Jedi wouldn't go to the "forest moon of Andor" until 1983.

However, when looking at rules for generating Oynprith words (AM: 5 Droyne, p40) ... it becomes VERY VERY CLEAR that the words "Andory" and "Candory" as commonly pronounced in english are "not legal syllable structures" for the way that Oynprith organizes things in word generation. For one thing, there is "ee" sound for the -y at the end of each world name found in LBB S3.

Another complication is that according to AM: 5 Droyne, p34-35 ... Droyne worlds have only 3 types of government ... 6, 7 and X.

DROYNE GOVERNMENTS
Droyne worlds governed by Droyne have three basic types of government:
6: Captive Government. The government is controlled by another world.
7: Balkanized. Rival Droyne governments control distinct areas of the world surface.
X: Droyne Hierarchy. Established communities are ruled by hereditary and long-established governments.

A quick gloss of the Travellerwiki for both Andor and Candory quickly demonstrate that Government: 7 is the best fit for both worlds, rather than the Goverment: 3 (self-perpetuating oligarchy) presumed all the way back when LBB S3 was first published.

Another fun fact about these Droyne worlds is that by their UWP (C695735-9 and C593634-9 respectively), going strictly by LBB3.81 (and 77 for that matter) both worlds would be limited to a +2DM to TL because of their type C starports ... meaning that on a 1D6+2 dice roll, neither one ought to be capable of reaching TL=9 before upgrading their starport to type B or changing their government type to 5 (feudal technocracy). However, according to AM: 5 Droyne, p34-35 ... the correct roll for tech level on Droyne worlds is 3D-2 ... which then makes a TL=9 result for both worlds "game legal" by going outside the scope of LBB3.81 (and 77) in this regard.

Which then brings us back to the problem of how to transliterate the names "An-dor-ee" and "Kan-dor-ee" into something vaguely resembling Oynprith?

• Ayndoroy (SM0236)
• Kayndoroy (SM0336)

Endory = VC CV CV syllable structure ... so it's spoken as Ayn-do-roy
Kendory = CVC CV CV syllable structure ... so it's spoken as Kayn-do-roy

If anyone else would like to offer an alternative, feel free to quote comment here in this thread (where I'll be sure to see it) with your preference.

One of the complications here with using the "a" vowel is that in Oynprith is that it sounds like the "o" in "lock" rather than like an "a" in "can" as spoken in english. In contrast, the "ay" vowel in Oynprith sounds like the "a" in the word "lake" in english.

I would like to think that this is the most satisfying transliteration possible for the names of these two worlds, just like I did with the Zhodani controlled worlds in the spinward/coreward subsectors.

---

All things considered, I'm rather pleased with how things shook out in this update to the Five Sisters subsector.

Next time ... District 268!
Same subtime.
Same subchannel.
Next subsector!

 

[Kakistocrat]

Given the way the Poster Maker API functions when given edited datasets, I’m convinced that I’m dealing with the column delimited format detailed HERE and the formatting for which is codified HERE. Since that makes for the Best Fit with the behavior I’m seeing when I make an error and the API “breaks” on that error, that’s my assumption for how the data is encoded and interpreted.

If it’s the Traveller⁵ column-delimited format, then it should have a single header line followed by a single separator line, and the width of each field’s hyphen runs in the separator line should determine the corresponding field’s width in the header line and the data lines. If the API is breaking on e.g. a Remarks field in a data line that fits within the width of the hyphen run of the Remarks field in the separator line, then I’m confident that Joshua would want to learn about that and fix the API accordingly.

Guess I’m just viewing it from the “more nuanced” viewpoint, where the Sa code can also be used to indicate to Navigators that there is additional context needed when jumping.

As long as the jump destination is at least 100D from the targeted asteroid in the belt, a navigator will probably be more interested in that context for in-belt navigation. (Contrary to most cinematic displays of an asteroid belt, there’s still a huge amount of space in between asteroids in a belt.)

STRICTLY speaking, the addition of the Sa code is “unnecessary” since the entire belt is going to be orbiting a star … except that it’s perfectly possible for even asteroids to have moons (as we now know, thanks to the DART mission).

We’ve known that asteroids can have moons at least since 1993, when the Galileo probe found Dactyl orbiting Ida.

Point being that it is both “safer” and a “no harm, no foul” to include a Sa code automatically with an As code to further emphasize the importance of accurate navigation, imo. Just one of those “be extra careful with your calculations” kinds of heads up notices.

A blinking red As code might be more effective to catch a navigator’s attention.

 

[Kakistocrat]

Which then brings us back to the problem of how to transliterate the names “An-dor-ee” and “Kan-dor-ee” into something vaguely resembling Oynprith?

• Ayndoroy (SM0236)
• Kayndoroy (SM0336)

Endory = VC CV CV syllable structure … so it’s spoken as Ayn-do-roy
Kendory = CVC CV CV syllable structure … so it’s spoken as Kayn-do-roy

If anyone else would like to offer an alternative, feel free to quote comment here in this thread (where I’ll be sure to see it) with your preference.

One of the complications here with using the “a” vowel is that in Oynprith is that it sounds like the “o” in “lock” rather than like an “a” in “can” as spoken in english. In contrast, the “ay” vowel in Oynprith sounds like the “a” in the word “lake” in english.

In this example, I think that the “«o» in «lock»” pro‍nunciation (IPA /ɑ/) would be preferable because English speakers tend to anglicize foreign words with an “a” vowel by using the “can” vowel (IPA /æ/). For example, the “a” vowels in “Afghanistan” have the /ɑ/ sound in Afghan languages such as Pashtun, but those “a” vowels have been anglicized to /æ/ by most English speakers.

 

[Spinward Flow]

In this example, I think that the “«o» in «lock»” pro‍nunciation (IPA /ɑ/) would be preferable because English speakers tend to anglicize foreign words with an “a” vowel by using the “can” vowel (IPA /æ/).

True ... but ...

Ayn-do-roy has the "ayn" part sounding like "ain't" (minus the apostrophe + t on the end) ... which I deemed to be a closer fit than the sound of "lock" (or "loch" spoken in a scottish brogue) minus all the consonants around the vowel sound.

In truth, I actually started with Andoroy (which would sound more like "on-do-roy") and decided to keep looking through the vowel sounds to see if there was a better fit for the phonemes I wanted, hence the switch to Ayndoroy just prior to publication for the Five Sister subsector update.

 

[Spinward Flow]

Fifteenth step revision: Imgur Link (3602 × 5209 png image) (recommend opening in new tab)

This increment includes editing of the Five Sisters subsector UWP data to be compliant with LBB3.81 RAW standards.

---

And there we have it. Incontrovertible proof that Travellermap has its "more world colors" programming operating in such a way that I cannot correct for it through use of Remarks in the Sector data.

According to CT's rules for what qualifies as a Rich world (which does NOT match the qualities needed for T5!), both Tarsus and Pavabid do NOT qualify as Rich worlds in District 268.

LBB3.81, p16:

Rich worlds have good climates and environments and are sought after by most individuals as living places. A rich world must have government type 4 through 9, an atmosphere of 6 or 8, and a population of 6 through 8.

T5 Second Survey classification used by Travellermap:

Atm 6,8, Pop 6-8

So naturally, when the is a disagreement between CT and T5 Second Survey ... because government type is an additional requirement in CT but not in T5 Second Survey ... you wind up with the "more world colors" option displaying Rich world trade code status on the map for worlds that are NOT considered Rich worlds under CT. This condition applies to both both Tarsus and Pavabid due to their government types ... but even with the Remarks field for both worlds corrected to not include Rich world status, the "more world colors" option continue to incorrectly display these worlds as being Rich when according to CT they are not (and are notated as such in my Sector data file.

I am disappoint.

Worse yet, I don't think that there's a way to "fix" this particular problem with a coding extension of the Travellermap API such that an option checkbox gets added to include the additional Government code limitation on Rich worlds used in CT.

Bare minimum, I'm basically stuck with the "more world colors" option reporting Wrong Colors™ for the trading codes of these two specific worlds in my (re)mapping effort for the sector.

---

In other news, only one Satellite code needed to be added (beyond the obligatory one for the Bowman system asteroid belt like I've been doing elsewhere). So far every single subsector has had at least 1 mainworld within its borders which is a Satellite rather than the planet in its respective solar orbit.

Had to update Binges/District 268 to report as a Non-aligned Droyne dominated world (70% Droyne, 30% Human population) to more accurately reflect the world data on file at Travellerwiki.

567-908/District 268 lost its alien minor species notation because the discovery of Shriekers was not reported to the IISS until 1108 and the date for the LBB S3 inspired (re)mapping effort I'm undertaking here is 1105 ... so this alien minor species hasn't been discovered yet at the time of the mapping survey I'm representing.

Also had to fix the Government codes and "ownership" attribution for Elixabeth and Talchek so they reported as being colonies (code: 6) of Forine as published in LBB S3. Travellermap has an incorrect attribution of "ownership" for Elixabeth pointing to Dallia (O:1335) instead of Forine (O:1533) as stipulated repeatedly in the Travellerwiki page for Elixabeth. A transposition typo, I'm sure.

---

Next up ... Glisten subsector!

 

[Spinward Flow]

And there we have it. Incontrovertible proof that Travellermap has its "more world colors" programming operating in such a way that I cannot correct for it through use of Remarks in the Sector data.

I was looking through previous subsectors and noticed that Pequan/Jewell has the same issue, so once I get all the UWPs updated through the Trin's Veil subsector I'm going to need to do another review pass through the sector and make manual image editing changes to worlds (to alter their colors) using copy/clip/paste so as to correct the "unforced errors" being imposed by Travellermap API programming that is functionally less flexible than I would have hoped for this.

Not an insurmountable challenge, but it does mean that what I'm doing is going to "defy replication of results" by others once I go ahead and publish my Sector data and Metadata XML files at the end of this project ... all because I have to "fix" what Travellermap is doing with its "more world colors" feature (that incorrectly assigns Rich world status under CT RAW).

Overall, from a tramp free trader campaign perspective, I vastly prefer the "more world colors" option (especially when done correctly) because it shows me at a glance what trade codes are clustered where, so as to be able to figure out where prime speculative goods market opportunities can be found. My one regret in this regard is that there are no colors (and therefore, combinations of colors) for either Non-agricultural or Poor worlds. My earlier recommendation to enable additional type styling of world names for Non-industrial worlds, with the addition of an underline for Population: 4- minus worlds (that incur additional -DMs to passengers and third party cargoes, per LBB2.81 p11) would be exceptionally useful to have as a merchant. That way, all the trade relevant population bracket information is contained within the styling of mainworld names on the map and the colors indicate all of the relevant trade code classifications relevant to speculative trading.

Insert lament about not being allowed Nice Things™ ...

 

[Grav_Moped]

but even with the Remarks field for both worlds corrected to not include Rich world status, the "more world colors" option continue to incorrectly display these worlds as being Rich when according to CT they are not (and are notated as such in my Sector data file.

Color coding probably is directly pulled from UWP digits, not the trade code sub-strings, so editing the latter won't affect it.

 

[King Midas]

Fourteenth step revision: Imgur Link (3602 × 5209 png image) (recommend opening in new tab)

This increment includes editing of the Five Sisters subsector UWP data to be compliant with LBB3.81 RAW standards.

---

A few interesting things of note to talk about this time going on in the subsector update.

Goethe and Quhaiathat are Green Zones, not Amber Zones in LBB S3.
Quhaiathat is actually a Cold mainworld beyond the habitable zone of its star.
Jinx is a Satellite moon of one of the two gas giants in the system.

Andor[y] and Candory present their own interesting set of problems, since these worlds were part of the LBB S3 publication in 1979, well in advance of Alien Module: 5 Droyne published in 1985. In this particular instance, I'm thinking that an update to AM: 5 Droyne standards for UWP and for transliteration of mainworld names (just like I did with the Zhodani controlled worlds) seems most appropriate.

Given a choice bewteen Andor and Andory, I definitely prefer the latter (to better avoid confusion with anything from Star Wars) ... even though LBB S3 was published in 1979 and the film Return of the Jedi wouldn't go to the "forest moon of Andor" until 1983.

However, when looking at rules for generating Oynprith words (AM: 5 Droyne, p40) ... it becomes VERY VERY CLEAR that the words "Andory" and "Candory" as commonly ⌧ounced in english are "not legal syllable structures" for the way that Oynprith organizes things in word generation. For one thing, there is "ee" sound for the -y at the end of each world name found in LBB S3.

Another complication is that according to AM: 5 Droyne, p34-35 ... Droyne worlds have only 3 types of government ... 6, 7 and X.

A quick gloss of the Travellerwiki for both Andor and Candory quickly demonstrate that Government: 7 is the best fit for both worlds, rather than the Goverment: 3 (self-perpetuating oligarchy) presumed all the way back when LBB S3 was first published.

Another fun fact about these Droyne worlds is that by their UWP (C695735-9 and C593634-9 respectively), going strictly by LBB3.81 (and 77 for that matter) both worlds would be limited to a +2DM to TL because of their type C starports ... meaning that on a 1D6+2 dice roll, neither one ought to be capable of reaching TL=9 before upgrading their starport to type B or changing their government type to 5 (feudal technocracy). However, according to AM: 5 Droyne, p34-35 ... the correct roll for tech level on Droyne worlds is 3D-2 ... which then makes a TL=9 result for both worlds "game legal" by going outside the scope of LBB3.81 (and 77) in this regard.

Which then brings us back to the problem of how to transliterate the names "An-dor-ee" and "Kan-dor-ee" into something vaguely resembling Oynprith?

• Ayndoroy (SM0236)
• Kayndoroy (SM0336)

Endory = VC CV CV syllable structure ... so it's spoken as Ayn-do-roy
Kendory = CVC CV CV syllable structure ... so it's spoken as Kayn-do-roy

If anyone else would like to offer an alternative, feel free to quote comment here in this thread (where I'll be sure to see it) with your preference.

One of the complications here with using the "a" vowel is that in Oynprith is that it sounds like the "o" in "lock" rather than like an "a" in "can" as spoken in english. In contrast, the "ay" vowel in Oynprith sounds like the "a" in the word "lake" in english.

I would like to think that this is the most satisfying transliteration possible for the names of these two worlds, just like I did with the Zhodani controlled worlds in the spinward/coreward subsectors.

---

All things considered, I'm rather pleased with how things shook out in this update to the Five Sisters subsector.

Weirdly, I was just reviewing my notes on Five Sisters just an hour ago.
I've always thought "Andor" was a mis-hearing. Both names end in a vowel not usually heard in Anglic, kind of a "-h" rather than an "eh". The human recording the name at Andory left it out, while the one at Candory stuck in something to signal the third syllable.
In my notes, I discovered the existence of "Wonderay," another r<vowel> world. Next to nothing is known about this world: Waterworld, Balkanized, Pop 4. So I wonder if this is a the home of some Droyne? Not enough to call it a "Droyne world" but some?

 

[Spinward Flow]

Color coding probably is directly pulled from UWP digits, not the trade code sub-strings, so editing the latter won't affect it.

That's my conclusion, that the "more world colors" are hard coded from interpretation of the UWP. The Remarks are just there as a "courtesy to users" so that the information relevant to those Remarks can be included in other displays (like the pulldown under the search) used by Travellermap.

Now I'm starting to wish that there were a LOT MORE "more world colors" available.
Can keep the empty white circle on black for the Atmosphere: 0-1 worlds, but then include white horizontal bands top/bottom modifier inside the white circle as an indicator for Ice Capped worlds.

The 6 trade codes relevant to speculative goods trading are:

• Agricultural/Non-agricultural
• Industrial/Non-industrial
• Rich/Poor

The "more world colors" includes:

• Water Ocean = Cyan
• Atmosphere: B-C = Orange
• Agricultural = Green
• Non-agricultural = (missing)
• Industrial = Grey
• Non-industrial = (not noted)
• Rich = Purple
• Poor = (missing)
• Agricultural + Rich = Yellow

If I rearrange that into more of an (extended) ROYGBIV sequencing order, I get this:

• Grey = Industrialized
• Red = (not used)
• Orange = Atmosphere: B-C
• Yellow = Agricultural + Rich
• Green = Agricultural
• Cyan = Water Ocean present (Atmosphere: 2-9, Hydrographics: 1+)
• Purple = Rich
• Black = Vacuum

My natural inclination would be to use Brown for Non-agricultural (as the opposite of Green).
Banded white top/bottom around black for Ice Capped (as mentioned above).
Non-industrial is best indicated by italics in the font for names, since MOST worlds in the sector are Non-industrial (since Population: 6- is a 2D=8- throw result).
Which then just leaves Poor needing a color assignment. I'm reluctant to use Red for this (for what ought to be obvious reasons). So pretty much the only color remaining out of the most basic color swatch set would be Magenta for Poor worlds.

And I guess then that the combination of Non-agricultural plus Poor would need to use Pink Panther Pink to symbolize that potential combination.
Industrial plus Non-agricultural could be Red to cover that combination.



I'd like to think that such a modernization of the "more world colors" feature to more fulsomely depict trade codes on the sector map in a way that is visually accessible to merchants would be a worthwhile upgrade.

And now that I've said that ... I'm starting to feel "compelled" to implement the idea when I review the completed .png image of the sector map in order to implement that scheme visually so that everyone can see what it does.
I'm just making Busy Work™ for myself at this point in order to have Nice Things™ ...

 

[Spinward Flow]

Sixteenth step revision: Imgur Link (3602 × 5209 png image) (recommend opening in new tab)

This increment includes editing of the Glisten subsector UWP data to be compliant with LBB3.81 RAW standards.
(yes, the previous one was District 268, I just didn't edit the post correctly)

---

Decided after lots of rethinking that people arguing that the Satellite code for Asteroid Belts was redundant/superfluous were (more) correct, so I went back and dropped it from all the Asteroid mainworlds that I'd added it to (since it was Glisten's turn this time).

Turns out that Windsor/Glisten actually is a Satellite of a gas giant in its star system. Who knew?

Was kind of surprised how many worlds in this subsector had so many discrepancies (mostly Size) in their UWPs, with quite a lot of them not fitting into the "off by 1" error pattern that I've seen so often.

Another fun point is that Tirem/Glisten is an Industrialized world according to Second Survey rules for trade codes ... but not by CT trade codes! So that's yet one more world icon I'm going to need to copy/paste into being the correct color when I have to meticulously go through the .png image after I get done with Trin's Veil so as to give the icon the correct color for its CT trade code classification.

Be nice if there was something akin to an XML file that would let me "frobbish the knobs" on world colors in order to be able to define my own, rather than having the color key hard coded into API, but that's just yet more wishful thinking on my part. I suspect that the whole question of "what are you actually trying to do here?" will be a lot easier when I can just SHOW what I'm thinking of and not just talk about it.

For some reason, I'm suddenly reminded of H. Ross Parrot on Sesame Street. Weird ... that was over 30 years ago.

"Are y'all ready to SAY the Alphabet and not just TALK about it?"

Also nice to be able to remove 3 Amber Zones that weren't there in LBB S3 from the Glisten subsector. Helps make the sector map start feeling more like "HOME" than seeing all the (to my mind) "errors" littered all over the Spinward Marches M1105 map on Travellermap. It's as if all the later eras "accidentally" dumped all of their timeline updates into the wrong Sector data file (that's not 1105, that's 1116!).

Marastan/Glisten was another "fun one" to update and correct.
Travellermap and Travellerwiki UWP: D868764-5
LBB S3 UWP: D868771-5
My compromise (including LBB3.77 and LBB.81): C868772-5

The starport "had to be upgraded" to type C in order to justify the Express Network J3 links to Persephone and Ffudn (LBB2.77, p2).
The law level "had to be upgraded" to 2 as the minimum possible for a government type of 7 (balkanized).
Fortunately, the upgrade in starport did not "require" an increase in tech level.

---

One other minor correction I made that has been bugging me for a while now was ... Flammarion/Sword Worlds.
There's simply no good reason why this star system would have a Way Station in it, especially when Mirriam/Five Sisters a mere 6 parsecs away ALSO has a Way Station. The Five Sisters just aren't "enough of a destination" to need TWO Way Stations that far away from contiguous Imperial territory. Besides, there's Persephone/Lunion to trailing with another Way Station, so the Way Station at Flammarion was just really superfluous.

Since Flammarion is supposed to have a Naval Base and a Scout Base, I just dropped the Way Station notation in favor of a Scout Base and called the job finished. Besides, it's not like the Travellerwiki page for Flammarion makes any particular mention of the star system having an Imperial Way Station as part of the writeup, so I feel more justified in making this correction. Yes, LBB S3 records Flammarion as having a Way Station, but I honestly think that was a screw up in editing/checking/proofing that (somehow) made it through to publication without being caught.

---

Next time ... Trin's Veil!
And then once I'm done with the first pass on the UWP revisions, it's going to be time to "fine tooth comb" through everything all over again to manually edit world names and colors to implement the updates that I wish Travellermap made available to us, along with putting all of the Imperial Nobles through a "steel sieve" to make changes to "who is worthy of what where" in ways that are more aligned with LBB S4 and the Noble career path in ways that can clear up a few things here and there (do want to be consistent).

However the end of Phase 1 is within sight, and that light at the end of the tunnel isn't making choo-choo noises!

 

[Spinward Flow]

Seventeenth step revision: Imgur Link (3602 × 5209 png image) (recommend opening in new tab)

This increment includes editing of the Trin's Veil subsector UWP data to be compliant with LBB3.81 RAW standards.

NO EDITS Travellermap source: Imgur Link (3602 × 5209 png image) (recommend opening in new tab)

I recommend opening both png images in adjacent tabs in your web browser and then flipping back and forth between them to see just how many edits and changes I was forced to make just to reach this stage of the editing process (and I'm still not done yet! ).

---

Turns out that Zyra/Trin's Veil is a Satellite of a gas giant. Who knew?

Travellermap source Sector data has a few really THAT CAN'T BE RIGHT errors (aside from the usual of biasing too many world Size codes to be 5 all the time for no good reason).

Under the heading of "Excuses Not Valid" we have Burston/Trin's Veil, which according to Travellermap is (Government: 6) "owned" by Edenelt (SM2733) instead of Squanine (SM2536) for no readily apparent reason. Gets even better when the Travellerwiki pages for both Burston and Squanine both clearly state that Burston is a Colony of Squanine (so I added the Cy remark to Burston) in addition to changing the "ownership" of the world to Squanine.

Even more egregious under the heading of "Excuses REALLY Not Valid!" is Keltchner/Trin's Veil, which according to Travellermap is (Government: 6) "owned" by ... (scrolls map down into the Trojan Reaches) ... Islent/Pax Rulin(TR2402) ... ?

Go Home Homura, You Are Drunk

And then there was the situation with Zephyr/Trin's Veil which in LBB S3 was a Red Zone but also had Government: 6. In this case I just added the Military Rule remark (after fixing the starport to be type X) and moved on.

Also had to reclassify Thisbe, Robin, Edenelt, Dodds and Hammermium as Green Zones, not Amber Zones to bring the subsector into compliance with LBB S3.

---

Now that I've "fixed" the UWP codes for all the mainworlds in the sector (and boy did that take a lot more editing than I thought it would! ), I daresay it's time to move on to the next phase of editing all of this ... correcting details on the map.

First thing I want to do is to implement my fantasized about italics for Non-industrialized world names along with underlined italics for names of worlds with Population: 4-. This will require a pretty staggering amount of image editing in Preview in order to pull this off, along with LOTS of "open, make a few changes, SAVE, close, repeat" intermediate steps along the way to prevent the image from "blurring out" when too many edit changes get stacked on top of each other in a single save cycle.

I'm thinking that this one edit to highlight Non-industrialized (and by extension, low population) worlds will probably make the most dramatic difference in how much information can be quickly gleaned at a glance just by looking at a sector (and/or subsector) map. I have a fair idea of just how much of a difference it's going to make in terms of presentation, but this is definitely one of those "Seeing Is Believing" types of things where once you SEE what it does, the obviousness of the usefulness in improved notation ought to be beyond reproach. The one thing that I cannot predict is if seeing what I'm about to do will prompt calls for Travellermap to follow suit and implement such a Feature Request™ so that I can't keep all the "glory" for this idea to myself.

Ye ken hoo i'tis.

---

After I get all the Non-industrialized world names modified to meet the new format criterion I want to use, the next update ought to be editing the World Colors used to indicate Trade Codes.

One thing that I'm noticing is that while Agricultural/Non-agricultural are by definition mutually exclusive, as are both Rich/Poor ... there are other possible combinations of trade codes. Agricultural+Rich is the one that we're probably most familiar with (since that yields yellow for world color on Travellermap), but perhaps the strangest potential combination is Industrial, Non-agricultural and Poor, which is a "thread the needle" combo that (under CT RAW) requires Atmosphere: 2, Hydrographics: 3- and Population: 9+. To my knowledge, there are TWO such Industrialized, Non-agricultural and Poor worlds in the Spinward Marches:

1. Louzy/Jewell (D322A88-8) Industrialized. Non-agricultural. Poor.
2. Bevey/Rhylanor (D4209CC-A) Desert. Industrialized. Non-agricultural. Poor.

Any "rework" of the world colors system for use as a tramp free trader's portolan chart for speculative goods trade codes knowledge is going to need to be able to show all of these possible combinations ... and just "adding more new colors" into the mix is only going to make things confusing ("Oh, that's puce." ).

So what I'm thinking of doing is something more like a refactoring overhaul/rewrite of how colors get applied to world icons on the sector map. However, I'd like to spend a little more time thinking about this, since right now I'm contemplating doing a Neopolitan Stripe on a vertical orientation in order to handle multiple trade codes (up to 3) for a single world. What I want is something where you can just GLANCE at the color of a world icon and interpret almost all of the trade code information just visually by looking at each world on the sector map. This means that I'm going to be doing a LOT more color revisions than I had hoped for originally, but it also means that the map I want to make is going to be that much more useful with more readily accessible information that is easier to distinguish at a glance (once you learn the system of symbology, of course).

---

So those will be the next steps along this journey.
I'm presuming that there are still some "errors" left over after a single pass through the data, subsector by subsector, which will hopefully get discovered during these subsequent reviews now that I've completed the First Pass through the Sector data.

So this is not the End.
It is not even the Beginning of the End.
But it is, perhaps, the End of the Beginning.

 

[bookwyrm]

Don't forget...

Ag - Ri - Ni and Na - Ni - Po worlds.

They're just as rare as Na - In - Po worlds and also found in the Spinward Marches.

More World colors... .