Modeling the communications delay

[The Oz]

Something I've never seen mentioned but I think would be very handy would be some kind of software that would handle the communication delay found in the TRAVELLER universe. Since messages move between worlds at the speed of jump (which varies depending on the ship) it's possible for news to spread very erratically. News of an event in some podunk starsystem off the beaten path (X-boat/trade routes) would have to wait until someone came there, picked up the news and then jumped it somewhere else. From there it would spread according to the trade and X-boat networks.

For role-gamers this could help track the spread of rumors, and the news of the player's own actions. With a fast enough ship and careful route planning, players could even beat the news of their own deeds and make speculative investments accordingly.

For wargamers such a software would have obvious use in tracking the news of the movement of enemy (and friendly) fleets and the ability of admirals to send orders to their forces. I would love to see a computer version of the Fifth Frontier War boardgame with this communication delay built-in. It'd be frustrating, but very realistic (in the OTU, anyway).

Ideally the software could read data input from the various subsector/sector map generators and then, given the trade routes/X-boat routes, calculate the time needed for news to go from planet X to planet Y.

 

[TheEngineer]

Perhaps we could ask Stuart Ferris to implement such things into his new H&E versions.....

 

[aramis]

it isn't hard to implement, but it can become very data intensive...

the problem is that one needs to know the routing mechanics and have a sufficiently robust datamodel for the systems.

assume for example, a simple data structure for a world, within a limit of 8 sectors across by 6 tall:

Struct simpleWorld{
char x;
char y;
char upp[12]; //incl tppg
char name[33];
char alg[2];
char stelldata[12];// allows for 4 compressed stars codes
char bases[3];
struct simpleWorld* nextPtr;
}

64 bytes per system.

for ease of cycling through, we'll add a nextPtr and assume only 2 bytes.

Adding some linking data; limiting to 30 serviced worlds , adds 2 bytes each allowed link, or 60 more bytes, assuming no data about link type. (based upon few worlds having more than 6 long links aka xboat routes and courier service is limited to J2 and thus no more than 3x6=18 systems, and then adding a6 system buffer jst in case...)

adding some speed efficiency, we add 1 byte for the char holding the number of links used.

we add an unsigned int (2bytes) for each of date data arrived and for hop count.

so we've added 60 + 1 + 4 = 65 bytes, and doubled the data structure's size.

loop a:
_ sort through the systems, examining for date present.
_ if date found, add one to hop count, and 8 to arrival
date, and gosub loop b
_ next system search for date.

loop b:
_ lookup target x/y
_ gosub loop c
_ when count equals number of links, return from sub.

loop c:
_ search systme list for match to current target
_ optional: adjust arrival date by + or - 1 day for this system
_ on finding target, if date less than extant date, or date is null, then replace date and hop-count. with valid values.
_ return from sub.


We're talking 8 systems per kb. that is large files; in an average sector with some 400 worlds, that's 50 kb plus sector overhead.

time overhead is reduceable (drastically) if current system is a static pointer in loop c, and all the x/y lists are ordered the same way....

other limits can be built in; hop-count limits, date limits, aligience limits, sector limits, etc. Date limits and hop-count limits get checked in loop a.

the program code isn't terribly long to write to mine the data; but by doubling the struct (plus the padding out that occurs in structs in many systems) we increase memory useage AND data-file sizes. Assuming the simple struct generates at load time from a GEnie archive format (80 col space delimited text...) that's 80B per system compressing in memory to 64B... or expanding into part of a 129B (132 with typical padding) struct.

Upon opeing a GEnie file, we'll need to generate the links. We can either assume news will flow along any trade link with weekly flows of a given route minimum, or we can assume a coordinated postal effort, and thus find route per the CT Xboat methodology. Each A port looks for all other A ports at range 3 or 4. if fewer than 1, look for B ports in same, and A ports at 2. All worlds within two get Type S weekly service from an XBoat port. If there is no xboat port within 2 PC, service will be from the nearest B or C port that does have Type S service.

the other issue is "Just how ^&*(* many type S's and XBoats are there out there?"

in order to use the above calculations, which don't account for portential misjumps, we have to assume each route has 16 ships (8 day cycle, 1 each way per day), or a capital investment of about 352 MCR per scout/courier link, and about 3x that per xboat link., plus upkeep.

Realistically, we need a larger data structure which also lists type of link for each link, with several of the following types:
daily xboat (rougly 3 GCr in capital, at 17 XB plus 2 tenders )
weekly xboat (roughly 1GCR in capital, 4 Type XB, 1 tender)
daily scout/courier (roughly 350 MCr in capital; 16 type S)
weekly scout/courier (roughly 90 MCr in capital, 4 type S)
biweekly scout/courier (roughly 50 MCr in capital, 2 tpe S and 2 ground stations)
monthly single scout route (roughly 25 MCr in captial, type S and two ground stations.)

each of these has a different calc for departure (and thus arrival) dates.

if we instead try to figure out using GT:FT, we run into even more problems with the calculations, as we need the trade route value, and to make an valid estimate of ships/week, etc... and then to figure if the tdata is xboated, couriered, or sent via merchant...

the real problem is that the baseline assumptions of transmission are all debatelable variales.

IMTU, all xboat routes on the map in the imperium are daily. all couriers leave on wonday, arriving on sixday, senday, or oneday. high pops, or B or C ports have weekly runs; D and E ports or low pops get biweekly service (one each way on 1st and 15th day of month). D and E ports whch are also low pop might get monthly service(to on 1st, back on 15th of month). real news flows also via civil shipping.

Since the stats for the Type S are an artifact of the CT design sequences, I've no problem with even cheaper mail-router craft built under HG/MT/FF&S/T4/T20: J2, 1G, 1bis, 2 staterooms, no hardpoint, no carried craft. Usually steamlined. Type S are used where gravitic sistuations require it; either due to jump masking or local gravity.

 

[Zinzan]

Errrrmmmmmmmm

Very confused by above post (don't try and explain - programming is just Hiver talk to me at best )

BUT I love the ideaof a programme that could do this and would love it even more if it could be implemented in something like Universe.

 

[aramis]

Originally posted by Zinzan:
Errrrmmmmmmmm

Very confused by above post (don't try and explain - programming is just Hiver talk to me at best )

BUT I love the ideaof a programme that could do this and would love it even more if it could be implemented in something like Universe.

fundamentally I pointed out in excrutiating detail that, while the programming to do it is possible, it's not space efficient, nor is it terribly time efficient. Additionally, it requires a lot of assumptions which are definitely NOT constants for the various TU's.

 

[kaladorn]

Not to disagree with Aramis, but:

1) If I'm willing to leave my 2.4 GHz P4 crunching overnight (or while I get dinner, or whatever), then that is a *lot* of cycles. Similarly, the machine has a lot of actual physical memory, and a huge virtual memory by virtue of the swapfile. Yes, not everyone has this kind of horsepower, but the limitation then should merely be how big of a chuk of the universe they can work with at a time.

2) I'm not sure the methods you've suggested above are the best or most efficient (you didn't say that they were). Much work has been done on similar problems over the last 15 years. So a better, or at least more time or space efficient, mechanism may be available. (Assuming the method is not Patented...)

3) You are correct that a lot depends on assumptions of service levels, jump results, etc.
A proper model would have to factor in redundant transmission, jump/maintenance problems (even if done abstractly), equivalent civilian traffic, etc. The propagation of news is not an entirely simple matter, as you point out. OTOH, with some abstractions, a few handwaves, something *useful* if not entirely perfect, could be devised that would be workable.

4) Last but not least, such a thing would be very useful to some GMs (I number myself among them).

 

[The Oz]

As a GM (which I still consider myself to be, even though I've been out of the loop for a while now) I can usually calculate the time delay of any particular message that I need to know about for my players. There's usually not that many messages that the PCs need to know (or not know) about and that reduces the work quite a bit.

What I was really thinking about when I started this was a computer version of Fifth Frontier War, where the communications delay was built right in, instead of simulated by having to plot moves so many game turns ahead.

This is always been one of the things that has facinated me about warfare before the telegraph was invented, and facinated me about TRAVELLER since I discovered it: the difficulty of managing a war where your information (both on your own forces and the enemy) is weeks or months out of date. The kind of strategic thinking required would be quite different from our modern information overload system.

 

[robject]

This is just screaming "database application"...

 

[Hemdian]

Originally posted by Zinzan:
Errrrmmmmmmmm

Very confused by above post (don't try and explain - programming is just Hiver talk to me at best )

BUT I love the ideaof a programme that could do this and would love it even more if it could be implemented in something like Universe.

That kind of function will almost certainly be in Universe Release 3. Unfortuneately, that's still a couple of years away ... gotta do system generation first.

Regards PLST

 

[FlightCommanderSolitude]

Originally posted by The Oz:
This is always been one of the things that has facinated me about warfare before the telegraph was invented, and facinated me about TRAVELLER since I discovered it: the difficulty of managing a war where your information (both on your own forces and the enemy) is weeks or months out of date. The kind of strategic thinking required would be quite different from our modern information overload system.

A great point, and it also applies to pretty much any endeavor, not just warfare: megacorporations, law, finance.

It would be cool to be able to, for example, indicate that a particular system is the origin of a piece of information (or a ship), and be able to see how far that piece of information could get in one week, two weeks ... N weeks. Conversely, it would be nice to be able to find out how many weeks it would take for said piece of information (or said ship) to travel from said origin to any other system. The route(s) would also be interesting to know, might as well show them since you have to calculate them. Finally, it might be nice to be able to impose constraints, such as jump number or xboat network.

 

[aramis]

Originally posted by kaladorn:
Not to disagree with Aramis, but:

1) If I'm willing to leave my 2.4 GHz P4 crunching overnight (or while I get dinner, or whatever), then that is a *lot* of cycles. Similarly, the machine has a lot of actual physical memory, and a huge virtual memory by virtue of the swapfile. Yes, not everyone has this kind of horsepower, but the limitation then should merely be how big of a chuk of the universe they can work with at a time.

2) I'm not sure the methods you've suggested above are the best or most efficient (you didn't say that they were). Much work has been done on similar problems over the last 15 years. So a better, or at least more time or space efficient, mechanism may be available. (Assuming the method is not Patented...)

[snip]
4) Last but not least, such a thing would be very useful to some GMs (I number myself among them).

there may be some decent shortcuts... but they aren't going to be based upon diret looks at data routes... <G>

If you couldn't tell, I've looked into the coding of it... I think it would be very useful. In my case, it's the UI issues and coding the link determinations. (Which, BTW, are a time save themselves. A further on would be storing the link end systems' struct pointers at load time, thus removing loop c from the end, but making load times climb.


And the issue of "How Pervasive is YOU IISS Postal System"; if the maintenance cost is from 1 to 50 MCr per link, will the IISS Spend that much?

 

[aramis]

Originally posted by robject:
This is just screaming "database application"...

fundamentally, any stellar charting software for traveller IS a database engine...

 

[kaladorn]

Originally posted by FlightCommanderSolitude:
It would be cool to be able to, for example, indicate that a particular system is the origin of a piece of information (or a ship), and be able to see how far that piece of information could get in one week, two weeks ... N weeks. Conversely, it would be nice to be able to find out how many weeks it would take for said piece of information (or said ship) to travel from said origin to any other system. The route(s) would also be interesting to know, might as well show them since you have to calculate them. Finally, it might be nice to be able to impose constraints, such as jump number or xboat network.

Well said. MT included maps which showed the propagation of news of the Emperor's death. The ability to generate some sort of similar map would be pretty handy. To know when key news events reach a particular area would be a very handy feature.

 

[FlightCommanderSolitude]

Apropos of this discussion, does anybody have a formula for determining distance between two hexes on a hex grid layed out Traveller-fashion? Either I'm missing something obvious, or it's rather complicated.

For example, if I look at hex 0504, how do I find the distance to hex 0603? Looking at a map, I can see that it's obviously one hex away, but how would I derive that mathematically?

I've found some good material on the net regarding hex grids, but there are a number of different coordinate systems and layouts for hex grids, and none of the formulas I've found work with the way Traveller subsectors are laid out. Somebody must have solved this!

 

[robject]

Here are functions to measure the distance from one hex to another, and one ring/ray to another. Ring/Ray calculations are slightly different because even hexes have odd ring/rays. Go figger.

As far as I can decipher, here's the hex-to-hex function in pseudocode:

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;"> distance( col1, row1, col2, row2 ):

a1 = row1 + int(col1/2)
a2 = row2 + int(col2/2)

d1 = abs( a1 - a2 )
d2 = abs( col1 - col2 )
d3 = abs( (a1 - col1) - (a2 - col2) )

if ( d1 >= d2 ) and ( d1 >= d3 ) return d1
if ( d2 >= d1 ) and ( d2 >= d2 ) return d2
return d3</pre>[/QUOTE]Here is my actual source code:

To find the distance from one hex to another, in parsecs (in Perl):

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">#
# How far apart are these hexes?
#
sub distance
{
my ($hex1, $hex2) = @_;


my ($c1, $r1) = ($1, $2) if $hex1 =~ /(\d\d)(\d\d)/;
my ($c2, $r2) = ($1, $2) if $hex2 =~ /(\d\d)(\d\d)/;

my $a1 = ($r1 + int($c1/2));
my $a2 = ($r2 + int($c2/2));

my $d1 = abs( $a1 - $a2 );
my $d2 = abs( $c1 - $c2 );
my $d3 = abs( ($a1 - $c1) - ( $a2 - $c2 ) );

my ($dist) = reverse sort { $a <=> $b } ( $d1, $d2, $d3 );

return $dist;
}</pre>[/QUOTE]To find the distance in parsecs between two ring/ray coordinates (in PHP):

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">//
// Ring is row, Ray is column
//
function distance( $ring1, $ray1, $ring2, $ray2 )
{
$a1 = ($ring1 + (int)(0.5+$ray1/2));
$a2 = ($ring2 + (int)(0.5+$ray2/2));

$d1 = abs( $a1 - $a2 );
$d2 = abs( $ray1 - $ray2 );
$d3 = abs( ($a1 - $ray1) - ( $a2 - $ray2 ) );

if ( ($d1 >= $d2) and ($d1 >= $d3) ) return $d1;
if ( ($d2 >= $d1) and ($d2 >= $d3) ) return $d2;
return $d3;
}</pre>[/QUOTE]

 

[robject]

By the way, credit where it's due: my friend and co-worker Jon Buller worked out the formula for hex-to-hex, with Traveller specifically in mind. I implemented it in Perl and PHP and have used it for perhaps 5 years.

In a related note, here are the mappings of Ring/Rays to several sectors. To get the Ring/Ray for a world, add the base Ring/Ray for its sector to its hex location.

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Gvurrdon 9888 ring/ray 62705
Tuglikki 9888 ring/ray 62745
Spinward Marches 9920 ring/ray 62705
Deneb 9920 ring/ray 62745
Corridor 9920 ring/ray 62785
Trojan Reaches 9952 ring/ray 62705
Reft 9952 ring/ray 62745</pre>[/QUOTE]For instance, Regina (1910/Spinward Marches) resides at 9930 Ring/Ray 62724 (I think that's how you add them -- ring is row, ray is column, and the hex has the column first, right?)

 

[FlightCommanderSolitude]

Thanks for the code, I'll try it out; my function was close but, alas, not close enough. BTW, would you care to explain the ring/ray stuff a little more?

 

[robject]

I'll do my best.

Ring/Ray coordinates are a way of mapping hexes to galactic positions. It's specific to a 'narrow' band of space around our galaxy, rather than specific to a sector, thus providing one way to ignore sector boundaries.

The Traveller Book talked about Ring/Ray coordinates, which sort of map out the hexes in the OTU's part of the galaxy. The Ring number is the number of hexes out from the center of the galaxy, and so corresponds to the Row of a hex location. The Ray corresponds to the number of hexes antispinward from Capital (Sylea), which is defined as Ray 0, so it more or less corresponds to the Column field of a hex location. Regina is therefore some 64,000-odd hexes antispinward from Capital. I hope that's clear, but I don't think I'm going a good job of explaining it.

This mapping system is valid for a width of a few hundred parsecs coreward and rimward of Sylea.

 

[kaladorn]

You'd think this would be problematic.

We have rectangular subsectors arranged in a rectangular sector and then mated to the next one. We thus end up with a square grid for space, not a pie slice which the ring/ray approach (well, a chunk of a pie slice...) should produce. So at some point, the similarity breaks down.

Ideally, we'd map stars wrt the core as a radial (ray) and a displacement (distance). But the OTU was *not* mapped this way, it was mapped on what is obviously a rectangular linear system and thus tools that want to model this accurately should probably account for that.

Note also that we have another interesting point: The distance between two systems as the crow flies is interesting but almost a useless measure. The distance at Jump-X, where X is a specified number and includes provision for fueling along the way (no gas-giant-less desert systems!) would be far more useful, but also a much much more computationally intensive project. It could be simplified with some assumptions, but nothing will prevent dead-ending.... (except massive sized models and lots of cycles!).

Anyway, this is an interesting discussion!

 

[robject]

Yes, you're right on both points. It's not useful enough to be used, so to speak.

However, it has some utility for computer programs. According to TTB, our sectors *are* chunks of pie wedges... but the pie is sooo huuuge, the sector-wide slices are sooo narrow, and the sector-slices are sooo far out along their respective pie wedge, that their coreward end is less than 0.01 light year narrower than the rimward end... thus we can use rectangular sectors coreward and rimward for about as far as we'd care to. Thus Ring/Ray is tuned to work with the OTU sectors.

That's one big pie.

The fact that it unites all hexes in Known Space under one grid system (for all practical purposes it's a grid) makes it useful for lazy programmers like me who like a particular kind of control flow in our code: some boundary cases are simplified. For instance, when Tigress jumps from Gvurrdon diagonally to Deneb, distance calculation uses the same formula as in an intra-sector jump. I don't have to make sure the sectors are neighbors, then massage the locations to produce a result. Call me nitpicky. Go ahead.

Another potential benefit is that hexes now have unique identifiers that double as those absolute locations. OK, maybe that's a stuffy reason. Call me nitpicky.

I'm using them so I don't have to write explicit boundary-checking rules for sectors. Client code can map them back to Sector/Hex easily enough, or the database can have explicit columns for that data (even easier, and less coding, though not normalized, but who cares?).