On Updating Fast Drug... Jeff Zeitlin (30 Dec 2024 21:32 UTC)
Re: [TML] On Updating Fast Drug... Jeff Zeitlin (01 Jan 2025 02:31 UTC)
Re: [TML] On Updating Fast Drug... Timothy Collinson (01 Jan 2025 09:53 UTC)
Re: [TML] On Updating Fast Drug... Timothy Collinson (01 Jan 2025 10:55 UTC)
Re: [TML] On Updating Fast Drug... Charles McKnight (01 Jan 2025 11:08 UTC)
Re: [TML] On Updating Fast Drug... kaladorn@xxxxxx (03 Jan 2025 23:53 UTC)
Re: [TML] On Updating Fast Drug... Timothy Collinson (05 Jan 2025 08:47 UTC)
Re: [TML] On Updating Fast Drug... Jeff Zeitlin (01 Jan 2025 17:23 UTC)

On Updating Fast Drug... Jeff Zeitlin 30 Dec 2024 21:32 UTC

A number of years ago, a contributor proposed, as part of an article on
passages, that the availability of Fast Drug ("F", henceforth in this
message) be modified.

As written, F is available in pill form, modified metabolism at 60:1, and
each dose is for one subjective day (S-Day)/60 objective days (O-day). The
cost of each dose is Cr200.

The change proposed is that F be available in "molecular powder" form, to
be mixed with an appropriate liquid substrate and administered through what
amounts to _Star Trek's_ hypospray. This would also allow controlling the
dose such that it would become viable to dose a passenger before boarding a
ship, and the passenger would experience about three hours of time, at the
end of which s/he would be at the intended destination (barring misjump) -
in other words, "fractional" dosing to control/limit the duration of
metabolic modification.

The cost cited in the proposal was not clearly set out, but what was
written could reasonably be read as Cr3 per O-day. However, the lot size
was unclear in notation, and used an expression whose _intent_ was clear,
but which has an actual meaning unrelated to the sort of calculation being
proposed.

I am intending to reprint this article, with this section edited to
clarify, and possibly to present costs that are more appropriate - I'm not
certain that it's reasonable for a more controllable effect to result in a
lower "end use" cost; thus I present the question to the TML brain trust:

Assuming that a starship or SPA medic can easily administer F in this form,
what should be

   (a) the cost _to the ship/SPA_ per "dose-hour", and what should be the
       "lot size" in which the ship/SPA obtains F in this form? (One
       "dose-hour" is the quantity needed to keep a notional 'standard
       person' under the influence of F for one _objective_ hour.)

   (b) the cost of one dose-hour to the recipient, on the assumption that a
       standard one-jump trip will last 180 _objective_ hours, including
       time to dose the recipient, situate the recipient aboard the ship,
       and remove the recipient to a recovery facility at the destination

(The intent of the passage proposal is that the passenger should be loaded
into the ship asleep, and remain asleep the entire duration of the trip
(three s-hours) - essentially, actual costs to the ship would be allocation
of space for a "bunk" and baggage allowance.)

As a side question, should initiation and recovery be managed by the ship,
or the SPA?

NOTE: In reality, the sort of metabolic slowdown described would, in the
real world, require constant medical monitoring, both human and
instrumental. As written in Classic Traveller, this is not the case; it's
like the High Passage in the Dumarest books, where a passenger who is awake
can engage in normal activities in a mostly-normal environment - just lots
slower. This "problem" is _not_ to be considered part of the discussion;
the intent here is that F is Dumarestian rather than realistic.

®Traveller is a registered trademark of
Mongoose Publishing, 1977-2024. Use of
the trademark in this notice and in the
referenced materials is not intended to
infringe or devalue the trademark.

--
Jeff Zeitlin, Editor
Freelance Traveller
    The Electronic Fan-Supported Traveller® Resource
xxxxxx@freelancetraveller.com
http://www.freelancetraveller.com

Freelance Traveller extends its thanks to the following
enterprises for hosting services:

onCloud/CyberWeb Enterprises (http://www.oncloud.io)