• 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.

UWP Changes

Nope.
You round down in Traveller most of the time ;)

3000km - 3999km = size 3 in the proposed new system.
To be size 4 in the new system you'd need a radius of 4000km minimum.

Mars is therefore size 3 in the proposed new system.

If I understand it correctly.
 
Personally I round towards the nearest size, but yeah, I goofed there - Mars should be size 3 in the new system, not 4
. Either way, it's not and never was 6 ;) .
 
Currently atmosphere is 2d6-7+size. Therefore a moon sized planet (size 2) will have a standard density atmophere 1 time in 12 (rolls of 11 or 12). Under the suggested change a moon sized planet is now size 1, and will have a standard density atmospher only 1 time in 36 (roll of 12).
This is still nonsense of course, but I've just cut by two thirds the possibility that a moon sized rock will have a stnadard density atmosphere. That's not a bad start.

Right now a Mars sized planet has a 10 in 36 chance of having a standard density (or higher) atmosphere. If Mars is now size 3 the odds just got cut to 6 in 36. This is still too high but it's a lot better.

Plus it just makes more sense for the all metric Traveller to not have any hold overs from the Imperial system. By making all the planets 24.3% larger and 92.1% more massive we can do that and reduce, but not eliminate, the number of silly atmospheres.
 
Go for it. Probably could set a limit like ATM can't be greater than SIZ or SIZ+1 or something.

(Hey, you're in Anchorage? You know Wil Hostman?)
 
Rob, you would have to be careful with that limit. After all, in the one solar system that we know with any kind of detail, we have:

Venus: SIZ 7, ATM B (or D?)
Earth: SIZ 8, ATM 6

We also have:

Ganymede: SIZ 3, ATM 0 or 1
Titan: SIZ 3, ATM B (or A)

Another big problem with the SIZ/ATM issue is the fact that the system only has 5 atmospheres, out of 15 that do not have oxygen in them. The system doesn't allow for a both pressure and composition differences within the single code outside of the breathable ones.
 
Well, how about ATM < SIZ*4 or SIZ*3 then?

I'm just throwing out suggestions, here. It just seems easier to cap ATM than to create funky functions.
 
State of Second Survey

Spinward Marches
The sector data for the Marches is being managed by Marc Miller and Mike West.

23 Sectors
These sectors conform both to the AOTI baseline and the T5 UWP generation procedure. Test data resides here: http://eaglestone.pocketempires.com/survey/second/

The data is currently alpha, and subject to change. The biggest changes in the UWP format are:
</font>
  • the base code field is now 2 characters wide</font>
  • the trade codes set has been generalized</font>
  • the file has some XML formatting</font>
</font>
  • Alpha Crucis (Jim)</font>
  • Antares (Jim)</font>
  • Core</font>
  • Corridor</font>
  • Dagudashag</font>
  • Daibei (Jim)</font>
  • Delphi (Jim)</font>
  • Deneb (Daryen) * needs scrubbing</font>
  • Diaspora (Jim)</font>
  • Empty Quarter (Jim)</font>
  • Fornast (Jim)</font>
  • Gushemege</font>
  • Ilelish</font>
  • Lishun</font>
  • Magyar (Jim)</font>
  • Massilia</font>
  • Old Expanses (Jim)</font>
  • Reaver's Deep</font>
  • Reft (Daryen) * needs scrubbing</font>
  • Trojan Reaches (Daryen) * needs scrubbing</font>
  • Verge</font>
  • Vland</font>
  • Zarushagar</font>

These sectors are beyond the reach of the Imperium
</font>
  • Solomani Rim</font>
  • Spica (Gruffty)</font>
  • Ley (QLI)</font>
  • Glimmerdrift (QLI)</font>
  • Gateway (QLI)</font>
  • Crucis Margin (QLI)</font>
 
:cool:

Very cool! Thanks for posting this, robject.

So on the plus side, I like the overall XML meta design. What I would REALLY like to see would be that the XML data structure extend into the data itself, then have a stylesheet for viewing (which is a rehash of another discussion, so I will leave it at that).

EDIT - A couple quick comments:

What are the stellar "tweaks"? (+M, V*, -K, etc)

Also, has the single digit scout/Navy co-location code ("A") gone away? I see a few instances in Antares where it lists NS. It would seem to me to keep the single character code.
 
Thanks for the reply Jim, you brought up a lot of good points.

</font>
  • Stellar data is not regenerated, or if it is, it is regenerated incorrectly or badly.</font>
  • XML will not intrude into the UWP line data. This is a compromise solution between machine and human formats. Note that it is trivial to write translator programs that will transform a sector file into a fullblown XML file, but as experience has shown, the format of XML UWPs has everything to do with your programmatic intentions, and nothing to do with standardization.</font>
  • Base fields are now 2 characters wide.</font>
  • There are no longer "mixed" base codes. A is now NS. B is now NW.</font>
  • There are still two "combined" base codes: W presumes a Scout base, and D presumes a Naval base.</font>
  • Base codes are now general. 'N' means Naval, whether Imperial, Vargr, Zhodani, or Non-aligned. The alignment of bases depends almost wholly on the allegiance code. *</font>
The stellar tweaks are non-authorized tests. The minus sign prefixes a close companion, while the plus sign prefixes a far companion. The asterisk might represent the star the mainworld orbits, but I think it's currently dysfunctional, and actually is going to go away.

I believe the base codes are:
</font>
  • S scout</font>
  • N naval</font>
  • W scout way station</font>
  • D naval depot</font>
  • M military</font>
So your combinations are
</font>
  • SN/NS scout and navy bases</font>
  • SD/DS scout base and navy depot</font>
  • SM/MS scout and military base</font>
  • NW/WN naval base and scout way station</font>
  • NM/MN naval and military base</font>
  • WD/DW way station and depot</font>
  • WM/MW way station and military base</font>
  • DM/MD depot and military base</font>
* There is one world which has a Solomani base on an Imperial world. That would require a footnote.
 
Originally posted by Plankowner:
Rob, you would have to be careful with that limit. After all, in the one solar system that we know with any kind of detail, we have:

Venus: SIZ 7, ATM B (or D?)
Venus's atmosphere is acidic and extremely hot and at a very high pressure. There's a good case for considering it type C, even though it's canonically B. Of course, in the 3000+ years that have passed between now and the era of the Third Imperium who knows what they've done with it.
 
Works pretty well for me. (As always, my implementation-driven XML structure for reference can be seen at http://www.travellermap.com/res/sectors.xml) I fully intend to support MSEC and could pretty easily consume robject's data as well.

Some things a more verbose metadata format could (but not necessarily should) include are:

- Allegiances
- Borders
- Routes
- Purely presentational items, such as Labels, Colors (which should be separated into a stylesheet anyway)
- Different languages (e.g. the Vilani name for Alpha Crucis is Amkarim)
- Credits/Attributions (e.g. source, author, publisher, url)
- Multiple versions of data (e.g. M0 vs. M1000 vs. M1100 vs. M1120 ....; QLI vs. JG)
- Transclusion (e.g. referencing the data as an external file)

robject's format can easily and cleanly be extended to include most of these (allegiances, borders, routes, credits and transclusion), so it's a great format to start from.
 
Thanks Joshua. I was also thinking about borders and routes a week or so ago, and agree a simple format could easily be tagged.

Very clever with that Transclusion idea.
 
Sooo...

Greetings Gentlebeings, it's the Dreaded Thread Necromancer back in effect.

So how is this going? Just curious, I see of course, Mr. West and HIM get to get all the fun stuff in the Marches, which makes sense...still waiting...and for some more setting stuff and teeheehee..so seriously, any word on this lately, didn't want to wade through 46 pages. And I am not much of a programmer and I don't even know what runs XML and how...help?
 
World Movers, Inc. has been awaiting the clarion call. I believe, however, that Marc has incorporated our fixes to Sunbane into his master spreadsheet.
 
Short version: Jim Fetters and I went through all of the Sunbane sectors and did some cleanup.

Regarding XML: There are several proposals, none of which are official. Probably, the official format will remain the spreadsheet.
 
Back
Top