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

LBB2 M-Drives in LBB5: When does it help?

To wrap up my side of the argument:

In LBB2'77, the 10Pn fuel requirement (disregarding ship tonnage) was established at the same time as small craft fuel consumption also disregarded craft tonnage.

The 10Pn fuel requirement was linked to Pn=Gs but not Pn=Jn. Pn>Gs was only required to enable double-fire, and would only require Pn>Gs on ships of 200Td or smaller (larger than 200Td, each drive letter step was less than one performance value step).

Thus, it's reasonable to conclude that starship power plant fuel requirements were linked to -- if not entirely driven by -- maneuver fuel usage. In any case, they disregarded ship tonnage.

HG (both editions) declared maneuver fuel use to be negligible, and that the mandatory power plant fuel allocation sufficed for four weeks -- and set fuel use proportinal to ship tonnage as well as power plant rating. This did not modify LBB2'77 -- AFAICT, the only change HG made to LBB2 was that a Jump Governor became available as a separate hardware component. (Edit: Small craft became LBB5'81 designs.)

LBB2'81 added the Pn=Jn requirement, and declared that the "one trip" power plant allocation (that, unlike HG, still disregarded ship tonnage) was instead "enough for four weeks" -- perhaps two trips?

As I originally pointed out, this removed the symptom (undefined fuel consumption rates), but not the cause (fuel consumption rates that disregarded actual power plant output). I see this as a problem, but one that the authors accepted in order to maintain backwards compatibility.

The important thing as I see it (since I'm looking at this for meaning rather than absolute rulings), is that at the outset the 10Pn allocation was set based on a fuel consumption rate, even though that rate was implausibly decoupled from ship tonnage and/or power plant output, while also being obfuscated. I see this as justifying setting a minimum fuel allocation based on a fuel consumption rate and plausible mission duration, rather than an arbitrary quantity (admittedly a house rule, but one which I feel is consistent with the intent of the official rules).
Ever consider using the fuel use chart from Beltstrike?
Yes, but it still runs into the "the rules state that you must have Pn%/10Td per Pn" problem.
 
Last edited:
Yes, but it still runs into the "the rules state that you must have Pn%/10Td per Pn" problem.
Honestly I use the High Guard fix....

Or really I use the High Guard fix and apply it to the Maneuver Rating ( I assume Maneuver is some flavor of Fusion rocket and Grav). IMHO Power refueling is part of Annual Maintenance.

Considering all of the ship designs out there in publication that use slightly alternate design systems I don't feel I am too off base.
 
Honestly I use the High Guard fix....

Or really I use the High Guard fix and apply it to the Maneuver Rating ( I assume Maneuver is some flavor of Fusion rocket and Grav). IMHO Power refueling is part of Annual Maintenance.

Considering all of the ship designs out there in publication that use slightly alternate design systems I don't feel I am too off base.
I like it conceptually, but then I think about the game balance effects (in LBB2, power plant fuel is the only significant tonnage constraint on maneuver, and that only in the small-medium ACS size range) and hesitate. Maybe double-HG-fix (2%/Pn)?

My preference is to nibble around the edges with things like pro-rating the TCS power-down rule (it normally works in 1-month increments, but I think it should also work in 1-week increments) and intentionally cutting fuel endurance margins close (4 weeks is 'required', while typically only 9 days worth gets used), rather than simply chopping the requirement outright. The way I see it, rules that make sense should be kept; rules that don't, deserve the full munchkin treatment but not necessarily complete elimination. And canon should be respected to the extent practical.

For example, the Type S has an implausibly large fuel tank by HG or Beltstrike standards. This issue could be used to justify cutting the fuel tankage down to 30Td or less, freeing up 10Td or more for cargo or whatever. IMTU it's to allow a third parsec of range (as a J1 after a normal J2 or vice versa) if the power plant is throttled back to Pn-1 for the whole trip except for the week of the J-2 itself, by exploiting (pro-rating) the TCS power-down rule.

Edit to add: The third parsec range isn't normally used; instead, it's kept as a reserve for self-recovery from a misjump. And the ability to self-recover from a misjump allows jump attempts from the 10D-100D zone with good survival odds (under LBB2) to escape combat (with low survival odds against almost any other ship).
 
Last edited:
I like it conceptually, but then I think about the game balance effects (in LBB2, power plant fuel is the only significant tonnage constraint on maneuver, and that only in the small-medium ACS size range) and hesitate. Maybe double-HG-fix (2%/Pn)?

Actually I would go with the 288 turn max thrust for the base 1% thus additional thrust would be added by additional tonnage devoted to maneuver endurance. Thus making larger tanks much more common.
 
Actually I would go with the 288 turn max thrust for the base 1% thus additional thrust would be added by additional tonnage devoted to maneuver endurance. Thus making larger tanks much more common.
It feels kind of weird for me to mention this, since I've been on a LBB2'77 kick for the last couple of pages of this thread...

This drifts away from the late-CT paradigm of the maneuver drive only requiring a token amount of power, and no fuel at all. Which isn't necessarily a problem, of course -- just an observation. I like the idea, it moves the maneuver drive back into the heplar zone from whence it came.
 
It feels kind of weird for me to mention this, since I've been on a LBB2'77 kick for the last couple of pages of this thread...

Honestly I like the 77 paradigm drives wise as Power and Maneuver are a unit thus fuel use is nebulous as to whether it's for power or thrust. And my choice for the High Guard fuel use decision is based on High Guard79.

I was mining High Guard80 for stuff for Book2, but High Guard79 is a better fit in a lot of ways.

This drifts away from the late-CT paradigm of the maneuver drive only requiring a token amount of power, and no fuel at all. Which isn't necessarily a problem, of course -- just an observation. I like the idea, it moves the maneuver drive back into the heplar zone from whence it came.
Oh boy, I know that attraction.

A final note when designing I mostly work at TL12 (the Imperial average) or lower in that in games that is where most of the PC's live at. A lot of these discussion tend to be about the top end and that really isn't in the universe I run games in.
 
A final note when designing I mostly work at TL12 (the Imperial average) or lower in that in games that is where most of the PC's live at. A lot of these discussion tend to be about the top end and that really isn't in the universe I run games in.
Interesting .... :unsure:

I too find myself (nowadays) slewing away from the TL=15 (minimum) everything in order to create more of a Frontier/Not Max Tech Level "feel" in the starships that I design, giving them a broader range of localized logistics support options.

In LBB5.80 terms, there is a SERIOUSLY HARD BREAK between TL=12 and TL=13 in starship designs, simply because of the 3.0x vs 2.0x multiplier for Power Plants, which then has knock on effects for both tonnage and construction costs. TL=9-12 Power Plants under LBB5.80 are both huge AND expensive(!) when you reach for powerful drives!

In LBB2.81 terms, the formula of the relationship between standard drives for tech level and hull displacements creates some really interesting contours in design constraints, all of which "compact ships down" into smaller hull sizes for a given level of drive performance at specific tech levels.
  • TL=9 means drives A-D, which tops out at Code: 1 in 800 tons (D)
  • TL=10 means drives A-H, which tops out at Code: 1 in 1600 tons (H)
  • TL=11 means drives A-K, which tops out at Code: 1 in 2000 tons (K)
  • TL=12 means drives A-N, which tops out at Code: 1 in 2600 tons (N)
Since drive performance throughput is a straight up multiple (or divisor if you prefer), the only way to achieve higher drive performance is to put "big(ger) drives in small(er) hulls" ... which can make for an interesting balancing act vs the LBB5.80 alternative options.

Consequently, I find myself being drawn (these days) most strongly into the TL=10-12 bracket of starship design, which as far as drive performance goes has some really remarkable potentials going on in it ... kind of like how the 1950s and 1960s were sort of a golden era in aerospace engineering, where all sorts of designs that weren't possible before became possible and transformed everything (propulsion, metallurgy, configuration, speed, etc.). I'm therefore always looking at starship designs in this range of tech levels in terms of "how can I get the most performance at the lowest tech levels possible while still being economically viable?" under CT rules.
 
A final note when designing I mostly work at TL12 (the Imperial average) or lower in that in games that is where most of the PC's live at. A lot of these discussion tend to be about the top end and that really isn't in the universe I run games in.
Interesting .... :unsure:

I too find myself (nowadays) slewing away from the TL=15 (minimum) everything in order to create more of a Frontier/Not Max Tech Level "feel" in the starships that I design, giving them a broader range of localized logistics support options.
One of the things about Traveller (at least in the original conception) is that high tech items can be goals and rewards, above and beyond their monetary value -- like "magic items" in D&D. Spin, there, points out the monkey's paw aspect of this -- be careful what you wish for, because while that TL-15 suit of battle dress is pretty awesome, where are you going to find someone to repair it when it gets shot up, out here on the fringes?
 
My explanation is that the m-drive consists of a field generator - this is based on nul-grav tech invented at TL8 and makes the air/raft available. The field generator lowers the mass of anything within the field (hence it is volume rather than mass based) and can have an acceleration compensation field component added by the installation of additional machinery along with the grav plates that produce artificial gravity.
You then have the thrust component that consists of a fusion drive that does have a high energy exhaust (which gets larger as the ship gets bigger thus the weapon factor remains the same).
That field is, while not quite as technically savvy in expression, pretty much the TNE approach...

But the TNE field only lowers the gravitic mass (and thus weight), not the inertial mass. The opposite of Doc Smith's Inertialess. So, you still need 10 TT per G per megagram mass for acceleration, but can get offworld with as little as 0.0201 G of drive... and can get out of denser atmosphere drives off, as some exceed the 2%'s resulting weight.

Noting as well: current science has yet to find any disconnects between the inertial and gravitic mass in well done experiments.

TNE added a lot of Plotnium hypertechnobabble.
 
but can get offworld with as little as 0.0201 G of drive... and can get out of denser atmosphere drives off, as some exceed the 2%'s resulting weight.
This is where the CT formulation of requiring streamlining for atmospheric entry breaks down.

Since CT was originally written in the 1970s, the pinnacle of aerospace engineering at the time was the (reusable) NASA Space Shuttle. It relied on aerobraking (think about it) in order to wipe off enough orbital velocity to land conventionally (as a glider) on the planetary surface. Consequently, it required a streamlined hull.

You can see that kind of thinking assumption at work in LBB2.77 starship design and going forwards beyond that point. LBB5.80 diversified the hull configurations a little bit (giving us 9 instead of just 2), but the basic idea for planetfall remained the same with respect to atmospheres. The ONLY WAY to transition from orbital velocity to surface landing velocity ... was through use of aerobraking, which required streamlining the hull.

The problem with that underlying assumption is that is completely omits the thrust vectoring potential of Maneuver Drives.

If you've got a maneuver drive that can supply just as much thrust (if not MORE!) than what an aerobraking atmospheric entry maneuver can do ... and the "duration" of that maneuver drive thrust can EASILY exceed the duration needed for an orbit to surface transfer ... and it's not like you're consuming (chemical) propellants at ruinously fast rates ...

Once you've got gravitic control technology, "geosynchronous orbit" becomes ANYWHERE from a surface to the actual inertial geosynchronous orbit distance. With gravitic "thrust" vectoring, you can effectively "geosync" to the surface in "low orbit" and just descent VERTICALLY straight down to the surface at MUCH LOWER velocity relative to the atmosphere.



When the difference between orbital velocity in a vacuum versus the rotational velocity of the atmosphere you're going to be contacting is in the "Mach TWENTY+" range, you're going to need streamlining to survive that transition.

When the difference between orbital velocity in a vacuum versus the rotational velocity of the atmosphere you're going to be contacting is in the "Mach ZERO" range, you can be "a brick" (Close Structure configuration) and perform an atmospheric entry JUST FINE. It will presumably be a SLOWER maneuver (taking a longer duration) than the Streamlined option would, but if we're talking the difference between 10 minutes (streamlined aerobraking atmospheric entry) versus 60 minutes (not streamlined decelerate to geosync in orbit atmospheric descent entry) ... how much a deal breaker is that, really?



For the sake of consistency, I would (house) rule that Configurations: 7-9 (Dispersed Structure, Planetoid, Buffered Planetoid) are INCAPABLE of surface landings (or at least, can't be "landed safely ... intact"), although there's always the "one way impact" option, I suppose. Just don't expect your ship to remain undamaged in the aftermath by such a maneuver, since they're "just NOT built to PARK" at the bottom of any kind of gravity well.

Parking ORBIT? No problem.
Park on a SURFACE? 💥
 
For the sake of consistency, I would (house) rule that Configurations: 7-9 (Dispersed Structure, Planetoid, Buffered Planetoid) are INCAPABLE of surface landings (or at least, can't be "landed safely ... intact"), although there's always the "one way impact" option, I suppose. Just don't expect your ship to remain undamaged in the aftermath by such a maneuver, since they're "just NOT built to PARK" at the bottom of any kind of gravity well.

Parking ORBIT? No problem.
Park on a SURFACE? 💥

Any ship can be landed at least once, per RAW. ;)
 
This is where the CT formulation of requiring streamlining for atmospheric entry breaks down.

Since CT was originally written in the 1970s, the pinnacle of aerospace engineering at the time was the (reusable) NASA Space Shuttle. It relied on aerobraking (think about it) in order to wipe off enough orbital velocity to land conventionally (as a glider) on the planetary surface. Consequently, it required a streamlined hull.

You can see that kind of thinking assumption at work in LBB2.77 starship design and going forwards beyond that point. LBB5.80 diversified the hull configurations a little bit (giving us 9 instead of just 2), but the basic idea for planetfall remained the same with respect to atmospheres. The ONLY WAY to transition from orbital velocity to surface landing velocity ... was through use of aerobraking, which required streamlining the hull.

The problem with that underlying assumption is that is completely omits the thrust vectoring potential of Maneuver Drives.

If you've got a maneuver drive that can supply just as much thrust (if not MORE!) than what an aerobraking atmospheric entry maneuver can do ... and the "duration" of that maneuver drive thrust can EASILY exceed the duration needed for an orbit to surface transfer ... and it's not like you're consuming (chemical) propellants at ruinously fast rates ...

Once you've got gravitic control technology, "geosynchronous orbit" becomes ANYWHERE from a surface to the actual inertial geosynchronous orbit distance. With gravitic "thrust" vectoring, you can effectively "geosync" to the surface in "low orbit" and just descent VERTICALLY straight down to the surface at MUCH LOWER velocity relative to the atmosphere.



When the difference between orbital velocity in a vacuum versus the rotational velocity of the atmosphere you're going to be contacting is in the "Mach TWENTY+" range, you're going to need streamlining to survive that transition.

When the difference between orbital velocity in a vacuum versus the rotational velocity of the atmosphere you're going to be contacting is in the "Mach ZERO" range, you can be "a brick" (Close Structure configuration) and perform an atmospheric entry JUST FINE. It will presumably be a SLOWER maneuver (taking a longer duration) than the Streamlined option would, but if we're talking the difference between 10 minutes (streamlined aerobraking atmospheric entry) versus 60 minutes (not streamlined decelerate to geosync in orbit atmospheric descent entry) ... how much a deal breaker is that, really?



For the sake of consistency, I would (house) rule that Configurations: 7-9 (Dispersed Structure, Planetoid, Buffered Planetoid) are INCAPABLE of surface landings (or at least, can't be "landed safely ... intact"), although there's always the "one way impact" option, I suppose. Just don't expect your ship to remain undamaged in the aftermath by such a maneuver, since they're "just NOT built to PARK" at the bottom of any kind of gravity well.

Parking ORBIT? No problem.
Park on a SURFACE? 💥
Can’t exactly blast out of MosEisley that way.
 
Can’t exactly blast out of MosEisley that way.
True, and a good point.
This is where the CT formulation of requiring streamlining for atmospheric entry breaks down.

Since CT was originally written in the 1970s, the pinnacle of aerospace engineering at the time was the (reusable) NASA Space Shuttle. It relied on aerobraking (think about it) in order to wipe off enough orbital velocity to land conventionally (as a glider) on the planetary surface. Consequently, it required a streamlined hull.
And as I've noted previously, they completely failed to see the implications of the stated performance of the Air/raft. 1-10 hours to orbit (through an over-simplified but not blatantly implausible rule) with a non-streamlined vehicle. Even under '77 rules at 1G, the worst case of 12 hours to orbit is just 72 combat turns out of the at least 288 that the fuel allocation supports (yeah, double it to include EDL* on the other end of the trip, but at small-craft burn rates there'd still be 5.5 days of fuel left for the transit) On the other hand, getting off a Size 12 world with a 1G drive would require aerodynamic assistance (but there'd almost always be some atmosphere on a planet that size).

My point here is that even under the fuel-intensive '77 rules, a ship with no better aerodynamics than a '68 Dodge Dart convertible could make orbit and escape velocity from most worlds without using enough fuel to break suspension of disbelief, because an Air/raft could make orbit.

The conceptual problem, as Spin alludes to, is that "unstreamlined" wasn't the canon Happy Fun Ball (mercenary cruiser) that got de-streamlined by LBB5, it was Discovery from the movie 2001: A Space Odyssey.

---------------------
*Entry, Descent, and Landing
 
Last edited:
I’d say Discovery isn’t close but more open configuration.
What's the normal take off acceleration for a rocket to reach orbit?

Three gees at ten minutes?
Mercury astronauts went up to 7g, want to say they backed off and were more 4G for Apollo and the shuttle.
 
Last edited:
The way I see it, an air/raft and the manoeuvre drive manipulate gravity differently.

The air/raft floats and falls towards the directed direction, so floating upwards is likely going to take longer.

The rockets and manoeuvre drive have a focussed thrust, so would get to orbit faster.

Time would depend on how many gees are expended, and I would think you'd aim for getting there within twenty minutes.
 
The way I see it, an air/raft and the manoeuvre drive manipulate gravity differently.

The air/raft floats and falls towards the directed direction, so floating upwards is likely going to take longer.

The rockets and manoeuvre drive have a focussed thrust, so would get to orbit faster.

Time would depend on how many gees are expended, and I would think you'd aim for getting there within twenty minutes.
The maneuver drive provides as a minimum, 1G in any direction (based on its rating).

An Air/raft neutralizes its own weight and has 0.1G acceleration (regardless of local gravity*).


-------------------
*Reasoning:
LBB3'81 says it has a maximum speed of 100 kph, bursts to 120kph, affected by wind, but not adjusted for local gravity.
This means that lower gravity does not enable it to redirect additional thrust to either lateral movement or increased climb rate.

Striker's tables (design sequence tables, p.5) indicate that 120kph top speed corresponds to 0.1g thrust not committed to maintaining altitude.

I infer that this means that an Air/raft can hover "for free" and has 0.1G (1m/sec) that it can always apply in any direction (up or sideways, or even down -- though "down" means it can fall at up to 0.1G faster than local gravity).

Since LBB3'81 says an Air/raft can reach orbit, its top speed is not limited in a vacuum (or the near-vacuum of the upper reaches of atmosphere). It is, however, drag-limited while in the atmosphere.
 
Back
Top