World Builder's Handbook Feedback

Yeah, I think you got me there. Looking at earlier drafts, Compatibility was originally:
2D+5 – Biocomplexity Rating + DMs
But that didn't end up panning out after doing a sector's worth of worlds, so I changed it to what it is.
But somehow the example has a probably unpreserved interim fix and not the final fix. I suppose in any updated printing the example should have a roll of 10 and no DM+3 out of left field - that way it would cause the least amount of disruption to the text.
 
Yeah, I think you got me there. Looking at earlier drafts, Compatibility was originally:
2D+5 – Biocomplexity Rating + DMs
But that didn't end up panning out after doing a sector's worth of worlds, so I changed it to what it is.
But somehow the example has a probably unpreserved interim fix and not the final fix. I suppose in any updated printing the example should have a roll of 10 and no DM+3 out of left field - that way it would cause the least amount of disruption to the text.
No worries. Having had to self-edit my first novel, I understand how tedious it can be, especially with what amounts to a highly-technical manuscript. I'm glad the formula is what's correct. :)

And, I think the final solution to the formula works well, including the inverse probability of high compatibility in a highly-complex environment.
 
No worries. Having had to self-edit my first novel, I understand how tedious it can be,
The problem with self-editing is that you see what you thought you meant. The problem with another person editing is they see what your wrote but not what you meant - but at least the sentence make sense on the page.

With the advantage of an actual editor, I've found severely diminished returns after the third edit - the one I do with a printed document and a red pen. After that, I introduce as many errors as I correct and the writing becomes ever more... blah. But in this case the problem was a sloppy revision on my part, where I didn't pull the thread all the way on the the effects of a change - made after the first submission (the final document was called "...-Final3" because over a course of two months I kept finding problems with the the result of what I actually wrote and intend to write, but which was not resulting in the expected outcomes). And then came seven forum pages worth of feedback corrections.

Oh well. If you're never wrong you never learn...
 
Trying to create a JavaScript implementation of the rules (because i apparently hate myself), got a question.
1706635768496.png
Is there a good rule of thumb for calculating these composite components? If a given star has a companion then they should be included as a composite, yeah, but on the higher level - why AB and ABC, not BC? With a four-star system A, B, C, D - would it be A, AB, ABC, ABCD? How should I express that in code?
 
Trying to create a JavaScript implementation of the rules (because i apparently hate myself), got a question.
View attachment 1552
Is there a good rule of thumb for calculating these composite components? If a given star has a companion then they should be included as a composite, yeah, but on the higher level - why AB and ABC, not BC? With a four-star system A, B, C, D - would it be A, AB, ABC, ABCD? How should I express that in code?
Could be worse than JavaScript - I did it in Excel and lost both hair and sanity during the process. I expect you'll find the automating 'exclusion zones' from multiple stars to be a bit of a migraine-inducing operation, but I'm sure actual coding will give you a leg up from Excel on assigning various planet types (Empty , Gas Giant, Terrestrial, Planetoid belts) to 'random' Orbits.

The best I can explain it is that the compromise between a 'true' barycentric system and a, well frankly Copernican or Keplerian system is the 'Primary Star'-centric view of the system in that all the capital lettered stars orbit the Primary star with each having at most one 'companion', so something like a 'BC' would be a Bab (B) sort of deal - a set of circles centered on the 'B' orbit but not crossing and A-centric orbits (AB, C and D would all be circling A). If that makes any sense - can't do a diagram right now, but it looks 'clear' in my head. Ache. So in a four-star system, where you had a Close, Near and Far star (hey, I didn't invent those terms, I took them from T5) then it would be as you said: A, AB, ABC, ABCD.
 
Could be worse than JavaScript - I did it in Excel and lost both hair and sanity during the process. I expect you'll find the automating 'exclusion zones' from multiple stars to be a bit of a migraine-inducing operation, but I'm sure actual coding will give you a leg up from Excel on assigning various planet types (Empty , Gas Giant, Terrestrial, Planetoid belts) to 'random' Orbits.

The best I can explain it is that the compromise between a 'true' barycentric system and a, well frankly Copernican or Keplerian system is the 'Primary Star'-centric view of the system in that all the capital lettered stars orbit the Primary star with each having at most one 'companion', so something like a 'BC' would be a Bab (B) sort of deal - a set of circles centered on the 'B' orbit but not crossing and A-centric orbits (AB, C and D would all be circling A). If that makes any sense - can't do a diagram right now, but it looks 'clear' in my head. Ache. So in a four-star system, where you had a Close, Near and Far star (hey, I didn't invent those terms, I took them from T5) then it would be as you said: A, AB, ABC, ABCD.
So, just to make sure I'm on the right track, it'd look something like this?
["A", "B"] -> ["A", "B", "AB"]
["A", "B", "C"] -> ["A", "B", "AB", "C", "ABC"]
["A", "B", "C", "D"] -> ["A", "B", "AB", "C", "ABC", "D", "ABCD"]
 
So, just to make sure I'm on the right track, it'd look something like this?
["A", "B"] -> ["A", "B", "AB"]
["A", "B", "AB", "C"] -> ["A", "B", "AB", "C", "ABC"]
["A", "B", "C", "D"] -> ["A", "B", "AB", "C", "ABC", "D", "ABCD"]

Pretty much. I changed the one in red... AB should precede C, but it and any other multi-letter combinations may not be viable in some (most) systems. That's where it starts to get annoying though: there may only be a handful of quad plus star systems in a sector, but they can end up being hard to compute by hand or by code.
 
(Cheers to @GabrielGABFonseca for catching this one.)

https://cdn.discordapp.com/attachments/997350214476243054/1202405086949548143/image.png?ex=65cd5600&is=65bae100&hm=55413b0fb166097dcaa4d42d250185a775f973ebe1280e0fadfd1ebf5fb8741d&
https://cdn.discordapp.com/attachments/997350214476243054/1202405087192948857/image.png?ex=65cd5600&is=65bae100&hm=959739b739fe9d28af3124382b4d0881a3304c9c474e1446416e004f88665bb3&

By the way, I'm trying to implement Hill Spheres - figured it'd be easier to work with on a maths machine - and noticed this one; M here is just m1, not m1 + m2. Not a big deal on planets and moons, is a big deal for stars.
 
(Cheers to @GabrielGABFonseca for catching this one.)

https://cdn.discordapp.com/attachments/997350214476243054/1202405086949548143/image.png?ex=65cd5600&is=65bae100&hm=55413b0fb166097dcaa4d42d250185a775f973ebe1280e0fadfd1ebf5fb8741d&
https://cdn.discordapp.com/attachments/997350214476243054/1202405087192948857/image.png?ex=65cd5600&is=65bae100&hm=959739b739fe9d28af3124382b4d0881a3304c9c474e1446416e004f88665bb3&

By the way, I'm trying to implement Hill Spheres - figured it'd be easier to work with on a maths machine - and noticed this one; M here is just m1, not m1 + m2. Not a big deal on planets and moons, is a big deal for stars.
Yes m1+m2 is a big deal for many stars, and I did start down that road, but then had to go back to Orbits (for backwards compatibility compatibility and math-lighter reasons), for which it is not a big deal, but entirely abstracted away.

The "true" way to do multi-stars would be to build a tree-like hierarchy of stars and account for all the orbital influences in a way that almost looks Ptolemaic in really complex systems. Wheels within wheels... except in 3D - and even that doesn't account for precession - Newtonian or Einsteinian.
 
Right. Though while I've got you - was there any rationale behind giving the composite orbital information the same as the companion?1706748465486.png
 
Right. Though while I've got you - was there any rationale behind giving the composite orbital information the same as the companion?View attachment 1553
Sort of... the pair do orbit each other in the period indicated and it does in a T5-like (Yeah, not sure if if I'm going Ptolemy, Copernicus, or Kepler here) sort of way sort of described the Aab orbit.
 
The physical copy of World Builder's Handbook is erroneously spine coded as Triangle 11 (which has already been taken by Secrets of the Ancients.) It should have been Hex 9.
 
So I just bought the book and read it... and love the detail. I'm sitting down with dice, forms, pencil and calculator working on a system, then I felt the urge to move to spreadsheets, then I couldn't help but wonder, is there going to be any kind of app or online tool that could automate most of the process for people who want the results but not the work, or for those times when you just need a quick believable star system that follows the same rules as your more carefully crafted systems? I searched for an answer but the best I could figure was to take a TravellerWorlds world builder (from the link in travellermap) and start editing all the "Full Star System" details manually to fit what I'm rolling at home. I can imagine an app or online tool, anything from something like the Robots Excel worksheet to something that will generate a lovely diagram of your finished system. Just curious if anything is available or in the works.

I can imagine negative responses from people who prefer to do all the work on paper, or create their own spreadsheets, or follow MOARN to the letter. But I've noticed more and more of my players, who seem to get younger every year, expect more detail, more images, more diagrams, etc, and an online tool could quickly and easily assemble a system, allow Referee customization, keep everything within the guidelines, and then spit out a nice image or diagram.
 
So I just bought the book and read it... and love the detail. I'm sitting down with dice, forms, pencil and calculator working on a system, then I felt the urge to move to spreadsheets, then I couldn't help but wonder, is there going to be any kind of app or online tool that could automate most of the process for people who want the results but not the work, or for those times when you just need a quick believable star system that follows the same rules as your more carefully crafted systems?
I built a testing sector generator in Excel as I was working out the bugs, but.... it can't deal with all the edge cases very well (I capped it at 6 moons per planet or 6 bodies per belt because I was running out of columns) and eats CPU and memory like a... big... badly written app. Not really keen to share it because it requires a lot of knowledge of the guts of the formulas, especially if you want to 'tweak the knobs' (aka, change random values to fixed and then manually adjust parameters).

From my known defects list (some of which will not make a lot of sense in isolation):
StarMaker only creates BD and D (brown and white dwarf) special 'stars' neutron stars, black holes and other anomalies are not supported
Systems are limited to 21 orbits - in practice, this limit is rarely reached, though 26 is theoretically possible
Anomalous orbits may not obey all orbit availability limits
Trojan orbits not linked to other orbits
Only 6 moons generated per world. Any additionally must be created manually and recorded as comments
Some detailed physical characteristics are fixed per system - Taints, land distribution, so their random components will not alter if a new Mainworld selected
The Census tab is one per system, so does not change with different Mainworlds, though DMs may alter some results
Moon Orbits not implemented other than to determine Hill Sphere Moon Limit (HSML) and resultant ring and moon removals and modifications
In Physical tab: Satellite Size and Hydrographics only work if entered in in decimal (not hexadecimal) form (S and H cells will convert)


It would really benefit from being written as an app, and I'm 2-3 decades beyond the time I wrote anything more complex than a macro or simple subroutine (And I learned on FORTRAN 77 and various forms of BASIC). So I'm afraid an app is not going to happen any time soon, though I'm willing to comment or review someone else's effort.

Robots was 'easier' to build because there are no dice rolls at all, and well-defined lists of things you can do. The robot spreadsheet might not be pretty, but it was developed at the same time as the document, so honestly, if something was too complicated for Excel to handle it without contortions, I changed the design process to make it easier. (And that's what I think is probably needed for any update to the Vehicle Handbook, but that's another thread....)
 
Since I picked up the book, I've been using a spreadsheet to handle a limited number of calculations (i.e., those that don't rely heavily on dice rolls), using a Google doc to record each system's information...not sure I'm going to have any space on my Google Drive when I finish system number 237...
 
Question on modifiers for the Habitable Zones Regions chart on p.47 (pdf p.48): What DMs should we set for atmospheres G and H? I have a Size E world (a moon of a gas giant) in the HZCO +3.01 zone that ended up with an atmosphere of H. (I figured the atmospheric pressure at just over 2,000 bar.)

The DMs only account for atmospheres up to F; I noticed in the text in the atmosphere section that you can use F for the code (with a G or H subtype) for a mainworld "gas dwarf," but a DM+2 just doesn't seem enough for a world with such a high atmospheric pressure. My initial thoughts were DM+8 for G and DM+10 for H, but then another part of me says DM+6 should be an absolute cap.

Edit: I mistakenly used the pdf page number, and not the book page number. Corrected for clarity. Thanks to Geir for pointing it out. :)
 
Last edited:
Question on modifiers for the Habitable Zones Regions chart on p.48: What DMs should we set for atmospheres G and H? I have a Size E world (a moon of a gas giant) in the HZCO +3.01 zone that ended up with an atmosphere of H. (I figured the atmospheric pressure at just over 2,000 bar.)

The DMs only account for atmospheres up to F; I noticed in the text in the atmosphere section that you can use F for the code (with a G or H subtype) for a mainworld "gas dwarf," but a DM+2 just doesn't seem enough for a world with such a high atmospheric pressure. My initial thoughts were DM+8 for G and DM+10 for H, but then another part of me says DM+6 should be an absolute cap.
Missed that... sorry. That table is a straight duplicate of the Core book, consistent, but not complete enough. Probably ought to have been more explicit with Atmosphere F DM as well and tie it to the F subcodes on page 93. (I noticed you used the pdf page, not the book page, for your reference, but I'm using book page numbers for consistency).

For simplicity, I would go with DM+6 under the 'absolute cap' theory - but I kind of like your DM+8 and DM+10. By the time you get to what are essentially gas dwarfs, then the surface gets to be a 'squishy' concept. Or the atmosphere just squishes you. You could treat those worlds like gas giants and just use a gas giant albedo (p.110) and potentially a residual heat factor (p.125) to compute the temperature at the one bar level and assume a 'city in the clouds' sort of settlement. Though to be fair, I left the minimum TL for the worlds at 14 (p. 175), so some sort of reinforced structure could survive on the surface.
 
Thanks for the clarification. I went with a DM+8 for G & H atmospheres to reflect that they start at an order of magnitude more oppressive than even extremely dense insidious atmospheres.

I noticed today on p.105, a note on the Tidal Lock Status chart says to reroll an axial tilt of more than 3 degrees as (2D-2)/10 degrees for both 3:2 and 1:1 tidal locks; however, on p.107 in the summary section on the Effects of Tidal Lock, point 3 says to roll 1D on the Axial Tilt Table for 1:1 locks only. (I did a search of the forum, but it doesn't look like this specific thing has been addressed to date.)

So, do we:
1. Ignore the chart note on p.105 for both 3:2 and 1:1 locks, in favor of the rule only for 1:1 locks on p.107,
2. Apply the chart note for 3:2 locks and the p.107 rule for 1:1 locks, or
3. Ignore the rule on p.107 in favor of the chart note on p.105?

And, just in case I haven't said it a dozen times already, the process of creating systems and worlds with this book has been spectacular! Thank you!
 
And, just to pile on, is it a safe assumption (at the very least for the sake of simplicity), that when a terrestrial world and a moon are in a mutual 1:1 tidal lock, the moon's orbital period (and, thus, its rotational period) is changed to be equal to the parent world's rotational period?
 
Back
Top