Utilitarian Star System Generator

[coolAlias]

Do you guys (@coolAlias and @Geir ) think it would be possible to bring this great work together into a T5 style webpage? It just seems a shame that you have created an elegant, up to date system for generating start systems but the Traveller Tools webpage on the Mongoose site links to Traveller Worlds. I don't imagine it needs a icomap, just the raw data as presented in your generator.

It's totally possible, yeah, but someone other than me will have to do that - I have no interest in setting up and maintaining a web page, sorry.

That's why I wrote a tool that can be run completely offline.

 

[ColinD]

If you mean 2 stars, enter the desired star profile(s) under the Continuation Method section.

If you mean 2 planets, you can also enter those quantities under the Continuation Method.

If neither of those work for you, the tried and true method is to simply modify the system output however you see fit on paper, spreadsheet, or some other medium. The script is really just a tool to give you a starting point - don't let it stifle your own creativity.

Thanks for replying! How should I enter the star data? I want to put in M0 V and M2 V.

 

[coolAlias]

Thanks for replying! How should I enter the star data? I want to put in M0 V and M2 V.

I copied the format from the WBH, so delineate each with a colon, e.g. M0 V:M2 V.

 

[ColinD]

I copied the format from the WBH, so delineate each with a colon, e.g. M0 V:M2 V.

View attachment 3488

Thanks so much! This is great.

 

[GabrielGABFonseca]

I don't exactly recall if you're still developing this (most excellent) tool @coolAlias, but on the off chance that you are;

I've noticed a peculiar bug - the first planet in the system generated from seed 789be5cfd440 has the atmospheric code of '1 - Trace', but a pressure of 0.549.

I checked the roll log and for the pressure it got a 44 on a D100; some quick double-checking and it seems like whatever happened in the backend, despite being a 'trace' atmosphere, it has used the values for Thin atmospheres instead to generate the pressure (Minimum Pressure Range 0.43 + Span 0.27 * 44/100 = 0.5488 ≈ 0.549)

I wish I could track the bug down further than that, but alas, when it comes to html that's the extent of my abilities I'm afraid.

 

[coolAlias]

I don't exactly recall if you're still developing this (most excellent) tool @coolAlias, but on the off chance that you are;

I've noticed a peculiar bug - the first planet in the system generated from seed 789be5cfd440 has the atmospheric code of '1 - Trace', but a pressure of 0.549.

I checked the roll log and for the pressure it got a 44 on a D100; some quick double-checking and it seems like whatever happened in the backend, despite being a 'trace' atmosphere, it has used the values for Thin atmospheres instead to generate the pressure (Minimum Pressure Range 0.43 + Span 0.27 * 44/100 = 0.5488 ≈ 0.549)

I wish I could track the bug down further than that, but alas, when it comes to html that's the extent of my abilities I'm afraid.

Thanks for the detailed information, I was able to track it down and push a fix.

What was happening is due to the location of the planet so close to the star, the atmosphere type was rolling in the first column of the Hot Atmospheres table on page 94, gets a 5 for Thin atmosphere, but then also has to roll on the table below, which you can see it rolls a 1 for Atmosphere Type: Orbit < HZCO-3 in the log, setting the atmosphere type back to Trace.

However, I had already set the density by this point based on the Thin atmosphere, so I just had to reset it.

 

[coolAlias]

Thanks to user makario, fixed an edge case that was broken due to a typo on my part where Class IV Typ O stars should have changed to Type B, but weren't.

Due to downstream effects, this may result in unpredictably different output for any previously generated seed that would have run into this particular edge case.

If any of you run into that, please drop the seed and settings - I'm always curious to compare the old vs. new output.

 

[LangyMD]

I've added the culture/tech/military/economy/starport profiles for the mainworld (ignoring special rules for balkenized worlds and secondary worlds) in a version on my github. I've created a pull request back to the original repo as well.

 

[coolAlias]

I've added the culture/tech/military/economy/starport profiles for the mainworld (ignoring special rules for balkenized worlds and secondary worlds) in a version on my github. I've created a pull request back to the original repo as well.

Thank you so much, this looks great! Your PR has been merged.

 

[GabrielGABFonseca]

I think I might have run into another possible bug. I've recently generated a system with the seed 020201, which came out as a singleton M6V star with 5 terrestrials around it – 0.144 M⨀, 0.216 Diam⨀, 0.00278 L⨀. Its Baseline number is 4, and the Baseline Orbit 0.142.

Then I noticed the System Spread is 2.199. I think this might be in error.

From Page 48 of the WBH, the System Spread is calculated as (Baseline Orbit# - MAO)/Baseline Number. Using the guidelines on page 38, the MAO for a star of 0.216 Diam⨀ would be 0.01 × 0.216 = 0.00216 AU = Orbit 0.0054 which rounds up to 0.01.

Thusly, using the formula from Page 48, shouldn't the Spread thus be (0.142 - 0.01)/4 = 0.033 instead...?

There might be some special rule or edge case I'm missing, but as far as I understand the rules...

 

[coolAlias]

I think I might have run into another possible bug. I've recently generated a system with the seed 020201, which came out as a singleton M6V star with 5 terrestrials around it – 0.144 M⨀, 0.216 Diam⨀, 0.00278 L⨀. Its Baseline number is 4, and the Baseline Orbit 0.142.

Then I noticed the System Spread is 2.199. I think this might be in error.

From Page 48 of the WBH, the System Spread is calculated as (Baseline Orbit# - MAO)/Baseline Number. Using the guidelines on page 38, the MAO for a star of 0.216 Diam⨀ would be 0.01 × 0.216 = 0.00216 AU = Orbit 0.0054 which rounds up to 0.01.

Thusly, using the formula from Page 48, shouldn't the Spread thus be (0.142 - 0.01)/4 = 0.033 instead...?

There might be some special rule or edge case I'm missing, but as far as I understand the rules...

You are correct, however it is not a bug but an intentional choice to handle the edge case when the spread is very small compared to the number of planets in the system.

In other words, this is an example of a system where the planets would end up super clumped together using the math as written.

To test this for yourself: open up star_gen.html in an editor, search for "System Spread of" and add "// " to the line immediately after it (line 4599 if your editor supports line numbers), so it looks like this:

log('System Spread of ' + system.orbit_spread + ' is far smaller than Max of ' + system.orbit_spread_max + '; increasing by +' + (spread_half + spread_mod));
// system.orbit_spread = round(system.orbit_spread + spread_half + spread_mod, 3);

Then refresh the page in the browser and re-generate the system.

You'll see the planets start in Orbit# 0.05 and only go up to #0.19.

Perhaps that's preferable in some cases, and I do see I left myself a note to add an option to choose whether to roll as written or use my tweak, but I never got around to implementing that.

 

[GabrielGABFonseca]

You'll see the planets start in Orbit# 0.05 and only go up to #0.19.

Perhaps that's preferable in some cases, and I do see I left myself a note to add an option to choose whether to roll as written or use my tweak, but I never got around to implementing that.

I don't think that "compactedness" is an inherent problem, though. It's a phenomenon that would mostly be confined to low-mass, low-luminosity stars like late M-Type Red Dwarfs, which is actually fairly realistic. Consider; the TRAPPIST-1 system, for instance, has its planets all orbiting within the Orbit#0.02885 to Orbit#0.154725 range! It's actually fairly common for exoplanetary systems around Red Dwarves to be very compact.
I can see this being a problem, however, if the Baseline Number spits out a 'hot' system with many planets closer than the HZCO...

But I think having that as a togglable option would indeed be ideal!

 

[coolAlias]

I don't think that "compactedness" is an inherent problem, though. It's a phenomenon that would mostly be confined to low-mass, low-luminosity stars like late M-Type Red Dwarfs, which is actually fairly realistic. Consider; the TRAPPIST-1 system, for instance, has its planets all orbiting within the Orbit#0.02885 to Orbit#0.154725 range! It's actually fairly common for exoplanetary systems around Red Dwarves to be very compact.
I can see this being a problem, however, if the Baseline Number spits out a 'hot' system with many planets closer than the HZCO...

But I think having that as a togglable option would indeed be ideal!

Agreed - options are good!

 

[coolAlias]

Here you go: https://github.com/coolAlias/star_gen/commit/ab01a25005e1ca29da5b171e94e5339377adc18a

Enjoy!

 

[MarcusIII]

Amazing! You rock!!!

 

[GabrielGABFonseca]

Aw man... I hate to be giving you work, but I think I might've found another bug, and this one will probably not be a trivial fix...

Using system seed 020201 as an example, the innermost planet has Orbit#0.05, and is listed as being in the HZ. This shouldn't, however, be the case.

Page 43 of the WBH defines HZCO Deviation as Orbit# - HZCO, naturally enough. But it then notes the following:

If either the HZCO or the Orbit# of the world lies below Orbit#1, the calculation becomes more complicated. The same basic subtraction occurs but the result is modified by dividing by the smaller of the HZCO or the worlds’ Orbit number and will result in a greater effective deviation.

And provides the following formula: Effective HZCO Deviation = (Orbit# - HZCO)/Smaller of Orbit# or HZCO.

In the system generated by the above seed, the HZCO is 0.13, so using the above formula we find that the Effective HZCO should be: (0.05 - 0.13)/0.05 = -1.6, which is smaller than -1 and therefore inside the inner edge of the HZ.

Using another system as example, that generated via continuation method by seed 000, 0 Gas Giants, 0 Belts, 12 Terrestrials; the HZCO for this one is 0.04, the outermost planet has Orbit#0.14. Using the formula, we find: (0.14 - 0.04)/0.04 = 2.5, most definitely outside the habitable zone, yet listed as HZ.

I think the 'fix' for this one would be adding an IF logic block to the HZCO Deviation calculation that is triggered whenever either the object's orbit or HZCO is < 1, and then using the smaller of the two values as the dividend for the alternate formula.

 

[coolAlias]

Aw man... I hate to be giving you work, but I think I might've found another bug, and this one will probably not be a trivial fix...

Using system seed 020201 as an example, the innermost planet has Orbit#0.05, and is listed as being in the HZ. This shouldn't, however, be the case.

Page 43 of the WBH defines HZCO Deviation as Orbit# - HZCO, naturally enough. But it then notes the following:

And provides the following formula: Effective HZCO Deviation = (Orbit# - HZCO)/Smaller of Orbit# or HZCO.

In the system generated by the above seed, the HZCO is 0.13, so using the above formula we find that the Effective HZCO should be: (0.05 - 0.13)/0.05 = -1.6, which is smaller than -1 and therefore inside the inner edge of the HZ.

Using another system as example, that generated via continuation method by seed 000, 0 Gas Giants, 0 Belts, 12 Terrestrials; the HZCO for this one is 0.04, the outermost planet has Orbit#0.14. Using the formula, we find: (0.14 - 0.04)/0.04 = 2.5, most definitely outside the habitable zone, yet listed as HZ.

I think the 'fix' for this one would be adding an IF logic block to the HZCO Deviation calculation that is triggered whenever either the object's orbit or HZCO is < 1, and then using the smaller of the two values as the dividend for the alternate formula.

You might be right, but I'll be honest, I took a brief look and seem to have some notes about various things I tried that didn't work out too well for extremely compact systems like these.

In other words, this is going to require a lot more brain power than I have available at the moment. No promises on a fix, but I do appreciate you for checking my math.

 

[FreeTrav]

Alright, fixed it. But also, I don't think the issue is what I think you thought it was, or perhaps what you thought it was isn't what you think.

If you see a Tidal Lock on a planet profile, it can be to either a moon or to the planet's host star(s).

If it is locked to its star(s), then the Solar Period and Solar Days / Year will show as '-' since they are undefined, whereas if it is locked to one of its moons, all of its rotational periods should equal that of the moon it is locked to (or those values * 1.5 in the case of a 3:2 lock).

Actually, if a world is locked to its primary (the star), then the solar day and the tropical year are both identical, and there is one solar day per tropical year. Using a hypothetical tide-locked Earth as an example, the solar day would be ((365*24)+5) hours, 48 minutes, 46 seconds - and there would be ONE solar day per tropical year.