• Welcome to the new COTI server. We've moved the Citizens to a new server. Please let us know in the COTI Website issue forum if you find any problems.
  • We, the systems administration staff, apologize for this unexpected outage of the boards. We have resolved the root cause of the problem and there should be no further disruptions.

System Generation Problem?

Given that all involved now acknowledge there's a problem with system generation, I don't really understand the resistance to proposing an errata variation. Is it pure traditionalism?

It's far more that any efforts to fix it invariably result in demands to make it match current science paradigms, which goes beyond errata into redesign.

The first real revision was T20... and T20, extended system generation didn't get much testing. It does use some more realistic numbers for stars, but they're still broken.

The expanded generation is little used; most people never bother. MGT doesn't have one at all, and GT uses it's own system in (IIUC) First In.

Doing it right involves redoing it on a major scale.
 
It's far more that any efforts to fix it invariably result in demands to make it match current science paradigms, which goes beyond errata into redesign.

The first real revision was T20... and T20, extended system generation didn't get much testing. It does use some more realistic numbers for stars, but they're still broken.

The expanded generation is little used; most people never bother. MGT doesn't have one at all, and GT uses it's own system in (IIUC) First In.

Doing it right involves redoing it on a major scale.

We can simply fix the current system just by re-ordering the process and including mandatory minimum values where appropriate. Nobody is saying we need to include the latest in astrophysics.

I never used the system generation before, but then I encountered H&E2, and that inspired a friend and I to start writing our own version, and I've come to discover that whoever wrote H&E had to fudge things, and so have we. I would be happy to post our solution as at least one example of a fix within the existing framework.
 
Given that all involved now acknowledge there's a problem with system generation, I don't really understand the resistance to proposing an errata variation. Is it pure traditionalism?
We can simply fix the current system just by re-ordering the process and including mandatory minimum values where appropriate. Nobody is saying we need to include the latest in astrophysics.
I don't see any resistance.

The issue is, anything we do is just "whatever we did", our personal whatever, which may well not be agreeable to anyone else.

I guess if I am going to put forth the effort to program something, I want the illusionary belief available that what I finish may be acceptable to others. The only way to get widespread acceptability is to get official errata, not fan errata. Does this make me a bit vain? Sue me.

As for wanting a corrected process to cover the latest in astrophysical knowledge... um, well, I sort of do want that. I realize I'm probably not going to get it, but it's still there.



I never used the system generation before, but then I encountered H&E2, and that inspired a friend and I to start writing our own version, and I've come to discover that whoever wrote H&E had to fudge things, and so have we. I would be happy to post our solution as at least one example of a fix within the existing framework.
One of the last topics discussed during the H&E2 development beta was regarding issues with the solar system generation rules, in particular, orbital slots and placement. We sort of got around to the idea that it would have to be resolved using whatever interpretation was found to be acceptable. At that point, most of us thought that anything was acceptable, as long as we got completed software. The author pointed out general concerns regarding the how well the software matched actual rules; whether or not he could claim it followed X rules or not.

Then, life interfered with the author and he had to cease development.

-----------------

If you complete writing a solar system generator that can accept mainworld UWP data and spit out the rest of the objects UWP data for the solar system, and it follows at least a goodly majority of the rules, please consider making it public. I will be happy to use it. Woo hoo!
 
Last edited:
I had a go at system generation software using javascript - largely as an exercise in classes and objects in javascript. (I was fully aware that H&E existed and liked using it, it's just that Traveller is such a great exercise for learning any given computer language).

I was focussed on acceptable output for gaming purposes. With this in mind, I wanted something that could produce all of the tedious details for me (all those planets and sattelites with YS00000-0 etc!) and lay out each planet as an object with properties that could be calculated and filled in as I extended the code. I got as far as calculating temperature in the WBH for each planet. I lost the code when my laptop was stolen, but I'm not too fussed - H&E really does a good job for what I'm after, and the exercise in building the code has served its purpose.

In importing UWP's from Canon (yes, I'm rather fond of the Spinward Marches), I applied a "common-sense" (yes, yes I hear what you're saying RainOfSteel about that phrase) along the lines of what Aramis said, but using a captured orbit as a simple way of implementing a main-world placement rule.

The steps I used were: (i) when rolling orbits, total available orbits (after calculating for any companion star) had to be at least Planetoids plus Gas Giants plus one. (ii) go back and re-roll orbits if this wasn't the case; (iii) after placing Empty Orbits, GG's and Planetoids, place the mainworld in the habitable zone as a satellite of a GG if needs be; (iv) if there wasn't an available orbit for the main world, determine a captured orbit - if atmosphere is 4-9, "cheat" by calculating a world temperature of 15 degrees C (using WBH) and then determine AU distance and create a captured orbit.

I reckon write the software however you think it makes sense, but clearly publish for the end-user the rules you are using. Then write the software with the ability to add different options for accounting for the anomalies you have discovered. In this way, you make it extendable, with the ability to add suggestions. Then you present the various options to the user before they hit the "generate" button.

My reading of the rules, FWIW, is that they work very well for creating extended systems from scratch without a mainworld that you have to import. But because of all of our great interest in using published materials (it's understandable, we're all busy) we get these anomalies. Most of our systems, though, would end up as class M stars with cold worlds if they have any at all. If entire sectors were generated this way, my prediction would be that the Traveller Universe would have a very different feel about it - a lot more hostile worlds and more imagination needed as to how a TL5 world with millions of inhabitants can exist when the atmosphere is a vacuum. But there would be clusters of garden variety worlds where the Gas Giant is in the habitable zone.

In summary, because we want an interesting main world to visit for adventures, the original rules are biased towards Earth-like worlds. This is a standard science-fiction trope. For example, it seems to me that in Star Trek the away-teams are always beaming down without the need for breathing apparatus. Hence the way the Book 3 mainworld generation rules work. It's about interesting worlds on which to create an adventure. You then fudge the rest of the star system to account for wider adventures in a particular system.

I know that this creates headaches for a programmer. You want a clear end-to-end process that's easy to code. But it's not an insurmountable challenge: if you add to or change the design sequence, just be open about what you're doing and document it along the way (for the end-user, not just in the code comments!), and offer different options to the user.

Lastly, remember that the output isn't just for it's own sake. It has to be usable by a Referee (generally you!) who is creating a setting for the players to explore. With that goal in mind, remember that any given Referee is going to take what the computer spits out and change all of it. You're just removing the drudge work.
 
I reckon write the software however you think it makes sense, but clearly publish for the end-user the rules you are using. Then write the software with the ability to add different options for accounting for the anomalies you have discovered. In this way, you make it extendable, with the ability to add suggestions. Then you present the various options to the user before they hit the "generate" button.

At present, there are Many different systems for generating detailed systems:
  • CT Bk6
  • MT
  • TNE
  • T4
  • T20
  • GT FI
  • G Space (not official, but recommended on SJG's forums often enough)
  • T5

Note the absence of MGT from the above list of official methods....

And a few homebrews
  • Malenfant's homebrew (adjusted for his personal views of realism - I've not read it, so I can't be more specific)
  • my homebrew (applying the principles of Bk6 to MGT, but deriving stellar frequencies from those in one of the current major star catalogues)
  • Rob Prior's method - buried in his excellent but no-longer-available Metator
  • Hemidan aka PLST's method (buried in his software)

And that's excluding those who imported Space Opera, Star Hero, Space Master and/or 2300 system generation.

My reading of the rules, FWIW, is that they work very well for creating extended systems from scratch without a mainworld that you have to import. But because of all of our great interest in using published materials (it's understandable, we're all busy) we get these anomalies. Most of our systems, though, would end up as class M stars with cold worlds if they have any at all. If entire sectors were generated this way, my prediction would be that the Traveller Universe would have a very different feel about it - a lot more hostile worlds and more imagination needed as to how a TL5 world with millions of inhabitants can exist when the atmosphere is a vacuum. But there would be clusters of garden variety worlds where the Gas Giant is in the habitable zone.

Having generated a subsector that way, it's a LOT of work... and DOES produce a very different feel.
 
@aramis: yes, point taken on how many different rule systems there are. What I meant was that if they are doing one rule system (e.g. MT or TNE), then publish whatever common-sense fudges they are using to let results make sense (e.g. impose a minimum number of orbits of GG + PB + one). But do this in a way that lets the user choose between what fudges to use.

On the other point about generating systems from scratch without generating a mainworld first, I would say a programmed solution would be perfect - saves all that work while being a clear process. In fact, without the need to import details from the OTU, I would say it would be much easier to program. Hmmmm. Might go back and do that myself. In other news, I was browsing through my computer folders of Traveller stuff ... and found my world generating code! It's in javascript - is anyone interested in having a look?
 
In other news, I was browsing through my computer folders of Traveller stuff ... and found my world generating code! It's in javascript - is anyone interested in having a look?

Yes. I'm thinking of adapting my Elestrial Concordat mechanics (an expanded for MGT) to a web page.... Or an automated PDF.
 
Yes. I'm thinking of adapting my Elestrial Concordat mechanics (an expanded for MGT) to a web page.... Or an automated PDF.

This would be great. Your system is excellent.
I may be tempted to try coding it in Python - but I first have to learn just what the heck I'm doing with it first! (absolute beginner at programming...)
 
This would be great. Your system is excellent.
I may be tempted to try coding it in Python - but I first have to learn just what the heck I'm doing with it first! (absolute beginner at programming...)

Only reasons not to use Python are that it's not widely used outside the Linux community, and it's not part of the PDF standard. And thanks for the complement. The system has a major flaw in that it's fit to the catalog data I had available, and that catalog has a bright star selection bias.
 
My code is bug-ridden! Sorry, will take a couple of days in spare time - I remember the particular back-up copy that this is: I just want to get it running before posting it.

It uses the Windows HTML Application engine (i.e. *.hta) as a front end, with Javascript and XML as the engine. I chose this because it allows you to use XML on local files without coming foul over the security related refusal to load XML cross-servers. A much better solution would be to use PHP, but I'm waiting on a replacement laptop to set up my developer's machine again.

It's very basic, with inputs hard-coded just to get some examples running.
 
Well, Chris, the conditions under which one has to have to wind up with unplaceable worlds are few... and could have been ruled.

Here's the "common sense" I apply:
If (GG+PB) > available orbits in system and no companion or only far companion, increase available orbits to (GG+PB), put a GG in the hab zone, and put the mainworld orbiting the GG.

If (GG+PB) > available orbits in system with non-far companion (includding both primary and companion), increase orbit # of companion by 1 and check again.

If (GG+PB+EO) = available orbits, reduce EO by 1. (EO isn't recorded - it only reduces available slots if there are slots that won't be filled with GG's and PB's, and isn't on the mainworld entries in published data.)

If all available orbits full before checking for captured, the captured ones must be ones already generated - the mainworld and GG's - as a belt being captured is a little too out there for most people's verisimilitude.
But note: Bk6 was NOT written for automation. Nor was Bk5. Both were written for people to do it by hand.

It actually seems to me that this small set of rules could be brought into the errata... if Aramis is willing?
 
There actually needs to be a few more changes than that, but it's pretty close to what we're using in our program, and probably pretty close to what H&E does too.
 
There actually needs to be a few more changes than that, but it's pretty close to what we're using in our program, and probably pretty close to what H&E does too.

The explicit instruction that a roll below the minimum on a given table is the minimum and above the maximum is the maximum needs to be added, for people like Malenfant. (He complained of it on another BBS this week.)

It was common praxis to understand that in the wargaming community, but many modern RPGers don't have any wargaming experience and need it spelled out for them.
 
There are still a few more necessary tweaks. For instance, one of the M5+ stars has no habitable zone (don't recall which class at the instance and no book available right this second), so obviously you can't have it with a habitable type world.

There's a couple of little things like that we noticed while writing the program. I'll post them and the solutions we ended up using when I have more time a little later.

Also, while our solutions are very similar, they aren't exactly the same. For instance, I don't know why you are reducing the empty orbits by one if GG+PB+EO = AO. Seems to me that GG+PB+EO = minimum orbits in just about every situation except for those where the main world can't be placed in a GG orbit (for instance, if no GG ends up generated in a H zone orbit, or if there is no GG), in which case Min Orbits would equal GG+PB+EO+1.
 
Last edited:
The explicit instruction that a roll below the minimum on a given table is the minimum and above the maximum is the maximum needs to be added, for people like Malenfant. (He complained of it on another BBS this week.)

It was common praxis to understand that in the wargaming community, but many modern RPGers don't have any wargaming experience and need it spelled out for them.

Actually, this specific instruction needs to be where it impacts the entire ruleset. And CT as well.
 
There are still a few more necessary tweaks. For instance, one of the M5+ stars has no habitable zone (don't recall which class at the instance and no book available right this second), so obviously you can't have it with a habitable type world.

There's a couple of little things like that we noticed while writing the program. I'll post them and the solutions we ended up using when I have more time a little later.

Also, while our solutions are very similar, they aren't exactly the same. For instance, I don't know why you are reducing the empty orbits by one if GG+PB+EO = AO. Seems to me that GG+PB+EO = minimum orbits in just about every situation except for those where the main world can't be placed in a GG orbit (for instance, if no GG ends up generated in a H zone orbit, or if there is no GG), in which case Min Orbits would equal GG+PB+EO+1.

OK, let's see that post.
 
As promised, here's my less-buggy code: Link

It's not well documented, I haven't implemented the ideal documentation and the code isn't really commented. Many apologies, it's done with HTA files using javascript that make extensive use of the Windows File System Object to deal with text data files - so sorry, it won't work on Linux or Apple systems.

But you're welcome to have a look and use anything you see.
 
Is there any interest in collating all the various systems into one and writing it up for Mongoose?
I'd be happy to do the grunt work of amalgamating the various systems if that's any incentive?
 
Hey Christopher, I just wanted to say after all this time that you've made a generous offer, but I for one will be putting my efforts into T5 which has a good balance for system generation (reducing the 'map every rock' style in MegaTraveller / CT Book 6).

I know it can feel terrible when you leave an offer 'hanging out there' on a bulletin board, so going back through my e-mails thought I'd reply.
 
Back
Top