UWP Changes

[far-trader]

Not really sure where else to propose this, maybe MTU ideas, but anyway this seems the one place it might have a chance at making a difference. Not that it's likely to gain any acceptance I guess. Feel free to add other UWP clarification/change ideas here too.

Mine has come about in discussion of the jump limit and world mass, gravity and such.

Would it make sense to rename the Size code as Mass code maybe? It would relate to Size code for worlds with standard (Earth) density only. So for example a Mass code 8 world could be Earth diameter and density, or it could be smaller and denser. In both cases the surface gravity would be the same as would the jump points based on gravity and distance.

Rather than limit the referee to a certain size just explain that the Mass code does not define the diameter of the world, only it's mass and hence the local gravity.

One nice benefit about this approach, it gets rid of the last vestige of imperial measure in the UWP

Additionally, and more importantly, it will relate jump limits to gravity which will make a lot of people happy. That could be done with tables as suggested elsewhere or simply keep the old 100d and 10d but redefine them as perhaps 100 or 10 times the Mass code times 1000km (or more).

 

[RainOfSteel]

far-trader,

What would the Mass codes turn out as?
</font>

• B = 1.1 Earth Mass</font>
• A = 1 Earth Mass</font>
• 9 = .9 Earth Mass</font>
• etc.</font>

It would also list Radius (in kilometers), because we always want to know how big the planet is.
</font>

• A = 8,000 km radius</font>
• 9 = 7,200 km radius</font>
• 8 = 6,400 km radius</font>
• 7 = 5,600 km radius</font>
• 6 = 4,800 km radius</font>
• 5 = 4,000 km radius</font>
• 4 = 3,200 km radius</font>
• 3 = 2,400 km radius</font>
• 2 = 1,600 km radius</font>
• 1 = 800 km radius</font>
• etc.</font>

That would make Earth-size worlds at Radius (or Size, to keep naming compatibility) at UWP Code 5.

 

[Fritz_Brown]

Gravity (hence, mass) has always been something I felt missing from the original UWP. Which way would be less painful, though - to label mass, and figure out G, or label G and figure out mass? I think it would depend on how often your characters are running for the jump limit, vs how often they are slogging their way across a planet surface.

 

[Malenfant]

You'd need a complicated system to disallow certain Radius and Mass combinations (because you're not going to get a 1.1 earth mass world with a radius of 800 km, for example).

I think the current system works fine (though maybe replace Diameter with Radius). What you really need I think is a Density code to go with the Radius, and let the user calculate the mass, volume and gravity individually from that.

 

[Fritz_Brown]

Ahh, yes, Malenfant, that would work well. If you can relate the codes (easily) in a table (for non-?? what are world-builders called?), that would be great, too.
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">
Density 1 2 3 4
Radius
1 .7/250 .8/300 .9/350 .9/375
2 .6/250 .7/300 .8/350 .85/375
3 ..........</pre>[/QUOTE]

 

[robject]

I'd like to see radius (in metric) also.

 

[far-trader]

Originally posted by RainOfSteel:
What would the Mass codes turn out as?

Well my idea was to keep it simple, if possible. This was to be mostly just a name change on the face of it. Perhaps it would be clearer presented as the full step in the UWP generation form:

Planetary Mass (2d-2): The digit representing planetary mass expressed in Standards. For typical densities this also gives the appoximate radius in 1000km increments and allows the suface gravity to be calculated (listed in Gs).

</font>

• 0 = No planet body - 0.000 Standards - 0.000Gs</font>
• ...</font>
• 4 = 4,000km radius - 0.625 Standards - 0.625Gs</font>
• ...</font>
• 8 = 8,000km radius - 1.250 Standards - 1.250Gs</font>
• ...</font>

It's not quite as pretty as I had originally thought, and I can't work out the intermediates right now. I just used the ones from the old tables that work out to even 1,000kms to show the relation I'm thinking of. The new Mass 4 in the table above is the old Size 5 and the new Mass 8 is the old Size A. This puts Earth at about a Mass 6 (6.4 actually) so we might want a refining digit like Pop. It also puts Earth Mass more in the average range. It also gives us more heavy G worlds for all those buff Heavy G trained troops and such

I'm really not sure now that I see it that it makes more sense or is full of problems. It still seems more playable in a lot of ways. The radius is easily derived from the UWP, which is what you want most of the time for the size of the world and the jump ranges. The gravity could be found from a table of the main Mass points and simple interpolation for the refining digit.

As for density this would be for the typical density of planetary formation (if such a beast exists) and a simple low/average/high (a simple average d6 roll: 1 = low 2-5 = average 6 = high could be used if more detail is desired. With low density moving the gravity down one Mass rating and a high density moving the gravity up one Mass rating, but the planet would still have the same radius. I think this would address Mal's worry of tiny moons with 2 surface Gs and hollow super planets with 0.2 surface Gs without needing a complicated system.

All this is just a thought experiment of course. Unlikely that it'll ever see use outside of a few mtu even if the kinks get hammered out.

 

[robject]

Borrowing the radius list: as long as it's really a new replacement field, then how about:

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Size Code Radius Diameter Notes/Old Size Code
1 1000 km 1250 mi 1
2 2000 km 2500 mi 2
3 3000 km 3750 mi 3-4
4 4000 km 5000 mi 5
5 5000 km 6250 mi 6
6 6000 km 7500 mi 7
7 7000 km 8750 mi 8-9
8 8000 km 10000 mi A
9 12000 km 15000 mi
A 16000 km 20000 mi Panthalassic
B 25000 km 31250 mi ~Neptune
C 50000 km 62500 mi ~Saturn
D 75000 km 125000 mi ~Jupiter
E 100000 km 250000 mi
F 125000 km 625000 mi</pre>[/QUOTE]

 

[robject]

Thread Hijack

Anyone interested in fixing UWP data? Marc's looking to have canon data worked over a bit, and is looking for a few good people.

That's all he's said, really, but if you really want to have a shot at canon reform, I have some suggestions. My advice is free, which means it's not worth anything, but anyway...

Also: please forgive my tone below. Yes, it's absurd to ask forgiveness for a tone I'm about to assume, but I don't know how best to explain what I mean about being a steward of something that's not owned by you, 'cause I think that's sort of what it's like when doing official reform of canon data. I could be very wrong here, but I think I'm right. Still, these are only my opinions. I tend to be wrong more often than not, but still...


1. I think you first have to be willing to work within Marc's preferences. There may be data that he won't want to change. If you accept this graciously, it's more likely that some suggestions will be helpful. In other words, it's as much about attitude as a willingness to help.

2. This is a labor of love, not a contract to work. The reason you want to do it is because you want to see the data fixed. Any recognition for your contributions is gravy, not payment. Everyone else, don't bother. In other words, your expectations matter.

3. I reckon if you have a chip on your shoulder, don't bother. This is probably just a restatement of #1 and #2.


Like I said, this may sound a little harsh, but I ask myself, "who would I want on a team?", and the answer seems to be "no lu raanku*".


* Vilani epithet: contentious or chaotic person.

 

[Gruffty]

I'm up for it

 

[Flynn]

robject,

I'd be interested in joining in on this UWP fix. I have already written a few Java apps to clean up data for my own personal use. I'd love to see if they could be modified to meet MWM's needs.

With Regards,
Flynn

 

[jfetters]

robject,

Before deciding one way or another - how much UWP data are we talking about here? The amount of time required can seriously affect my decision to participate.

Hell, this is Traveller, so I really don't care about getting paid.

But my time is valuable, and I don't want to participate and delivering half-assed results.

 

[robject]

Jim got the sixty-four dollar question.

I think it's all open season. I assumed (there's that word again) that he'll take a world here, a world there. But then again I don't know.

In fact, it could range from changing one star in one system to vast swaths of Sunbane data reform.

There are possibilities for programmatic reform. For example, we can show how stellar type distributions are *different* between sectors: there's a problem to justify and fix. Then, we can show where incorrect UWP generation was used for a sector, and propose fixes for that.

In more delicate areas, such as planetary data for the Spinward Marches, I suspect changes will be more careful.


Here's an issue. Personally, I'd want to change the primary star around 567-908. How would I go about suggesting the change? And would Marc really want to bother with adjudicating every change? He's got the master list.

But from Traveller5.com I know he's been interested in fixes and changes, at least to some degree. I'm just thinking it's worth trying to get the ball rolling.

Addendum. The 'volunteer' nature of the effort cuts both ways. We've got complete freedom to do as little as we are able. In this respect, I suspect we'd want to use COTI forums as workspaces.

 

[robject]

OKAY. Let me start with one world at a time, since it's pretty simple to devise a format for suggesting changes at that level.

Example formats to submit a change request for a single UWP:

[Preference] Change the star at 508-453 into an A5.

Justification: Make a good case for it here.

Expect only a couple of personal preferences each to get in to canon.

[Modernization] I think modern astronomy calls for a plain old 'D' versus M3 D or whatever.

Justification: Make a good case for it here.

[Canon Reconciliation] Broadly, this canon source says that this system is an A5 V, and its in the lists as and M3D.

Justification: Cite references and arguments pro and con here.

[Canon Support] There's a need for a homeworld in Lishun for the Sky Raiders. Which one is it? I suggest 0405, but we'd have to change the star type to XYZ and the UWP to SSAHPGL-T.

Justification: Cite references and make your case here.

 

[robject]

[Canon Reconciliation] (1031 Spinward Marches) Change the primary for 567-908 from M9 V to F5 IV.

Justification: This Mars-sized world has an orbital period of 42 years in all canon references. This period puts that world far outside the habitable zone for any main sequence star (see LBB 6). A highly energetic, fairly large star (like an F subgiant) is needed to get a period like that into the habitable zone.

 

[Flynn]

I'd suggest at least some general clean-up, in the form of the following:

* Worlds with Pop 0 get a Class X Starport, a Population Multiplier of 0, Gov code of 0, Law Level of 0 and TL of 0 (aka Xxxx000-0), making the world Barren.

Alternatively, to preserve the Starport code, each such world should receive a Population of 1d3+1 and then generate a Government, Law Level and TL as is appropriate.

* Worlds with a Population code greater than zero should have a Population Multiplier greater than zero in the PBG section.

* Worlds with a Class A starport should have a minimum Population of 4 and a minimum TL of 9.

* Worlds with a Class B starport should have a minimum Population of 3 and a minimum TL of 6.

* All worlds, even Imperial ones, should use Marc's minimum TLs by Atmosphere code. (See MWM's computer program code in Challenge 26 for details.)

* All worlds with a Size code of 0 should have a minimum Planetoid Belt value of 1 in the PBG section.

These are simple internally-consistent things that I think would solidify any set of sector data.

Hope that helps,
Flynn

 

[robject]

Flynn,

Excellent "Canon Reconciliation" points. Without reservation, (except for a slight change) I agree on all except the last one.

In your first point, I'd change 'X' to 'E'. Apparently, an X is actually an interdiction mark. But your point stands nonetheless.

And the last point is a good one, but I have a reservation. I suppose it is possible that a "lone" planetoid can be found in an orbit.

Thanks!

Rob

 

[daryen]

I can do the Domain of Deneb. (Actually, I have done the base for 1112.)

However, the scope of changes do need to be agreed to beforehand. I would hate to see people put in a lot of effort that isn't what is wanted.

robject,

On the issue of 567-908, I would strongly recommend against a non-V star of any type. Non-V stars (and V stars of type O, B, and A) just don't last long enough for life to have a chance to develop.

On a related note, one change I want to see done is that all type D stars that have worlds with type 2-9 atmospheres be changed to V stars. The presence of a type D star in a system pretty much precludes the possibility of a habitable planet unless it is in a really, really, really far orbit.

 

[Flynn]

robject,

I've got an app that does the above clean-up work on a standard *.sec file. Just let me know if you'd like me to run any files through it, as it doesn't take much effort at all. (And I can make the suggested changes you listed above, if that's deemed more appropriate by MWM or his duly appointed representative.

)

In Service,
Flynn

 

[robject]

Hey Flynn, I do, too, in fact. We'll probably want to run every friggin' sector through those babies, and compare them to each other for sanity. And while we're at it, we'll probably also want to include Mike's filter ( D -> V ).

And, Mike, I understand about the short lifespans of spent stars, but there's no way a main sequence star can support life on a world whose period is 42 years (figger 20+ AUs).

...unless the world orbits the companion, whose period happens to be 42 years around the primary. If so, then can the companion be perhaps a K1?

In related news, check out the images I made of the competing Core sector data -- one from the old archives, and one from T4. Note that most worlds are in the same place (good thing), except for the first subsector: T4 placed some extra worlds, which I'm all for ditching.

http://eaglestone.pocketempires.com/survey/core.html