As Above So Below - Yet another Traveller System Generator

[Bartleby]

v0.7.3 is out:

1. **Mongoose Socioeconomic:** Fixed bug that did not check if Ix, Cx, or Ex could be inherited
2. **Mongoose System Expand:** Fixed bug that did not make use of T5 Stellar information and PBG
3. **Import Sector .tsv:** Fixed bug that did not capture Worlds value
4. **Generate Xboat:** Added user options on range and jump distances
5. **Import Imperium:** Added the option to bulk import Imperial Sectors

 

[Bartleby]

v0.7.4 has been pushed into production.

You can now try to import the entire OTU (not for the feint of heart!)


Some quick notes on Importing the Universe:
1) I have a one second wait time for each sector - so it takes a bit to load everything
2) Make sure to Save the JSON once you load it, so you never have to import it again - just load from your hard drive
3) It will be its most sluggish when zoomed out, and most responsive when zoomed in.
4) It will not work well for older or slower systems. Hell it is too frustrating for me zoomed out and I have 32GB memory.
5) This was done as a request by a user with some good system specs
6) Having all of these sectors loaded at once was not the intention of this program. I do, however, appreciate a challenge. So if you think you would enjoy working like this and have the right system for it, be my guest.

Replacing Foreven:
Want to replace any of these sectors with your own file (like Foreven)?
1) Mouse over the sector you want to replace (zoom in for smoother and better response results)
2) Press Control + S to select the Sector (you should see it highlighted)
3) Right Click->Populate->Manual Reset Clear (Note the sector # in the Clear Hex; 36 for Foreven)
4) Click the settings gear in the top right and choose Import Sector .tsv
5) Select your file - choose the sector number you noted (#36 for Foreven)

Notes on Size Limits:
1) If you do not ever expand the system generation you can operate large amounts of systems as long as it is not too frustrating to scroll. Your system specs will dictate how many sectors you can use before it is too frustrating to use (zoomed in is always better than zoomed out)

2) If you do want to expand system and socioeconomic information for each system (like I do) you will probably get to a limit of around 8 or 10 sectors before it will crash when you try to save your JSON. I have a number of options I am reviewing to expand this limit, but for now that is where we are. So if you download the Imperium and try to expand every system in every sector you will likely end up frustrated. For now you should be able to work safely with 8 or 10 sectors fully generated without too much of a problem.

Use it here: https://bartlebythecoder.github.io/traveller_magnus/hex_map.html
Full code here: https://github.com/bartlebythecoder/traveller_magnus

 

[Bartleby]

A new update this morning (v0.8).

This new version:
1) Makes it easier for slower and older systems to manage a larger amount of systems
2) Allows for the automatic plotting of routes constrained by any filter rules the user wishes to use (e.g. don't use X starports)

In a point to point route the path only stops at filtered systems (in this example from Terra to capital only systems with Gas Giants and pop codes >6):



In the below homebrewed sector the green routes are xboat routes, the gold routes are automated trade routes connecting 10+ WTN worlds within a range of (I think) 6 hexes, using max Jump 2 routes to connect them. The blue route is an automated Jump 6 route going between two important worlds.



There is more I want to do with routes but this is a good start.

As always this is free and still in development so feel free to use but understand things will change and not everything may be perfect yet.

Use it here: https://bartlebythecoder.github.io/traveller_magnus/hex_map.html
Full code here: https://github.com/bartlebythecoder/traveller_magnus

 

[Spinward Flow]

In a point to point route the path only stops at filtered systems (in this example from Terra to capital only systems with Gas Giants and pop codes >6)

I'm kind of curious how many jumps would be involved in that route?
The reason why I'd like to know that bit of trivia is that is gives a sense of "how much time lag" there is between those two points on the map. If you assume 24 jumps per year (standard commercial op tempo) ... how many weeks/months/years would such a journey take?

This is where the "friction" of communication lag times starts becoming the most apparent, which then translates into a sort of inertia AND centrifugal forces breakup around the fringes of an overly large polity because distant places are "too far" from the center to command & control effectively. Authorities have to be delegated (feudal style), which then sows the seeds for potential civil war when ambitions outweigh loyalties (anyone got any matches?).



Nothing to do with mapping the stars (per se), but it is the kind of Big Picture™ insight that can be gained from having such an excellent mapping tool.

After all, one of the better ways to Collect Taxes (or conduct business, profitably ... ) is to start with Better Maps.
Funny how that works ...

 

[Bartleby]

I'm kind of curious how many jumps would be involved in that route?
The reason why I'd like to know that bit of trivia is that is gives a sense of "how much time lag" there is between those two points on the map. If you assume 24 jumps per year (standard commercial op tempo) ... how many weeks/months/years would such a journey take?

This particular route (J-4, pop 7 or higher and always a gas giant) is 45 Jumps.
Another route someone in the Mongoose forums asked about (J-6, total pop 500m+, and always a gas giant) is 33 Jumps.

 

[Spinward Flow]

This particular route (J-4, pop 7 or higher and always a gas giant) is 45 Jumps.
Another route someone in the Mongoose forums asked about (J-6, total pop 500m+, and always a gas giant) is 33 Jumps.

No matter how you slice it ... that's a LONG HAUL.
It basically means that any "round trip" communications (origin > destination > origin) are going to take over a year ... and probably 2 years (or even more!) ... and that's just the amount of time needed to make all the jumps. Any time at "the far end" of that round trip needed to make any ... decisions ... based on the contents of the communication will increase the time it takes to make a round trip (report > decide > action).

That kind of communications lag can be CRIPPLING to centralized command & control authorities, because the information you receive could be a year old at the center and can't be implemented for a year after a reply gets sent back. Meanwhile, real time on the fringes isn't stopping/waiting for the bucket brigade of message relaying via jump to resolve matters.

Seen in that light, it's surprising that the Third Imperium lasted as long as it did ... mainly via delegation of important decision making powers away from central authority.

 

[kilemall]

No matter how you slice it ... that's a LONG HAUL.
It basically means that any "round trip" communications (origin > destination > origin) are going to take over a year ... and probably 2 years (or even more!) ... and that's just the amount of time needed to make all the jumps. Any time at "the far end" of that round trip needed to make any ... decisions ... based on the contents of the communication will increase the time it takes to make a round trip (report > decide > action).

That kind of communications lag can be CRIPPLING to centralized command & control authorities, because the information you receive could be a year old at the center and can't be implemented for a year after a reply gets sent back. Meanwhile, real time on the fringes isn't stopping/waiting for the bucket brigade of message relaying via jump to resolve matters.

Seen in that light, it's surprising that the Third Imperium lasted as long as it did ... mainly via delegation of important decision making powers away from central authority.

That suggests the functional sector capitals are the naval depots.

 

[Bartleby]

Next up:

For the next few days I will be working on the v0.9 releases. These will, bit by bit, enable the editing of the expanded system details. In case you don't like what was generated or perhaps have a manual generation you want to input.

While working on that I will be thinking about how to improve the routing as I have a lot of disparate ideas I would like to get into one cohesive vision. The new routing will be part of the the v0.10 series that will follow.

Within these two series I will be adding in obsidian/markdown file exports. Likely part of v0.9 but not 100% sure yet.

Anyway, more to come.

 

[Bartleby]

Released version 0.9.3 this afternoon:
1. **Mongoose Editable System Fields:** Many Mongoose system fields now inline-editable. Edited fields are highlighted and persist in the workspace JSON. This includes the ability to add names to each world and moon.
NOTE: Some fields, like atmosphere, are still not editable and you still cannot add or delete worlds or moons. I would like to eventually allow a user completely build out a new system by hand with full control, so I still have it on the list.
2. **Corrected Stellar Generation Tables:** Star physical properties (mass, diameter, surface temperature) are now derived from accurate per-luminosity-class tables with subtype anchors, rather than a single averaged value per spectral type. Giant, dwarf, and subdwarf stars now have physically distinct and correct statistics. NOTE: White Dwarf and Brown Dwarf stars have one simple average used for their key stellar information. Thank you to @Dodo98
3. **Fixed Missing Companion Rolls for Primary Star:** Previously, only secondary stars (Close, Near, Far) received a companion roll. The primary star now also rolls for a companion, matching the full rules requirement that every star in the system gets a companion check. Thank you to @Dodo98
4. **Improved HZCO calculations**
5. **Accordion Display Polish:** Cleaned display and added atmospheric pressure to UI.
6. **Octagon Filter Symbol:** Added an octagon as a new shape option in the Advanced Filter styling panel.
7. **Gas Giant Ring Visibility:** The ring symbol on gas giants is now 2–3× thicker, making it clearly visible when zoomed out to subsector or sector scale.



Next up (v0.10.x) will center on revamping our routes/filters/customization and metadata. This will include adding borders and routes to the OTU downloads.

 

[Bartleby]

I published one more update in my v0.9 series. v0.9.3.2 was uploaded yesterday. It corrects some generation errors in the Mongoose orbit spread and hzco calculations.

It also now imports xboat routes automatically when you import the OTU or the Imperium. It takes twice as long now, so make sure to save your JSON once you import (load from a JSON is much quicker).





The next release will focus on routes. What I want to include:

Routes:
1. Allow for different specific routs with customizable colours and labels. Sure I can make the default Route #1 Green and call it Xboat, but the colour and the label should be allowed to be changed by the user
2. Add as many routes as I want
3. Routes can be automatic (using the filter rules to set them) or manual or any combination thereof (i.e. I should be able to manually change a route that was generated automatically)
4. I should be able to change the colour of each or any route later if I want to
5. I should be able to hide/unhide each route individually
6. Bring all route generation and modification into one simple menu (it is scattered right now)
7. Routes that overlap should be displayed side by side. One should never cover the other. I may actually decide on a different offset for each route #. E.g. Route #1 is always down the middle. Route #2 always to one side etc.
8. OTU routes should be downloaded into Route #1/XBoat by default.
9. Special for me: I want to be able to build routes automatically by filtering on combining WTN numbers like GURPS.

Let me know if you have any requests for updates.

 

[Spinward Flow]

Routes:
1. Allow for different specific routes with customizable colours and labels.

Something that would be extremely handy, especially as an aid for Referees and Players would be to define a collection of worlds as a "grouping" for commercial purposes. This could be a subsidy range of "in-group" systems or it could be used to define a "preferred pathing" for a specific commercial trade route that would be getting run at regular intervals (like "trains running on time") for commercial operations.

Being able to pull up a map of a (sub)sector and SHOW everyone (Referees and Players alike) that THIS is the subsidy range/authorized route that you're obliged to operate within (or which the campaign will just so happen to be set as a starting point? ) can be really helpful as a way of getting everyone involved oriented and thinking about possibilities, risks/rewards and so on (and so forth).

While this kind of functionality can be PARTIALLY done using shading of specific hexes with various colors (to indicate "here" and "not there"), being able to use the Route function would enable all kinds of additional functionality, such as being able to tell "how far from here to there" and what intermediate stopover points may be necessary along the way. Knowing how many jumps it would take to get from Regina/Regina/Spinward Marches to Equus/Lanth/Spinward Marches using a variety of jump numbers (including 2x jumping through empty hexes to "shortcut" across voids!) could have a lot of potential as an assistant tool for being able to make "longer" routing plots beyond the immediate next destination.

Taken to extremes, this kind of routing feature can be used to determine the "jump lag" for communications between various points on the map (including across multiple sectors, if necessary).

Being able to determine "jump lag" delay timing in communications can have implications for all kinds of things, including (but not limited to) wanted notices and bank repossession ops against assets where businesses that have started "skipping" their mortgage payments. Giving Referees (and Players) "how long" they might be able to outrun "the long arm of the law" can be a useful insight/bit of intel for all kinds of adventure seeds/patron encounters.

 

[kilemall]

Something that would be extremely handy, especially as an aid for Referees and Players would be to define a collection of worlds as a "grouping" for commercial purposes. This could be a subsidy range of "in-group" systems or it could be used to define a "preferred pathing" for a specific commercial trade route that would be getting run at regular intervals (like "trains running on time") for commercial operations.

Being able to pull up a map of a (sub)sector and SHOW everyone (Referees and Players alike) that THIS is the subsidy range/authorized route that you're obliged to operate within (or which the campaign will just so happen to be set as a starting point? ) can be really helpful as a way of getting everyone involved oriented and thinking about possibilities, risks/rewards and so on (and so forth).

While this kind of functionality can be PARTIALLY done using shading of specific hexes with various colors (to indicate "here" and "not there"), being able to use the Route function would enable all kinds of additional functionality, such as being able to tell "how far from here to there" and what intermediate stopover points may be necessary along the way. Knowing how many jumps it would take to get from Regina/Regina/Spinward Marches to Equus/Lanth/Spinward Marches using a variety of jump numbers (including 2x jumping through empty hexes to "shortcut" across voids!) could have a lot of potential as an assistant tool for being able to make "longer" routing plots beyond the immediate next destination.

Taken to extremes, this kind of routing feature can be used to determine the "jump lag" for communications between various points on the map (including across multiple sectors, if necessary).

Being able to determine "jump lag" delay timing in communications can have implications for all kinds of things, including (but not limited to) wanted notices and bank repossession ops against assets where businesses that have started "skipping" their mortgage payments. Giving Referees (and Players) "how long" they might be able to outrun "the long arm of the law" can be a useful insight/bit of intel for all kinds of adventure seeds/patron encounters.

For hardcore types you could lay out routing by industry- raw materials flowing to manufacturing planet, and delivery of products to downstream customers.

 

[Bartleby]

Something that would be extremely handy...

I am having trouble grasping this. But I really like what I am grasping. Can you give me some examples of how this would work once it is implemented so I can get a better picture?

 

[Spinward Flow]

Something that would be extremely handy, especially as an aid for Referees and Players would be to define a collection of worlds as a "grouping" for commercial purposes. This could be a subsidy range of "in-group" systems or it could be used to define a "preferred pathing" for a specific commercial trade route that would be getting run at regular intervals (like "trains running on time") for commercial operations.

Something that I did (years ago, now) was a Race To Profitability ... pitting a starship class I designed against a J2 Far Trader on a route through Lanth and Vilis subsectors. The starship class I'd designed was TL=D, so I needed a TL=D world in a subsidy grouping to use as the annual overhaul maintenance hub.

The "race" was a sort of Test™ in which the two designs would run the exact same route and "share" all of the dice rolls for cargo/passenger ticket opportunities, the dice rolls for speculative goods opportunities and for "random encounters" between the jump point(s) and the main world(s). So the only real/meaningful differences in "performance" over the course of the race would be the Design Details™ between the two starships, which would then produce derivative effects that could be computed in terms of profitability when calculating revenues earned versus costs incurred.

Long story short ... my design and the Far Trader were "relatively evenly matched" ... until there was a encounter with a purloined Type-T Patrol ship. The Far Trader had to surrender, while my design (basically a minimally armed Fast Trader) was able to escape with a "clean pair of heels" thanks to a powerful maneuver drive (so Break Off By Acceleration was successful). That basically decided the "race" right there, since the Far Trader had to "pay a ransom" to get their ship back ... and after that, it was all over (in terms of profit margin advantages).

Anyway, the section of the Spinward Marches that the race took place in was here:

So the "race course" was basically THIS ... running from D'Ganzio through Vilis to Ficant, before reversing back through Vilis to D'Ganzio.

I ran the whole thing as if both starships were operating under subsidy from Vilis, and the starting and finish lines were both at D'Ganzio, with an annual overhaul maintenance payment included in the total operating costs for the race.

As you can see, just drawing lines on the map like this (or using a hex shading option) would make it readily apparent which worlds are included in the subsidy range, where a subsidized starship would be obligated to spend 70% of each year conducting business:

1. Ficant/Vilis
2. Arkadia/Vilis
3. Garda-Vilis/Vilis
4. Choleosti/Vilis
5. Margesi/Vilis
6. Vilis/Vilis
7. Saurus/Vilis
8. Tavonni/Vilis
9. Lanth/Lanth
10. D'Ganzio/Lanth

You CAN leave this subsidy group (temporarily), but you need to be conducting trade operations between these worlds during at least 70% of the time each year, and each world needs to be visited at least once per year (is how I interpret the obligations for subsidies). The above mapping exercise would simply be a part of the Business Plan submitted to the subsidizing government for approval.



However, if I was an operator with a TL=9 J2+2 capable starship that I wanted to maximize the Speculative Goods Arbitrage profit potential of ... I would want to be conducting business between these mainworlds primarily:

Why?
Because of the variety of Trade Codes.

1. Nonym/Darrian: Non-agricultural, Poor.
2. Dekalb/Querion: Rich, Water World.
3. Thanber/Querion: Poor, Non-industrial.
4. Margesi/Vilis: Agricultural, Non-industrial. Amber Zone
5. Vilis/Vilis: Industrial.
6. Saurus/Vilis: Agricultural, Non-industrial.

Those 6 mainworlds include ALL of the Trade Codes relevant to Speculative Goods Arbitrage in LBB2.81.
However, you need to have J2+2 (unrefueled) capability in order to reach all of those destinations without needing to enter Sword Worlds Confederation or Darrian Confederation controlled space (so empty hex transit navigation is important!).

Suffice it to say, that this specific "collection of mainworlds" would offer a remarkably robust set of Speculative Goods Arbitrage Opportunities, simply because of the diversity of Trade Codes available between these 6 worlds.

This kind of "gotta get 'em all" distribution of Trade Codes with a "reasonable" range accessible by J2(+2) is actually something of a rarity in a place like the Spinward Marches. There are others (of course), but I'll leave the exercise for finding them to the Disinterested Observer™.

I am having trouble grasping this. But I really like what I am grasping. Can you give me some examples of how this would work once it is implemented so I can get a better picture?

Hopefully the above will give you something more "end user use case" in terms of example to work with.
The above is just a "quick 'n' dirty" bit of work editing my Portolan Chart™ method of remapping the Spinward Marches from years ago using an updated color scheme. I just did a copy/cut 'n' paste + annotate with lines to create the samples provided, so to be clear, I was not using As Above So Below for this.

 

[Bartleby]

OK, thank you spinward. So help me work through this backwards. When this is all done and implemented and you want to use it:

a) We have this new sub-group category, like your subsidy group. Let's call it, I dunno, Affiliation? For now we will call it Affiliation
b) The user can highlight any hexes he wants and right-click and assign them an Affiliation.
c) Users can filter on Affiliation, so any time they want they can filter to only those planets in this particular Affiliation
d) We can then go to the routes and instruct the auto-router to generate either a network route or a point to point rout through the Affiliated worlds.

Is that close? What else would we need?

 

[Spinward Flow]

a) We have this new sub-group category, like your subsidy group. Let's call it, I dunno, Affiliation? For now we will call it Affiliation

Affiliation works for this use case.
We're basically needing a way to discriminate "here, not there" in order to "confine" the routing to a specific set of (manually) defined possibilities.

b) The user can highlight any hexes he wants and right-click and assign them an Affiliation.

That works.
Highlighting is probably the "best use case" in this instance, because you could have something like a Tramp Merchant operation with a Home Port where annual overhaul maintenance (and thus, crew vacations) takes place as a matter of routine. So you've got an "anchor point" and everything spreads out from there, but you keep returning to the "anchor point" on a somewhat regular basis. Note that this kind of behavior also works for an interstellar patrol routine for naval assets at different levels of the hierarchy in organization, so there are military as well as commercial uses for this kind of application of mapping and navigation.

c) Users can filter on Affiliation, so any time they want they can filter to only those planets in this particular Affiliation

Correct.
Toggle on/off of the filter and rules associated with the filter then becomes the "value added" from developing this Feature Request™.

d) We can then go to the routes and instruct the auto-router to generate either a network route or a point to point rout through the Affiliated worlds.

Yes ... but ...
There's the precedent (which I'm making HEAVY use of in my own starship class research projects) of being able to double jump (J1+1, J2+2, J3+3, etc.) using the (main) integral fuel tankage PLUS additional fuel reserves (L-Hyd Drop Tanks, Demountable Tanks (internal or external), Collapsible Fuel Tanks). Being able to double jump thus makes it possible to use "empty hexes" as intermediate stopover points (as demonstrated on the map above ) in order to traverse a 4 parsec gap using a J2 drive performance (just add extra fuel).

Under MOST circumstances, a 6 parsec (total) range will often times wind up being the "practical maximum" when working in YTUs where 10% tonnage fraction per parsec is the rule.

Where this gets complicated, as an edge case condition, is when dealing with deep space fuel caches to get across truly LONG distances ... such as can be found in The Great Rift region (and elsewhere). There are settled worlds within The Great Rift that are 7-12 parsecs away from the nearest OTHER settled mainworld, which makes reaching those locations a matter that is logistically complicated. The Islands Cluster in the Great Rift is an example of this, being 7-8 parsecs away from the nearest stellar system on both sides of the cluster. Consequently, the only way to reach the cluster (without misjumping) is to 2x jump.

Being able to transit 7-10 parsecs can involve a mix of internal auxiliary fuel (demountable and/or collapsible fuel tanks) and/or external auxiliary fuel (demountable, again, and/or L-hyd drop tanks) in order to attain "sufficient" multi-jump capability in order to transit such vast expanses of space.

Note that:

• A starship capable of J2+2+2 range, if adding drop tanks (and dropping them) for the first jump ... would be capable of an 8 parsec range over 4 jumps.
• A starship capable of J3+3 range, if adding drop tanks (and dropping them) for the first jump ... would be capable of a 9 parsec range over 3 jumps.

Obviously, such fuel demands will reduce the revenue tonnage capacity of the starship making those transits ... but it's better than nothing.



Conceptually speaking, you want to be thinking of "empty" deep space hexes (whether there's a fuel cache there or not!) as a Calibration Point in terms of their usefulness for routing algorithms. Yes, there's no star or mainworld there ... and refueling might not even be an option(!) ... but such locations CAN be used as intermediate destinations to locations "on the far side" of the "empty" deep space hex, which WOULD have a star system and mainworld (and hopefully, refueling options!).



One of my favorite examples of "you can go there, but there's no fuel available" is Heroni/Rhylanor/Spinward Marches ... UWP: E7A0614-8

Starport: type E ... so no fuel available. LBB3.81, p10:

E Frontier installation.
Essentially a marked spot of bedrock with no fuel, facilities, or bases present.

Atmosphere: A + Hydrographics: 0 ... so no wilderness refueling on the mainworld.
Gas Giants: 0 ... so no wilderness refueling via orbital skimming either.

"This is some rescue! When you came in here, didn't you have a plan for getting out?"
- a Princess to her rescuers

Gets even better when you realize that Heroni/Rhylanor/Spinward Marches is a part of the J1 Spinward Main ... but if you think you can "go there" in a J1 starship without 2 parsecs of fuel range ... let's just say that your "stopover" on at that location might last longer than you'd planned ...

These kinds of BYO_BF (Bring Your Own _Beer Fuel) conditions can be found elsewhere in the Spinward Marches (as well as other sectors) at some mainworlds, so being able to "jump more than once" on a full load of fuel can make a difference in a multitude of circumstances, which in turn can require some "specialized modifications" to (stock) craft in order to enable such performance.



It would be NICE if the Routing Algorithm were constructed in such a way as to enable the option for multi-jumping (2+ without refueling) in order to find the "best" routing options available when transiting the map.

 

[Bartleby]

For hardcore types you could lay out routing by industry- raw materials flowing to manufacturing planet, and delivery of products to downstream customers.

So I understand, more than just auto-mapping a rout for Ni to In but by actual industry?

You know, the Trade Remarks section is totally free form. There is nothing stopping a referee making up a new code for a type of industry. Let me know how you think this might work.

 

[Bartleby]

Affiliation works for this use case.
We're basically needing a way to discriminate "here, not there" in order to "confine" the routing to a specific set of (manually) defined possibilities.

That works.
Highlighting is probably the "best use case" in this instance, because you could have something like a Tramp Merchant operation with a Home Port where annual overhaul maintenance (and thus, crew vacations) takes place as a matter of routine. So you've got an "anchor point" and everything spreads out from there, but you keep returning to the "anchor point" on a somewhat regular basis. Note that this kind of behavior also works for an interstellar patrol routine for naval assets at different levels of the hierarchy in organization, so there are military as well as commercial uses for this kind of application of mapping and navigation.

Correct.
Toggle on/off of the filter and rules associated with the filter then becomes the "value added" from developing this Feature Request™.

OK, I got you. Some sort of system for group assigning a sub-group or affiliation that can later be filtered. I can dig that.

It would be NICE if the Routing Algorithm were constructed in such a way as to enable the option for multi-jumping (2+ without refueling) in order to find the "best" routing options available when transiting the map.

OK. It is easy for me to say "yes of course, I can do that". So I will say it. Yes, of course, I can do that for you. But the devil is in the details. What sort of options are on the menu? What sort of levers can the player pull to customize the ask? Can you help me picture how this works?

 

[Spinward Flow]

But the devil is in the details. What sort of options are on the menu? What sort of levers can the player pull to customize the ask? Can you help me picture how this works?

The simplest method that I can think of would be to "enable" the following collection of options:

1. Routing does not require jumping to star systems (with mainworlds) exclusively.
2. Deep space hexes are "legal" steps for routing.
3. Deep space hexes fall into 1 of 2 categories:
   1. No refueling possible (empty space) ... this is the DEFAULT option.
   2. Refueling is possible (fuel cache, transfer station or other feature) ... this can be "enabled" but the hex has no star in it.
4. Program the routing algorithm to require refueling after # of jumps (default: 1), with the option to increase that number to 2+.

So the "ordinary" routing system works on a "one jump" basis, requiring refueling after every single jump.
Since deep space hexes have no refueling options (by default), they are (typically) "not used" for any kind of routing algorithm feature. The deep space hexes are "invalid" steps in a plot between origin and destination.

However, when you switch from a J* (one jump any) routing system to a J*+* (jump any+any) ... it's only when you can do J1+1 (or higher) that empty hexes in deep space can start to be used as "intermediate points" for longer routing options than can be achieved in a single jump.

From a UI perspective, you might need to define things by sequential jump numbers ... 2, 3 (or 2+3) for example for a 5 parsec transit.
You'd want to keep things a bit open ended on how many jumps can be made sequentially ... so as to be able to do things like "discover the J-5 Trans-Rift Hierate Route across the Great Rift" using a starship that is capable of J1+1+1+1+1 and thus has a 5 parsec maximum range (and would require a 50% jump fuel tonnage fraction as a result).



With Travellermap, you simply get the J1 to J6 options ... but if you want to do J2+2, you basically have to "fudge it" and use J4 instead to find the mainworlds along the route where refueling is necessary.

 

[Bartleby]

OK thank you. I will give this a shot. Working on v0.10.0 right now but this might be ready for a later v0.10 release next week.