Patron Zero
SOC-13
Oh I fully agree, hence my remark about not being the same object, perhaps I should have amended such to include the word, intact.
Technical Liftoff Question
- Thread starter kilemall
- Start date
Oh I fully agree, hence my remark about not being the same object, perhaps I should have amended such to include the word, intact.
esampson
SOC-13
I talked about this in an earlier post. Actually, as long as you are capable of sustained burn and the vehicle has slightly more power than it needs to sustain level flight then you can fly to orbit. If a vehicle is capable of maintaining flight at speed X when atmospheric pressure equals Y then it is just as able to maintain flight at speed 4X when pressure equals 1/2 Y. It will produce the same lift, drag, and heating in either case.
There's some little fiddle bits in there where drag will temporarily increase in a way that doesn't follow the simple formulas and while you produce the same thermal energy you won't dissipate it quite as quickly but unless you're in a situation where you're pretty close to your limits in the first example (flying at speed X when pressure equals Y) you're going to be good to go.
http://www.travellerrpg.com/CotI/Discuss/showthread.php?t=14689&page=2#15
I need to get back to working on this. I've been stalled working out the proper way to control the ship via lifters and I got distracted by another project I'm working on. However the current model has been more than accurate enough for me to examine a ton of things concerning the various methods of take off (with lifters/without lifters/aerodynamic ascent because of low thrust) and landing (controlled vertical descent without heating/traditional re-entry).
Pretty much concurs with my experience. For vehicles with a thrust to weight ratio less then one and using lifting surfaces there is a tricky part in the upper atmosphere where you have to fly the profile just right to get a sub-orbital ballistic arc. Otherwise you will just stall as you try to climb. But I found it like flying a rocket manually just a matter of figuring the pitch program and paying attention to the clock.
http://www.travellerrpg.com/CotI/Discuss/showthread.php?t=14689&page=2#15
That would be cool to see. I just used the PB/X flyer model and jacked up the ISP so that the on-board fuel will last for weeks. Then played around with thrust to get 1-G, 2-G, etc acceleration.
Hmmm, I don't run into that much as I'm using RTT Worldgen not standard Traveller nor the OTU and RTT has most of the non-Terran rocks with low starports pump up TL to survival levels (except for Long Night scenarios).
As costly as it would be to support such a service without the tech base, it's still a magnitude of order cheaper then small craft.
esampson
SOC-13
The only real difficulty can be that if your ascent is too rapid then the atmosphere thins out too quickly. Your engine doesn't have time to accelerate you to the new required speed and you start to stall out. Try flying an XR2 with maxed out ISP and don't use the scram jets. When you get to about 50 km fly more or less straight until you begin to heat up and then regulate your temperature by pitching up slightly. Assuming you keep your temperature up but in the safe zone you will find that you continue to slowly gain altitude and velocity without any stalling problems at all until you pass the Karman line and break orbit.
That was how I started testing a lot of my theories but I found that I just had to rewrite certain routines to produce more genuine 'Traveller' results. Lifters aren't just the hover engine firing downward (although in that clip they may sound like it) with a given amount of force. It's actually a force that is vectored directly against gravity regardless of the orientation of the ship. The only problem I have with it is that it only just matches gravity in a straight down direction while lifters clearly have the ability to overcome gravity (allowing them to take off straight up) and vector the gravity (allowing them to move forward). While I've got the math all worked out (a lifter is capable of altering the vector of up to about 60% of the gravity acting on the body, meaning it can vector the full 60% up and accelerate at about 2 m/s since the 60% has to overcome the remaining 40% giving you and upwards acceleration of 20% gravity) I've been trying to work out a control system that wouldn't be overly difficult.
I've also been able to make the main drives actually work like Traveller drives in the sense that the force the exert is based upon the mass of the ship. If something were to happen to significantly lower the mass the thrust would likewise automatically be lowered.
Incidentally, the 'true' aerodynamics of the scout ship are horrible. I always thought it would be possible to fly it in an atmosphere using the body as a lifting wing by angling it in flight, but it turns out not really. Even with the addition of some stabilizers it just isn't flyable without aerodynamics that have nothing to do with its shape or lifters.
That reminded that I did some small amount of coding. Basically my idea was similar that if you could control gravity, you could do what you said above, have an engine or lifter pointed against the local gravity vector and negate it. Then your use m-drive to establish a thrust vector.
The reason I did that was I was playing around with turning it off and on. For example if you are approaching a planet with it on then all travel is in straight lines. However if you wanted to curve around the planet, you get your initial velocity going in the right direction (usually tangent to the lowest altitude you want to be at) then turn off the lifter and let the local gravity turn your path into a curve. Using gravity to give you some free thrust beyond what your m-drive can provide.
By turning the lifter on and off at various times you can do some interesting maneuvers in near orbit.
If you code up your craft using the API in a C++ dll then you can add a custom thruster. The API will give you a handle that you can store. You then use the handle to access the other API functions that allow you to point the thruster in the direction you computed.
I do this in order to properly simulate the different attitude control modes of the Mercury and Gemini spacecraft. Constant Rate, Pulse*, etc.
Interesting I didn't get that far and aerodynamics is not my strong point. Simulating Ship Systems and Operations is where was I was good at. All I will say that Gravitics cures all ills when it comes to performance and aerodynamics. It not totally a free lunch and certainly not point and shoot especially at low-G. But compared to flying a Gemini or even a Delta Flyer it is a true hot-rod.
=====================================
For those who are interested here is the deal with attitude and transition controls.
Most people think of thrust control as something you turn on for so long, and then turn off after which you are rotating or in the case of translating moving at some rate of speed.
Well with electronics (and computers) you are not limited to that. There are several control modes that were used historically that made orienting and translating a spacecraft a lot easier for a pilot.
First all this relates to how the thrusters respond to the joysticks. There is typically one joystick for attitude control (roll, pitch, and yaw) and another for translation (Fore and aft, left and right, up and down).
One is direct, the further you push your joystick out the more thrust you put out. The thruster will keep operating for as long as the joystick it extended. This is what most people think happens.
The second is rate control. The joystick is extended and amount of extension determines the RATE at which the craft rotates or move. The rate at maximum extension is designed into the system. For example 10 degress/ second or 1 m/sec. The Mercury Spacecraft had this mode. When you release the joystick it goes back to center and the craft will deceleration to zero velocity. This mode was used only for attitude control in Mercury, Gemini, and Apollo.
A third is pulse control. The joystick is extended and when it reaches a breakaway point, the thruster will fire a short pulse (like 1 second). The craft will continue to translate or rotate after the joystick is centered. Controlling your speed of translation or rotation mean pushing the joystick out then in X times. Then when you want to stop doing the same thing X times in the reserve direction. This was used for attitude and translation control on the Gemini. Of the modes discussed so far this was my favorite and allow for very precise control over your speed when docking or maneuvering.
There are others more specialized modes for example keeping the craft level with the horizon. In the Mercury spacecraft this was done through relay logic tied to gyroscopes on the Gemini and Apollo through an on-board computer monitoring a gyroscope.
If you heard the phrase Gimble lock (for example in Apollo 13 movie) it because the craft uses a 3 axis gyroscope. There is are two orientation that will cause the mechanics for two axis to line up which will have the bad of effect of causing the gyroscope to lose it zero reference point among other things. This can be fixed by adding a fourth axis slaved 90 degrees to the innermost axis.
The Mercury spacecraft had a three axis gyroscope so was prone to gimble lock.
The Gemini spacecraft had a four axis gyroscope and didn't have the issue.
But Apollo also had a three axis gyroscope. This was a result of the fact that the Gemini and Apollo were developed independently.
Not really. The Air/Raft costs MCr0.6
A shuttle costs MCr 33.
The Air/raft carries 1 Td of cargo, limited to 4 tonnes, plus 3 passengers. Requires a pilot, probably paid KCr2/month.
A shuttle carries a crew of 2, carries 71Td cargo (710 nominal tonnes limit, per TNE), and requires a total salary of 4200/mo.
Cargo Shuttle:
Cost per month per ton capacity: 137500 payment, 4200/mo salaries 15000/mo in fuel. 156700 total. Per cargo ton
Mixed Cargo:
Assuming 1 Td per 3 passeners as a ratio, that's 2.5 Td chunks.
28 passenger seats adds MCr1.4 to the cost. 1 additional crew seat adds MCr0.05. (56 Td cargo)
143542 payment, 6200/mo (adding a steward), 15000/mo in fuel. 164742 per month, or, assuming passengers charged at same rate as a ton of cargo... 84.5 cost units... Cr1949 per cost unit per month.
Air Raft 3.4 cost units (3 pass, 0.4 Td due to mass limit) Cr600,000
2500 payment, 1000 fuel, 2000 salary, for about Cr5500 per month. Cr1618 per cost unit.
Note that the shuttle can get to/from high orbit in about Size/4 hours
The air/raft can only make low orbit, and does that in Size hours.
So, the shuttle can make 4x the trips.
Making the effective cost about Cr 500 per unit per month.
Assuming a 20 day work month... we get Cr25 per Td or passenger for the shuttle, and Cr80 per passenger or Cr 32 for the cargo space.
I suppose it's too late to mention I had in mind a G Carrier minimum, more typically a Grav Truck (4 Passengers, 10 ton contaner cargo lift) rather then the air/raft, which is effectively an open topped combo of a Beech 15X and a Jeep.
I also had in mind the maintenance costs, which certainly are much larger, especially if we are talking tech base issues.
I also had in mind the maintenance costs, which certainly are much larger, especially if we are talking tech base issues.
Condottiere
SOC-14 5K
A luxury liner may have a chauffeured Ferrari Bentley anti gravity vehicle(s) to directly pick up and send down VIPs. Fast and comfortably.
esampson
SOC-13
It's not a coding issue. It's a UI issue. If I have one level that controls absolute lift (regardless of the orientation of the craft) how does that relate to a separate control for pushing the ship 'forward'.
Let's assume I have 2 levers. The left one handles absolute lift and at 50% a ship is 'hovering'. As I use the right one to provide thrust what effect does that have on absolute lift? What happens if I am nose down, and crank both levers to 100%?
Well the point of the lifter is to negate the local gravity vector right? You don't need manual control just sensors and the logic to compute it and the mechanism to orient the lifter in the right direction. Then the rest of the controls are as normal.
There are six degree of freedom controls out there if you want to attempt manual control. They have six axis where normal joystick has three. I have one myself that I use as a translation controller. I set it up to ignore the rotation axises since they are on my normal joystick. But I could tie them into another set of thrusters that rotates independently of the attitude thruster tied to the first joystick.
I suppose then learning it would be like learning the extra controls a helicopter has.
But at the level of technology we are talking about why not have the lifter be automatic?
The maintenance costs are proportional to the payments.
Round Trips: roughly 1 a day for grav, 4 a day for shuttle, 20 days per month, 13 months. (Smaller worlds, both go up proportionatly, larger, down proportionally.)
running the numbers for the G-Carrier:
MCr8
Payment: 33333.3
Salary: 2000
Fuel: 1000
Units: 13.2 (13 pass, 2 tonnes cargo) Or, stripped of passengers, 5.25 units.
Monthly: 36333.3
Trips/mo: 20
Maint: MCr0.8/year, 260 round trips Cr0.233/unit (Cr0.586 for cargo mode)
Sum per unit. Cr13.6 per unit round trip in mixed mode (limit 0.2 Td)
Shuttle, Cargo, 2070100 per year, 1040 trips, 71 units each Cr28 each Td
Shuttle, mixed. MCr2.1 per annum, 1040 trips, 84.5 units each, Cr24.46 each Td or Passenger
GCarrier: 83133.3 per annum, 260 trips, 13.2 units/trip, Cr24.42 each
GCarrier, Cargo Mode: 83133.3, 260 trips, 5.2 units/trip, Cr61.49 each unit
Air/Raft: 72300 per annum, 260 trips, 3.2 units/trip, Cr86.90 each unit.
G-carrier is, like the air/raft, limited to low orbits, while the shuttle isn't. And it's in the same price range, and is MUCH more expensive to operate as a cargo carrier.
Isn't this analysis falling into the same trap as the original STS cost per ton to orbit analysis ... you are assuming a high level of demand that will make the craft the limiting factor.
What happens if the TL 7 Class E starport sees only 1 Free Trader per week? Per Month? Then the overhead of the large, expensive, capable shuttle as it sits idle becomes a crushing burden on the starport budget.
The same issue impacts 2000 dTon freighters ... they are more profitable IF YOU CAN FILL THE HOLD and keep them running.
[but those IFs tend to get overlooked.]
The equally as versatile, but less costly launch is under twice the cost of the G-Carrier, has 13 Td of space; if we go with 3 pass per 1Td, for mixed, it's 15 pass, and 5.5 Td, for 20 units and MCr14.75.
MCr14 means cost per annum of 863,333.333, with 13units and 1060 trips. Cr62.651/unit
Mixed MCr14.75 is 904733.333/annum with 20 units and 1060 trips, Cr42.675 per unit.
Yeah, more expensive. But the number of places where the demand is low enough and the tech high enough to support even G-Carriers instead of shuttles, the launch has additional uses in deep space rescue; the G-carrier cannot exceed 10-diameters with thrust at all. And, for cargo instead of passengers, it's similar cost, and far better capability.
It's in IMOTrade and IMOJ's interests to facilitate the launch instead of the G-Carrier, simply for the rescue potential.
Further, it's canonical that any world within J2 of an X-boat route gets at least a single Type S per week for the X-mail run. (Rules for sending and receiving are in CT's TTA and S12.)
Oh, and E-ports have enough traffic to allow for finding a broker-1... and at least one lot of cargo. So... they're quite likely big enough to justify a small craft of some size.
The launch, if not busy, can be used for asteroid prospecting; the G-Carrier cannot. The launch be used for rescue missions, the G-carrier takes a lot longer and often cannot match vectors. The launch can be used for interdict, the G-carrier cannot. The Launch can mount a ship-combat capable laser, the G-carrier cannot. The launch is, practically, as good in combat as the Type S... and odds are good that, at an E port, the "scout X-mail station" is itself a Type S grounded until the next one comes in.
If the E-port lacks enough cargo flow to justify a launch, then the Air/raft of the local scout is the most likely option.
esampson
SOC-13
Automatic isn't the question. It's an issue of what 'automatic' means. Think of it in terms of an air/raft (that's where I realized I had an issue, because I was thinking of making an air/raft that could be launched/landed in the ship). What's a simple control system (that works with Orbiter) that lets you hover, accelerate forward, vertically ascend and descend, and brake, and what happens if you point the nose down, tell it you want to ascend, and then throttle forward?
Yes, the computer can automatically handle the lifters to do what you are telling it you want, but what exactly are you telling it? If I want to fly forward, but nose angled down 30 degrees should I increase vertical lift and then have it fight with the thrust? If I decide that at 50% lift I always want to remain at the same level then to go down I have to move the lever rather than just nosing down, which seems a little counter intuitive.
Er, Aramis, my LBB3 equipment guide says the GCarrier is 1 MCr, 8x cheaper then you have it listed.
For 8 MCr I would expect a souped up GTruck with the aformentioned passenger capacity of 4-6 and a cargo capacity of 10 tons that runs at the speed of the GSpeeder (1 hour to orbit and back).
For 8 MCr I would expect a souped up GTruck with the aformentioned passenger capacity of 4-6 and a cargo capacity of 10 tons that runs at the speed of the GSpeeder (1 hour to orbit and back).
mike wightman
SOC-14 10K
The price of grav vehicles in CT is a mess - in LBB4 there was errata that they should all be reduced by a factor of 10, or greater depending on TL, this errata was never included in any subsequent edition.
To be more precise, the cost of some grav vehicles was adjusted in later versions, but the TL dependent cost reduction went missing in action.
To be more precise, the cost of some grav vehicles was adjusted in later versions, but the TL dependent cost reduction went missing in action.
Last edited:
There is a device called a control moment gryoscope. It is basically a "box" that sits at a certain location on a spacecraft and allows to it to rotate in one axis without thrust by using a momentum of a gyroscope electrically spun up.
What I would propose that there is a device on grav vehicles in a similar form but devoted to nullifying the local gravity vector. It sits on or near the center of mass and regardless of the orientation of the vehicle it will discover the direction of the local gravity vector and apply a contra grav field in that direction to cut off its effects.
So you have a air/raft that is equipped with this. You get it and you turn on the counter gravity. The air/raft won't move but instead of resting on it's support it is now floating.
To fly the thrusters are engage, a set of linear thrusters and a set of rotational thrusters. This is done with the normal two joystick setup with a attitude control and a translation control.
But suppose this counter gravity device is too magical that gravitics is limited to just reactionless thrusters and grav plates.
Well you still can get by with just a attitude joystick and a linear translation joystick. You going to have to a data display showing your velocity in various orientation. But by applying the right amount of thrust using the linear control you can fly in any orientation.
Now I never tried this in terms of simulating a traveller vessel but I have flow the Deltaflyer like a helicopter and got a ton of practice doing in plane and out of plane fly arounds of the agena with the Gemini Spacecraft. The main problem with Orbiter is that most people don't have a second joystick
What I did was use a 3DConnexion and setup it up to control the translation axis of the gemini.
http://accessories.us.dell.com/sna/...79&acd=12309152537461010&ven1=sE1inYhPj&ven2=,
esampson
SOC-13
I thought of using lifters to just neutralize gravity. In fact, that's actually what I'm doing now. It's just that after playing around with that for a bit I've come to the realization that lifters do more than that.
The biggest thing is that your assumption is that your vehicle has some sort of thruster to propel the vehicle. This doesn't appear to be the case with the air/raft so I had to work on the assumption that the lifter doesn't simply negate gravity, rather it alters the direction of a substantial portion of it. By altering the vector the vehicle is able to move forwards or backwards.
Additionally air/rafts seem capable of lifting straight up. If all a lifter did was negate gravity then an air/raft would require some sort of additional thrust just to get off the ground. This is also really important because it means that a descending vehicle can 'brake' (instead of just using air resistance to slow down, which will not slow the vehicle much when the speed drop to about 15 kph).
So with that in mind I need to figure out a control system that is relatively intuitive to use. What I'm currently thinking of is a pair of levers with one lever controlling the absolute vertical component. In the middle it converts just enough of the gravitational vector to keep the vehicle effectively weightless. The other lever governs the use of the 'residual vector', directing an amount of it forward or backwards depending on the how far the lever is pushed forward or back. If the first lever is pushed all the way up there is no 'residual vector' and second lever doesn't effectively do anything.
There is a strong 'automatic' component to all of this. As more 'residual vector' is used for thrust the amount of gravity affecting the ship decreases, so the angle of the vector has to increase so that the 'upward' force remains in balance, even though the first lever has not been moved.
The biggest thing is that your assumption is that your vehicle has some sort of thruster to propel the vehicle. This doesn't appear to be the case with the air/raft so I had to work on the assumption that the lifter doesn't simply negate gravity, rather it alters the direction of a substantial portion of it. By altering the vector the vehicle is able to move forwards or backwards.
Additionally air/rafts seem capable of lifting straight up. If all a lifter did was negate gravity then an air/raft would require some sort of additional thrust just to get off the ground. This is also really important because it means that a descending vehicle can 'brake' (instead of just using air resistance to slow down, which will not slow the vehicle much when the speed drop to about 15 kph).
So with that in mind I need to figure out a control system that is relatively intuitive to use. What I'm currently thinking of is a pair of levers with one lever controlling the absolute vertical component. In the middle it converts just enough of the gravitational vector to keep the vehicle effectively weightless. The other lever governs the use of the 'residual vector', directing an amount of it forward or backwards depending on the how far the lever is pushed forward or back. If the first lever is pushed all the way up there is no 'residual vector' and second lever doesn't effectively do anything.
There is a strong 'automatic' component to all of this. As more 'residual vector' is used for thrust the amount of gravity affecting the ship decreases, so the angle of the vector has to increase so that the 'upward' force remains in balance, even though the first lever has not been moved.
Last edited:
Just to get the point home, that's 61.49/8, for a per unit cost of 7.69 each unit.
Gcarriers ARE the LEO interface economy kings. My postulated Gtrucks for 5-ton and 10-ton containers could cost 30% more and still be half as much as small craft.
