Spica, still in review, has a handful of embassies.
OTU Only: T5SS Semi-Official Thread
- Thread starter DonM
- Start date
I seem to recall Don applied each of the possible solutions:
1) re-review the stars in the area for other potential matches.
2) Apply an "Mr" (Military Rule) or "Rs" (Reserve) trade code.
3) Change the government type.
Because the system isn't working correctly. You have pointed out a bug in my code. I'm currently working on fixing it. The "Nearby" isn't as nearby as it should be.
What has to happen, criteria, for a sector to be accepted into In Review? I have been working on Knoellighz for over a year and suspect there is more work to be done.
Like I said, this is a bug in the check code. I want to say thank you for pointing this out because the "nearby" check is central to the whole of the trade route generation process. It it's missing nearby worlds, the routes are going to be bad.
I've attached an updated owned worlds sheet here. If you see any more weirdnesses please let me know.
Oh, hurray you're still around. I've finished transcribing the Ex and Cx values from your working page into the data pages for the worlds. This lets me generate a full world list.
I have found a few missing bits that need fixing.
- Based upon the conversation above, all the worlds with dual bases need to have their Ix values updated.
- One world is missing the Ex and Cx values.
- There are three or four populated worlds with the PBG of 000
- I should give you the Owned Worlds report for the sector.
For Gashikan and Trenchans sector, (Edit: and Tienspevnekr ) the lint process points out that for Non-industrial world (Ni) the economic extension (EX) Infrastructure value should be 1D + Importance (Ix). The linter process is pointing out some of these worlds have Infrastructure values off the high end of the scale. It looks like they may have been generated with 1D (no modifier).
Last edited:
Is the formula "only" looking out 4 parsecs for owners? The T5 rules call for the highest Importance world within 6 parsecs.
So Tiamat (Canopus 2404) and Valence (Canopus 2202) currently have Castine (Canopus 2007) as their owner, which is 5 and 6 parsecs away. But the formula only recommends the less-Important Tanqueray (Canopus 2103) and Baxter Station (Canopus 2407) or Klimovsk (Canopus 2001).
That said, I really think 6 parsecs is too far and 4 seems a much more reasonable limit.
I have found a few missing bits that need fixing.
Can I get a PM with a worklist rather than try and hunt down each erroneous world in Knoellighz? I want this Sector to attain In Review as I find it has so much story potential for such a distant region that pits Zhodani up against the Vargr Extents/Splinters.
- Based upon the conversation above, all the worlds with dual bases need to have their Ix values updated.
- One world is missing the Ex and Cx values.
- There are three or four populated worlds with the PBG of 000
- I should give you the Owned Worlds report for the sector.
Can I get a PM with a worklist rather than try and hunt down each erroneous world in Knoellighz? I want this Sector to attain In Review as I find it has so much story potential for such a distant region that pits Zhodani up against the Vargr Extents/Splinters.
Yep, bug in my tool. Your linter is great!
I regenerated Infra for those three sectors. (I could have left non-Ni worlds untouched but it wasn't worth it.)
How does it look now?
Ultimately it comes down to Marc's desire for a consistent data set. Don was tackling published sectors - the Atlas of the Imperium set of 35, the QLI ones (Gate, Cruc), the classic Land Grants (Thet, FarF, Vang, Beyo), Ziaf and Gvur (covered in MgT, etc). Akti/Uist/Ustr were rolled in on Marc's request to flesh out Aslan space. Don's last batch added Tugl/Prov/Wind/Mesh/Mend/Amdu; I'm not sure of the priority for tackling those but an eye towards designing the 1900 era probably played a part. (And having a sector-wide buffer around the Imperium is appealing.)
I tackled the most recent batch - #1 Cano/Alde/Newo/Lang, #2 Tien, and #3 Gash/Tren for distinct reasons: #1 because I knew Garnfellow had done meticulous research and prepared T5 data for them so the process of shaking out bugs would be informative (as is happening here); #2 because GypsyComet is always handy, had done updates earlier this year, we needed experience upgrading pre-T5 data, and Zho sectors are relevant (see below), and #3 on Marc's request for exploring the development of the Ziru Sirka.
So a mix of pragmatism, personal interest, and explicit direction.
Other bonuses: stable data (e.g. FreeTrav's Gash/Tren designs have been sitting around for years) or an active developer with time for research and review, and able to incorporate feedback (e.g. GypsyComet and Garnfellow)
Indeed.
I seem to recall sending you some errata that never got addressed. But beyond that...The next big T5SS project, on Marc's request, is tackling Zhodani space. Specifically, we need to flesh out the unmapped Zhodani sectors and revise the coreward borders of the Consulate, which should match the classic posters rather than the dotmaps in Vilani and Vargr. This affects Stiatlchepr, Itvikiastaf and Knoellighz and requires generating Sidiadl and Eiaplial. (Any takers? I'll also be pinging BeRKA.)
Like I said "nearby" is a vague term.
Warning: long-ish technical explanation
The trade map generator uses a graph for the base data structure. A graph (in the computer science data structure sense) consists of a set of nodes and edges.
For the trade map generator, each world on the map is a node. In the graph the edges connect the nodes together, representing possible paths between nodes. In the setup for the trade generator, the system generates an edge between every pair of worlds within a maximum jump distance. For the generator, the default maximum is 4 parsecs, and I usually run it with a maximum of 5 parsecs.
As part of each edge I track it distance (in parsecs), the Bilateral Trade Number (BTN) between the two worlds, and a weight for the route.
To actually generate the trade routes, the system uses a route finding algorithm called A*. The process generates a route between (almost) every pair of worlds on the map following the edges between the intermediate worlds.
The A* Route finder is very efficient, but if you give it too many options for possible routes it takes much longer to process. So as an optimization I remove some of the edges. In this case I remove the longer (J-5 first, then J-4, and so on) and the lower BTN routes first for each distance.
The generator sets a maximum of 20 and a minimum of 10 routes for each system. So depending upon local stellar density the maximum distance averages between J-3 to J-4. For lower density areas, it may include one or two J-5 links. For really high density areas it may only include the J-2 links.
The owned worlds report just checks the set of edges from a given (owned) world to find potential owning worlds. So yes, it checks some or most of the worlds within J-3 or J-4 for potential matches.
When I explained this to Don as I was developing it, he was fine with it's limitations. It was a 90% solution, meant to resolve the mostly boring cases, and letting him work on the more interesting (i.e. exceptional) ones. He specifically requested the list to allow selection of an interesting case. I know I wasn't aware, and I'm not sure Don was either, of the T5 rule for owned worlds.
I can do this as a option if you would like. It will take me a day or so to write and test the processing loop.
Honestly, I wouldn't bother -- I think 4 parsecs is a much more reasonable limit for 90% of the cases.
All three sectors load without any notes now, meaning they are clean as far as my lint checker is concerned.
I've attached the owned worlds report for Trenchans and Gashikan. None of the owned worlds have any owners listed. I verified by visual inspections.
I will also note that the sectors rimwards: Amdukan, Mendan, and Meshan (also listed in review) are missing their owners as well. These three sectors are lint free too. Do you want a report for these three sectors as well, and can fix all five in one go?
Yes please!
Zhodani Consulate
BeRKA is on board to help. Any other volunteers to tackle Zho space? I'll coordinate things (shared docs, tools, etc).
Thomas: is it possible to share your linting tool? Maybe we can make a web-based version so developers can also check their own work before it gets to us? (Validate early and often!)
BeRKA is on board to help. Any other volunteers to tackle Zho space? I'll coordinate things (shared docs, tools, etc).
Thomas: is it possible to share your linting tool? Maybe we can make a web-based version so developers can also check their own work before it gets to us? (Validate early and often!)
The linting tool is part of the Traveller PyRoute trade map generator code. The lint code itself is part of the read processing in the Star.py.
I am not at all a web designer. I do databases and back end development. I understand and can write code in almost every language, except anything to do with UI layout and processing. Web page design is especially far into no-understanding mode for me.
Part the second. I added more linting to check the Cultural extension values. For this I came across two issues:
1) The definition table on p. 411 says the minimum value for any of the CX values is 1. In a review of some of the sectors I found some CX values set (incorrectly) to 0.
2) It has been common, but not universal, practice to set the CX values for barren (Ba, Di) worlds to "[0000]". I wanted to make this either required or forbidden.
This also brings up an interesting corner case. It is legal to have a UWP population of 0, but still have the population multiplier (PBG) be greater than 0. What is the correct trade code (Ba or Lo) for this world? I have found real versions of the case, one in the TNE data from the Regency Sourcebook, one in the Knoellighz data.
I am not at all a web designer. I do databases and back end development. I understand and can write code in almost every language, except anything to do with UI layout and processing. Web page design is especially far into no-understanding mode for me.
Part the second. I added more linting to check the Cultural extension values. For this I came across two issues:
1) The definition table on p. 411 says the minimum value for any of the CX values is 1. In a review of some of the sectors I found some CX values set (incorrectly) to 0.
2) It has been common, but not universal, practice to set the CX values for barren (Ba, Di) worlds to "[0000]". I wanted to make this either required or forbidden.
This also brings up an interesting corner case. It is legal to have a UWP population of 0, but still have the population multiplier (PBG) be greater than 0. What is the correct trade code (Ba or Lo) for this world? I have found real versions of the case, one in the TNE data from the Regency Sourcebook, one in the Knoellighz data.
No worries - I can wrangle it. Just the list of checks is extremely helpful.
Ignoring [0000], looks like that's present in Cano/Gash/Lang/Newo/Tien/Tren, i.e. just this new batch.
In Garnfellow's it occurs in Strangeness (pre-generated), which would be a glitch in his generation code.
In Gash/Tien/Tren (ones I T5ified) its because I'm not forcing the Homogeneity/Strangeness/Symbols values to 0 for Pop=0 worlds, but the spreadsheet auto-generates Acceptance as 0. I've fixed (forced those all to [0000])
Agreed. I'd prefer [0000]. That's what the spreadsheet has, so I assume it's Marc's desire, so an errata item.
It has a sensible interpretation - it's literally the number of people on the planet - but I agree it's silly. We can consider the TNE entry a bug and we have the author of Knoellighz here on this thread...
Any world in my data with a pop > 0 and strangeness of 0 should definitely have a strangeness of 1. That's a great catch -- I appreciate having many eyes on this data.
The generation code seems to working OK now, so I can't explain why it threw up those errors. Weird.
Similar threads
