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

General How often does mail arrive at the local Starport?

Currently, financial institutions pay to have their servers as close as possible to stock exchanges, where latency in nanoseconds make the differences in arbitrage profits.
Hence why I'm of the personal opinion that transaction requests ought to be buffered for a time prior to simultaneous execution, to combat this kind of exploit. Sort of a "financial transactions airlock" type of arrangement, where the transactions execute on a set schedule (say, once every 5 seconds, for example) and every transaction that arrives needs to wait for the NEXT execution cycle following the current one to be processed, rather than executing upon arrival as is done now (creating the latency loophole that is currently being exploited).

So with a "clock tick" of 5 second intervals, any transaction requests that arrive would take ~5-10 seconds to execute and process, rather than being immediate, and all transactions captured within a single "clock tick" would be processed simultaneously (so no advantage to the low latency overlords).

But then, what do I know about structuring the operation of financial markets? :rolleyes:
 
Hence why I'm of the personal opinion that transaction requests ought to be buffered for a time prior to simultaneous execution, to combat this kind of exploit. Sort of a "financial transactions airlock" type of arrangement, where the transactions execute on a set schedule (say, once every 5 seconds, for example) and every transaction that arrives needs to wait for the NEXT execution cycle following the current one to be processed, rather than executing upon arrival as is done now (creating the latency loophole that is currently being exploited).

So with a "clock tick" of 5 second intervals, any transaction requests that arrive would take ~5-10 seconds to execute and process, rather than being immediate, and all transactions captured within a single "clock tick" would be processed simultaneously (so no advantage to the low latency overlords).

But then, what do I know about structuring the operation of financial markets? :rolleyes:
Or impose a transaction tax/fee to penalize high-frequency trading and thereby reduce volatility. This would reduce the benefit of momentary time advantages.

I don't know much either. :)
 
Depends on who pays; if it's on behalf clients, they.

If it's the financial institution doing it on it's own, them.

Problem is, they can comingle funds.
 
Ok buried in Supplement 8 Library Data A-M Express Boat entry;

Time between jumps is almost always less than four hours, and can be under seven minutes.
Xboats on route it's six per day. By that.
Ok, I stated this, but that really speaks to turn around time not frequency...
 
S7
High population and high technology star systems can be expected to have up to twelve xboats present at one time, probably distributed evenly between arriving and departing ships.
Lower population systems will have fewer xboats
 
S7
High population and high technology star systems can be expected to have up to twelve xboats present at one time, probably distributed evenly between arriving and departing ships.
Lower population systems will have fewer xboats

Missed that, thanks.
 
S7
High population and high technology star systems can be expected to have up to twelve xboats present at one time, probably distributed evenly between arriving and departing ships.
Lower population systems will have fewer xboats
I think we're going to need a bigger XBoat Tender...
 
I think we're going to need a bigger XBoat Tender...
The XBoat Tender is horrifically wrong sized for its role.
It's a J1 starship that needs to deploy along routes that can involve a 4 parsec gap.

How is an XBoat Tender supposed to be able to cross that 4 parsec gap on J1 drives and nowhere near enough fuel?
If the Tenders were J2 and had enough fuel tankage for a 2J2=4 parsecs self deployment, that would make a lot more sense. They would at least be able to transit the 4 parsec gaps under their own power when rotating out of service for repairs and overhauls or return to waystation for scrapping/deep refurb (or whatever).

Problem is that with LBB2 drives and a TL=10 limitation, you can't go any higher than H/H/H drives, which are code: 1 in a 1600 ton hull, but code: 2 in an 800 ton hull.

So a superior design would be one that uses an 800 ton (custom) hull built to a TL=10 standard and is fitted with H/H/H standard drives capable of 2J2, requiring 340 tons of fuel tankage (and 8 tons for a fuel purification plant).

Personally, I would prefer to give it an organic fighter capability, rather than arming the Tender itself with turrets and weapons, so if the Tender needs to be defended such defense can be undertaken AWAY FROM the Tender itself (Tender in reserve) and let the armored medium fighters (40 tons, 5G, capable of towing up to 160 tons of external load) handle any defensive responsibilities as well as XBoat deployments and recoveries.



Hmmm ... I might actually have to take another look at this and do more than just napkin math for it ... :unsure:
 
What TL10 limitation?
Canonically speaking, the XBoat system was built to a TL=10 standard (even though TL=12 was the maximum available at the time) in order to have (I'm presuming) the broadest possible industrial supply chain throughout the Third Imperium (the more "local" sources available the better!).

As for a "why TL=10?" the answer to that is because TL=10 is the minimum required for a model/4 computer ... which just so happens to be the lower bound needed for a J4 drive.
 
And yet jump 4 is TL13 in the Third Imperium setting.

By the way canonically the Imperium achieved a widespread civilian TL of 13 in the 300s, more than three centuries before the x-boat system was built and actually achieved a widespread civilian TL of 14 before the system was completed.

Noe I use the term widespread civilian since it is obvious from the canonical Agent of the Imperium novel that the Imperial Navy and IISS were ahead of the TL of the civilian TL.
 
And yet jump 4 is TL13 in the Third Imperium setting.
This is where we bump up against the cleavage point between the two (well, two and a half...) CT starship paradigms.

LBB2.81 permits J4 as early as TL=10 controlled by a model/4 computer in a 400 ton form factor (or smaller).
LBB5.80 permits J4 at TL=13+ as a limitation of --> custom <-- drives.

The way to square this circle of differing limitations is to interpolate between them for a "thread the needle" approach.

First ... J4 capability needs to be "discovered, tested, proven" using custom drives before the necessary design parameters can be back ported/tuned into the capabilities of standard drives.

In other words, there needs to be a capability within the polity/faction of building LBB5.80 TL=13 J4 custom drives and make them WORK before you can then turn around and use that higher tech research and development to enable LBB2.81 TL=10 J4 standard drives to operate in a hull form factor of 400 tons or less.

Basically, "J4 needs to be discovered" (at TL=13) before it can be back ported into older (legacy) technologies (at TL=10) as a matter of tuning up older hardware "to do new tricks" that it was capable of all along (because the engineering margin was there from the start).

Note that such an interpolation between the two design paradigms "preserves the no J4 until TL=13 rule" while stipulating that a particular polity/faction needs to have achieved TL=13 (at a Type A starport) SOMEWHERE within its sphere of control (to make the "research discovery") before that J4 performance (in small hulls!) can be achieved through use of standard drives "properly tuned" thanks to the fruits of the TL=13 research and development discoveries.

One of those "you can teach an old dog new tricks, but you need a new dog to do the teaching first" kinds of deals.

So the world/starport where the construction takes place does not itself need to be TL=13 if using LBB2.81 standard drives (in small enough hull sizes for a small ship universe), while TL=13 is absolutely required to "make the technological breakthrough in the first place" and for building hulls larger than what the standard drives can handle (bigger ship universe stuff).
By the way canonically the Imperium achieved a widespread civilian TL of 13 in the 300s, more than three centuries before the x-boat system was built and actually achieved a widespread civilian TL of 14 before the system was completed.
Which works perfectly fine.

TL=13 was reached 300+ years before the XBoat Networked started build out and was (by the early 600s) a thoroughly vetted and known working technology. Basically, the bugs had been worked out of the necessary systems (on the custom drive side of things relevant to LBB5.80) in advance. So J4 "had been discovered" by the LBB5.80 route already when the buildout of the XBoat network began.

However, by relying on STANDARD drives (rather than CUSTOM drives) for the XBoat Network, the IISS Communications Branch was able to standardize on TL=10 starship designs for the XBoats, rather than needing to standardize around the much more challenging/limited (and presumably vulnerable) TL=13 requirement for custom drives. Use of TL=10 standard drives (A-H) suited their needs just fine and offered a far broader (and therefore, supply chain secure) technology and industrial base for the build out of the Network that wouldn't have to compete with the higher tech demands of other services and sectors (starting with the Imperial Navy).

So custom drives first ... dictates maximum performance limits for standard drives afterwards.
 
There is no bump.

The setting doesn't explain how it has letter drives but it does stick to the drive TL paradigm introduced in HG80 in all subsequent iterations.
 
There is no bump.

The setting doesn't explain how it has letter drives but it does stick to the drive TL paradigm introduced in HG80 in all subsequent iterations.
My take on it is that the letter drives work at higher Jns in suitably-sized hulls than would be possible under HG and later rules systems, for reasons that are not well understood, because canonically, Jump itself is not well understood.

It works, but nobody knows why despite centuries of research.

Out-of-universe, of course, it's because the rules changed, but they retained the legacy drives to maintain backwards compatibility.

Edit to add:
IMTU they're the prototypes/early versions of drives that will become routine (under HG rules) once technology advances sufficiently. But they're the prototypes that are known to work.
 
Last edited:
That's a more ... permissive stance ... than the one that I took, but an equally valid interpretation.
Curiously, it means that smaller ships are capable (at great expense!) of achieving higher jump numbers "early" relative to LBB5.80 ... but those "early fast movers" are also heavily penalized by their "more than 2%" tonnage requirement for a starship bridge AND the more "punishingly inefficient" power plant fuel formula used for LBB2.81 power plants in hulls of 100+ tons (small craft appear to use the 0.01MPn formula for LBB2.81 small craft drives). If you want to make the argument that the "oversized at 20 tons" bridge size inside these smaller hulls is what makes this kind of performance leap using LBB2.81 relative to LBB5.80 possible in the first place ... have at it. :cool:
 
My take on it is that the letter drives work at higher Jns in suitably-sized hulls than would be possible under HG and later rules systems, for reasons that are not well understood, because canonically, Jump itself is not well understood.

It works, but nobody knows why despite centuries of research.

Out-of-universe, of course, it's because the rules changed, but they retained the legacy drives to maintain backwards compatibility.

Edit to add:
IMTU they're the prototypes/early versions of drives that will become routine (under HG rules) once technology advances sufficiently. But they're the prototypes that are known to work.
Game design is a TL 30 capability.
 
We live in a world of news every minute, 24 hours a day. I think it's hard for us to imagine how we would deal with such out of date information being the best available. It certainly seems to make haste a waste.
I was in upper elementary ("Intermediate" per more modern terminologies in education) when the 4 stations in Anchorage started getting things the same week as the lower 48, and that pretty much only for sports and news. Prior to that, TV news was local on day of, lower 48 networked news show the following day, having been flown up on 16mm film and/or 1/2" RTR Tape.
By high school (fall 83) all four were getting the evening news by satellite.
By 1987, all were on grab by satellite or mailed up on videotape for same schedule primetime and syndicated talk shows (most of which were filmed at leas a week before airing...).

So, yeah, I remember having out of date news... it sucked. No election results from out of state, however, was nice. (Note also, until 1986, Alaska was 5 time zones... and some locations were still teaching the elementary school curriculum almost entirely in Russian, excepting the required 2.5 hours min/week of English Language...)

I also remember ordering one of the Traveller boxed games from Gamescience by mail order... 2 weeks for them to get the order, 4-6 for it to arrive, and no contact in between.

When the internet made communication person to person with persons outside one's local community not only inexpensive, but in real time... it changed a lot.

Ordering
The XBoat Tender is horrifically wrong sized for its role.
It's a J1 starship that needs to deploy along routes that can involve a 4 parsec gap.

How is an XBoat Tender supposed to be able to cross that 4 parsec gap on J1 drives and nowhere near enough fuel?
Demountable tanks in their 400 Td bay...
They're just fine if you have 3-4 per system; one's always en route to incoming point, one's at, one's fueling, and one's heading back to fuel up.

Note that 9-12 XB in system is, given the ~35 hour window, quite likely one departure per day per link. nominally, the XB should be 3 per linkage, well, 1-4 in system at a time, normally 2-3.
One on day 7 of last jump just arriving, one on day 8 of last jump (probably had a day for R&R&R, but maybe not a full day), one prepping to go or goingon day 9 since last jump, resetting the clock...
and one on standby, in case of emergency information. Whether this means a 10-day cycle or a 9 day R&R for the pilot....
 
Back
Top