Questions about the starsystemdef_ files

[MarkDey]

I've written a script to take all of the information in these .json files and put them into a single tab delimited file for analysis and comparison. The output of the script is attached (it's a flat file, and I haven't done much formatting to make it less raw).

As I was looking at this, I had a few questions.

Entries that are the same in all starsystem .json files: MapRequiredTags, MapExcludedTags, ShopRefreshRate, ShopMaxInventory, SystemInfluence, StarPosition, UseSystemRoninHiringChance, RoninHiringChance

Entries that I have questions about:
FuelingStation (59 TRUE out of 256 starsystemdef_ files. What is this for - unimplmented detail for flying the Argo?)
TravelRequirements (Is this used to limit the systems accessible during the story campaign?)
Depletable (8 TRUE out of 256 starsystemdef_ files: Alloway, Bellerophon, Detroit, UrCruinne. What is this for?)

 

[Pode]

Fueling station isn't used IIRC, it indicates a system that has a fast charger for jumpships so you can move thru it in hours versus solar recharging for a full week. I think they gave up on that level of detail for traveling.

You got it on the TravelRequirements

Depletable is the 4 starting worlds (and their career twins) and flags them so that new contracts don't generate, in order to force players to take the first story missions and move things along so that more worlds unlock.

 

[MarkDey]

Cool - thanks!

I'm also trying to recreate one of the reference sheets that @ninte000 made which had systems listed as well as the names of systems that could trace a transportation route through that system. Does anyone know where the inter-system links are defined?

For example, in the old sheet, I see that Bonavista has connections to New Abilene and Joppa. If I can figure things out for the 1.6 list of planets, then it would be possible to plot a good course through high-value systems with a minimal transit time so that the 'visit 170 systems' category in the career scoring mode can be maxxed out.

 

[Pode]

There's not a list of linked systems defined in game files, it just checks that the distance between any two systems is less than 30 LY

 

[MarkDey]

Oh! Good to know. For the x,y position data listed in the starsystemdef_ files, do you know how that maps to Light Years?

For example, if I had a system at 30,500 and another system at 50,500 then the difference is 20 units away. Is that a direct mapping so the system would be 20 LY away?

If so, that would let me programatically determine system adjacencies.

 

[Pode]

Yeah, the units are light years and Terra is the origin, with positive directions being galactic coreward and spinward

 

[Kwic]

Any chance you could post the script for others to use?

Or perhaps code a script to write from a the csv file to individual json files?

 

[MarkDey]

Sure! I've worked on things a bit more and have attached a .zip file with the work. @ninte000 made the 'jump distance planet skull employers.xlsx' and 'travel planning.xlsx' files and I think they were accurate for game version 1.4. The other files are a Perl script, the raw tab-delimited file output, and a 'careerBTsystems.xlsx' file that has been prettied up and summary statistics added to the bottom.

Some more can be done to improve the output of the script, but one thing I'd really like to do is figure out how to programatically determine adjacency within 30 Light Years. The coordinates are all there, I just haven't looked up the math that would be needed to make that determination. If anyone has already done that, or would be willing to assist, I'd certainly appreciate the help!


P.S. ComStar doesn't actually employ mercs in the game, even though 5% of the systems have them listed as an employer, right? I've never seen it...

 

[Pode]

For systems 1 and 2 at locations (x1,y1) and (x2,y2), the distance between them is less than 30 LY if

900 >= (x1 - x2)(x1-x2) + (y1-y2)(y1-y2)

Pretty sure all z coordinates are zero, but if not then add (z1-z2)(z1-z2) as well.

 

[ronhatch]

One oddity as far as figuring out optimal paths is that you don't have direct control over which systems you jump through to get to a particular destination. That can matter quite a bit when you're trying to skim without leaving the jump point.

Not sure exactly what the algorithm is for that pathing. Just from observation, I suspect that part of it is that when multiple valid options for a jump exist, it uses the option that puts you closest to your destination, with distance in light years breaking any ties in the number of jumps.