UWP Changes

[Malenfant]

Why use Ring/Ray at all? It's completely impractical, I can't recall ever seeing any Traveller maps in that format, and nobody actually uses that in the game anyway - everybody uses sector/subsector/hex coordinate (or something like that).

 

[Gruffty]

Originally posted by robject:
In particular, what should we do about these:

# Spica (Gruffty)

Thanks for taking an interest, robject

As Spica is outside the scope of MWM's T5 Second Survey regen criteria (i.e. Imperial sectors only) I don't think Spica should be condsidered an "urgent" case of any kind.

SPL is taking a different route for regenning Spica compared with the work that others have carried out here. This process will, inevitably, take more time and SPL will announce the completion of the regen process when that process is completed to the satisfaction of those involved.

Whilst I appreciate that the above answer is, to a degree, "vague", it would be best for all involved in the T5 Second Survey regen process to consider Spica " a work in progress". I hope this makes things a little clearer for all involved.

</NHS management mode >

 

[robject]

Wonderful Gruffty! I forgot/didn't realize it lay completely outside of Imperialness.

Consider it laissez-faire.

Re: Ring/Ray: my perl script calculates Ring/Ray coordinates automagically. I wanted to be sure it had the correct offset.

 

[jfetters]

kewl

 

[Gruffty]

Originally posted by robject:
Wonderful Gruffty! I forgot/didn't realize it lay completely outside of Imperialness.

Glad to be able to remind you

However, it was you who informed me that Spica is outside the T5 regen area

Consider it laissez-faire

Eh? Bon chance, Rodney, he who dares, wins, eh?

Re: Ring/Ray: my perl script calculates Ring/Ray coordinates automagically. I wanted to be sure it had the correct offset.

I don't wish to appear to be being difficult, but a) AFAIK, there are only two references to the Ring/Ray business; one is in (I think) the CT Library Data supplement, the other is in one of the MT manuals, b) I don't ever recall Ring/Ray being something that was universally used in play or World/StarGen and c) Ring/Ray isn't used in any of the canon books for mapping. So I s'pose I'm bound to ask: why bother?

 

[Flynn]

Originally posted by Gruffty:
I don't wish to appear to be being difficult, but a) AFAIK, there are only two references to the Ring/Ray business; one is in (I think) the CT Library Data supplement, the other is in one of the MT manuals, b) I don't ever recall Ring/Ray being something that was universally used in play or World/StarGen and c) Ring/Ray isn't used in any of the canon books for mapping. So I s'pose I'm bound to ask: why bother?

Robject's code allows him to print multiple sectors in one map, so he needs it for his mapping purposes. Other than that, it's not a valid issue for publication. It's a good enough reason to want to know, though.

Hope this helps, Gruffty,
Flynn

 

[Gruffty]

Thank you, Flynn It all makes sense now, in the wyrde and wonderful world of Gruffty....

 

[jfetters]

Originally posted by robject:

Next, I found your Old Expanses data, corrected the Sunbane list, added in the external references, extracted the AOTI baseline data, and did a draft regeneration. The corrected Sunbane file, the AOTI extraction file, and the regenerated file are all posted.

Rob,

Regarding the regen draft stuff - a couple questions:

- What's up with the ordering of the worlds? I looked at Antares and there seems to be two sets of numbers - it starts out in the 01s, then progresses and about halfway thru, more 01s start over again.

-Also, It seems that the "sections" are a bit off - meaning, it lists

1-18: Name
20-23: HexNbr
25-33: UWP

but it doesn't seem like that matches up. There also seems to be FOUR digits in the PBG column.

 

[Gruffty]

Jim: there are two ways of listing UWPs by hex location in these data files.

The first is the "straight column" approach, i.e. start at hex 0101 and work your way down to 0140, then go up to 0201, down to 0240, and so on, across the sector. I think I am correct when I say the majority of .sec files are organised in this way.

The second way is to list the hex numbers by subsector, so you would get the 01xx hexes from further down the sector suddenly appearing in the listing.

And guess what? Spica is listed by subsector. Teh.

 

[jfetters]

Thanks, Gruffty! At least I am not going crazy. At least in that way...

 

[Gruffty]

It got me wondering as well, Jim, when I first came across it. I had thought that all .sec files would be formatted in the same way and was 100% thrown when I got Spica and found it to be listed by subsector. There are other listings available for Spica as "straight column" but the UWP data is late CT/early MT so no good for comparing to AotI.

 

[Anthony]

There are other minor differences, generally in offsets. For my map generators, I had to create a header for each file specifying where certain things were.

 

[Gruffty]

And some .sec files include stuff that you don't see in published books, like "O:xxxx", "C:xxxx", "Tp", "Tn", and a whole load of other stuff. Most confusing.

 

[Flynn]

I load the data into an array of objects, and then sort the objects by hex column and row. When I output my data after modifications (such as 1248 Collapse/Recovery), I sort them in the traditional manner.

I also have a method to call when I just want to simply sort a sec file into the traditional manner.

It's a nice routine to have, because sec2pdf sometimes breaks if you don't organize the UWPs in the traditional manner.

Okay, random comments are over,
Flynn

 

[robject]

Originally posted by Gruffty:
Ring/Ray isn't used in any of the canon books for mapping. So I s'pose I'm bound to ask: why bother?

As Flynn said, I use Ring/Ray, for distance computations from sector to sector. In that it's handy, and cooler looking (and less Imperiocentric) than the sector-offset-from-Core.

On a whim, I had perl re-order the sectors based on subsector order instead of straight hex order, but my perl module does it all for me so it's no biggie to change the order (I created a "subsector" method that returns the subsector a world is located in, and then could overload the sort operator).

And as for the data positions, well, that's cleanup I hadn't done. Once again, my perl module almost doesn't care what column positions the data shows up in, because it parses using regular expressions. All it needs to look for is the anchor points:

(1) hex + UWP
(2) PBG + Allegiance

With those two anchors, the rest of the data falls into place, to one side or another of each anchor. And when #2 is missing, it tries to look for the old, old, Classic format.

 

[Flynn]

<murmuring to himself...>

Regular expressions... now, why didn't I think of that?

<returns to coding...>

Thanks,
Flynn

 

[robject]

Here's a starting place:

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">(for the standard UWP):

if ( $line =~ /^\s*(\S.+\S)? # $1 name
\s*(\d{4}) # $2 hex
\s+(\w\w{6}-\w) # $3 uwp
\s+(.*) # $4 codes
\s+(\d{3}) # $5 PBG
(.*) # $6 etc
$/x )
{
$self->_src = 'Std';
$self->name = $1;
$self->loc = $2;

$self->_loadUwp( $3 );
$self->_loadCodes( $4 );
$self->_loadPBG( $5 );

my $etc = $6;

if ( $etc =~ /(\w\w)\s*(.*)/ )
{
$self->allegiance = $1;
$self->_loadStars( $2 );
}
else
{
$self->allegiance = 'Na';
}

return $self;
} </pre>[/QUOTE]

 

[Gruffty]

Originally posted by robject:
I use Ring/Ray for distance computations from sector to sector. In that it's handy, and cooler looking (and less Imperiocentric) than the sector-offset-from-Core.

Fair enough

 

[robject]

I'll post my trivial ring/ray code in the "software" forum...

 

[jfetters]

robject,

FYI, I was updating some UWPs (subsector N of ANtares) in my Universe database when I came across a possible bug -

Khurda (Antares 1036) is listed as being a desert world, however Universe says that the value is not possible (2D - 7 + size). Don't know if this is a known issue or not...