Sysgen Series: Moon Tidelocks

[Cralis]

Next in the sysgen series I'd like to address moon tidelocks for type-G and type-I planets. For clarification I'm going to use these two terms:

tidelocked moon = a moon that is tidelocked, but is not a twin (ie. it is tidelocked to the planet, but the planet is not tidelocked to the moon).

big moon = a tidelocked moon that is large enough to be a twin.

twin = referring to the big moon as a planet.

1. G and I twins are a little funky in ULTRA. Basically you are never going to see a twin type-G or type-I planet. So what do I propose? gas giant twins are addressed in #2 below, but type-I twins should become type-F. Not mF.

2. Right now the W6.04.2 tidelock table turns all tidelocked moons into type-mT. That is very unrealistic and skips another type of moon you find around gas giants. A tidelocked moon around a type-G should be type-mH. Io. A big moon around a type-G can be type-mT, that makes them more rare and more realistic.

Now to address an issue that was brought up, Marvin's reason for not changing this was that he apparently made them more available in order to balance the exotic life-types table. So be aware that this change will reduce the number of terran-type planets on the exotic life types table. I would propose that we change the table to adjust, but at this time I'm unsure of how much change (effort) that will require.

3. tidelocked moons around type-I will remain type-mF just like regular moons. They do heat up, but not enough to change the type of moon.

Thoughts? Comments?

[Crucis]

Next in the sysgen series I'd like to address moon tidelocks for type-G and type-I planets. For clarification I'm going to use these two terms:

tidelocked moon = a moon that is tidelocked, but is not a twin (ie. it is tidelocked to the planet, but the planet is not tidelocked to the moon).

big moon = a tidelocked moon that is large enough to be a twin.

twin = referring to the big moon as a planet.

1. G and I twins are a little funky in ULTRA. Basically you are never going to see a twin type-G or type-I planet. So what do I propose? gas giant twins are addressed in #2 below, but type-I twins should become type-F. Not mF.

No problem here, though for improved clarity, I'd say "type-I twins should become type-F planets."

2. Right now the W6.04.2 tidelock table turns all tidelocked moons into type-mT. That is very unrealistic and skips another type of moon you find around gas giants. A tidelocked moon around a type-G should be type-mH. Io. A big moon around a type-G can be type-mT, that makes them more rare and more realistic.

Now to address an issue that was brought up, Marvin's reason for not changing this was that he apparently made them more available in order to balance the exotic life-types table. So be aware that this change will reduce the number of terran-type planets on the exotic life types table. I would propose that we change the table to adjust, but at this time I'm unsure of how much change (effort) that will require.

Very interesting idea.

[PracticalM]

I would say changing the values of systems that are currently balanced in the exotic life makes this change more work then the expected benefit.

The extra work to rebalance the exotic life races doesn't seem worth the changes.

[Cralis]

Heh, I would be doing the work on it, so I don't expect anyone else to do it. A lot of people don't care about the exotic race types and it wouldn't even affect them in the interim either. I was more bringing that up as a note to self I guess, I could have left it out.

[Crucis]

Heh, I would be doing the work on it, so I don't expect anyone else to do it. A lot of people don't care about the exotic race types and it wouldn't even affect them in the interim either. I was more bringing that up as a note to self I guess, I could have left it out.

Honestly, this is a big reason that I don't like the Unusual Races rules. If one wants to make some tweak here or there to the sysgen rules for realism reasons or perhaps to add additional variety, the bogeyman of Unusual Races rears its fugly head and screams "You've got to rebalance all of the UR population #'s to account for the changes you made!!!" Argh. It just doesn't seem worth the hassle to me.


I mean, jeeeez...

Thinking about making changes like Matt's suggested mH moons for G planets? Gotta rebalance those UR's!

Think that maybe there should be a possibility of mass 1 "hostile moon"-like planets in the bioshere? Gotta rebalance those UR's!

Or perhaps Ice Giant "twins" should be Type F planets? Gotta rebalance those UR's!

Want to have m1 Type B planets in the Gas zone or m1 Type F planets in the Ice zone? Gotta rebalance those UR's!

Or maybe a Rare rocky zone Gas Giant? Gotta rebalance those UR's!

Argh!


Here's my method for rebalancing UR's.... (hear the sound of a toilet flushing....)

[PracticalM]

Matt,

I actually like the UR and have played around with them. I know that system generation stuff is something you are fond of but I just don't see that this makes enough reason to make all these changes to what amounts to a stable rule set.

It's kinda of interesting having the ability to surprise players with UR races as they head towards T worlds that end up having no population in a heavily defended system.

Having completely alien types fairly well balanced is something that makes Starfire fairly unique.

If you do put the effort into rebalancing them, it wouldn't matter what changes you make to the system. But really I don't even see the need for changes to something fairly stable.

[Cralis]

I think you misunderstand Jeff. ULTRA is set in stone and will not change.

This would be an optional set of rules. Potentially for one of my other projects as well. It wouldn't be for nothing - I am actually going to use it.

[krenshala]

I actually like the UR and have played around with them. I know that system generation stuff is something you are fond of but I just don't see that this makes enough reason to make all these changes to what amounts to a stable rule set.

I haven't used them, primarily because the rules in section Y for them appear ... thrown together. It reads to me like not all the required instructions are there, because the person that worked them up didn't include everything because some of it was obvious (to hir). I like the concept, but just using them appears to be more of a hassle in figuring out how they work then just running with standard "warmlife".

As for the system generation rules, they are not exactly "stable". There are a number of small things that make writing system generation utilities a gods-aweful royal pain the posterior. Tidelocked moons are but one aspect of that.

Personally, I like Matt's idea, but think it should be implemented slightly differently. Essentially, however, the method I came up with is pretty much the same thing, just slightly different in derivation (my system does not limit G worlds to just outside the hab zone, thus G moon types have to be determined based on orbital position of the GG, in combination with the tidelock results).

[Cralis]

You might need to give us some more details, I don't remember anything about your mass 4 rolls that made any difference to the tidelocked moon rules. What did I miss?

[krenshala]

From memory, and the original/current GSF/Ultra rules ...

Twin worlds are the same mass ... unless its a T or G 'parent'. But wait, G worlds can have habitable twins from non-big worlds ... oh wait, but not all the time (depending on G mass and star type). This is something that could really be "fixed" in such a way as to reduce the number of cases/rules needed, while maintaining the current end results.

As for how it interacts with my mass generation tables (masses 1 - 4, where only mass 4 worlds are GGs), I didn't really change anything in my rewrite of section W, but when I was writing the system generation code I made a change in how it picked whether a moon was the same or the "other" mass for twins. I did something else with G-mT twins, as well, but don't remember what it is off hand. Its one of the parts I'm not currently happy with, and really need to recode.