Discussion LKS inspired shuttle concept.

Could the solids be used during ascent together with the other engines like oms assist of the sts? In this way the cutoff precision will be achieved by regular engines

Yeah, I was thinking something like the solid rockets are fired shortly before final orbital insertion by the OMS, allowing the shuttle to take advantage of the extra DV without as much penalty to precision.

Then you just have the aforementioned "setting off fireworks next to people" issue.
 
Then you just have the aforementioned "setting off fireworks next to people" issue.

For LES I can safely "overengineer" it's engines sacrificing efficency for safety (thicker SRB case). I don't mind small SRBs design as safety measure.

Urwumpe said:
Yes, but it means you need a higher propellant mass in the spaceplane, because you have to calculate with a higher dv budget for orbit insertion. Also, such things like a 4-orbit docking approach would be impossible then.

This shuttle has ~600m/s of dV - plenty for any reasonable LEO manuever.

fred18 said:
Could the solids be used during ascent together with the other engines like oms assist of the sts? In this way the cutoff precision will be achieved by regular engines

I need to investigate that codewise. It'd probaly act as 3rd booster to which payload (shuttle) would be attached.
 
I need to investigate that codewise. It'd probaly act as 3rd booster to which payload (shuttle) would be attached.

sorry if it was already said and I missed it: will the launcher be a dll developed vessel ?
 
sorry if it was already said and I missed it: will the launcher be a dll developed vessel ?

Yup. While I use multistage as dev tool, I still prefer my add-ons to be dll based. We (me and woo482) have some experience with rockets (Themis-A and HCLV) so it shouldn't be that hard for Woo to code LV itself.
 
Yup. While I use multistage as dev tool, I still prefer my add-ons to be dll based. We (me and woo482) have some experience with rockets (Themis-A and HCLV) so it shouldn't be that hard for Woo to code LV itself.

You mentioned that you intend to make it XR level of complexity. Are you going to model the shuttle's operations/coding off of the XR vessels?
 
Nope - I don't have access to XR codebase however I want to model electric systems, life support system, reentry heat modelling (with heatshield glow effects), custom autopilot suite (reentry, and docking) and full VC.

Launch vehicle will be controled via MFD like Themis or HCLV and probably there will be some improvements there.

That will take some time but I want this to be really top league add-on.
 
Nope - I don't have access to XR codebase however I want to model electric systems, life support system, reentry heat modelling (with heatshield glow effects), custom autopilot suite (reentry, and docking) and full VC.

Launch vehicle will be controled via MFD like Themis or HCLV and probably there will be some improvements there.

That will take some time but I want this to be really top league add-on.

Everything you're talking about definitely will make it top-league.

By the way, any ideas for what to call it?
 
Nope - I don't have access to XR codebase however I want to model electric systems, life support system, reentry heat modelling (with heatshield glow effects), custom autopilot suite (reentry, and docking) and full VC.

Launch vehicle will be controled via MFD like Themis or HCLV and probably there will be some improvements there.

That will take some time but I want this to be really top league add-on.

Will you also include DG-like features like an electrical power subsystem?
 
Will you also include DG-like features like an electrical power subsystem?

One thing I miss from the DG-IV when flying an XR vessel is the ability to control the electrical systems. Also the ability to shut off propellant flow to various systems. I always turn them off as a safety when they aren't needed.
 
One thing I miss from the DG-IV when flying an XR vessel is the ability to control the electrical systems. Also the ability to shut off propellant flow to various systems. I always turn them off as a safety when they aren't needed.

Yes. Practically, it makes sense that you usually won't touch anything about system management in a spacecraft after powering it up the first time after maintenance. The computer can do that better.

But in an emergency, you sure want to do that, also you know yourself better, which kind of power profile you need, so telling the computer that the spacecraft should now get powered down to "cold standby" or leave "cold standby" by an "emergency undocking" power-up sequence, would be pretty realistic.
 
Yes. Practically, it makes sense that you usually won't touch anything about system management in a spacecraft after powering it up the first time after maintenance. The computer can do that better.

But in an emergency, you sure want to do that, also you know yourself better, which kind of power profile you need, so telling the computer that the spacecraft should now get powered down to "cold standby" or leave "cold standby" by an "emergency undocking" power-up sequence, would be pretty realistic.

Exactly. Also it's good to be able to completely power down the spacecraft for ‎long-term storage. I think if you're running a space shuttle program you'll want at least two orbiters (preferably at least three, if not more, two or more to alternate missions to decrease potential downtime, and a third to act as a backup/rescue vehicle in case of emergency), which means ‎keeping some in hangars/storage, and it adds to the realism and immersion to have power-down and power-up sequences.
 
Exactly. Also it's good to be able to completely power down the spacecraft for ‎long-term storage. I think if you're running a space shuttle program you'll want at least two orbiters (preferably at least three, if not more, two or more to alternate missions to decrease potential downtime, and a third to act as a backup/rescue vehicle in case of emergency), which means ‎keeping some in hangars/storage, and it adds to the realism and immersion to have power-down and power-up sequences.

Yes. Also during cruise, you can power down a lot of the propulsion and navigation systems. Also, a lot of the configuration, you will likely only do once before a mission and then keep your hands of it.

For the "Aribace" SysML project, I for example have a lot of power changes, because the spacecraft has quite a few configuration changes during its mission, and it simply makes no sense to have all systems powered up at the same time. But that's also a bit bigger than that one in its dimensions.
 
Will you also include DG-like features like an electrical power subsystem?

Yup - battery, fuel cells and generator tied to APU
 
I am not sure how Dream Chaser would have been able to use the same engines for abort and as an orbital maneuvering system, that's a very deep throttle range.

The big engines of CST-100 (Starliner) will only be used for abort. The Superdracos of Dragon V2 will only be used for abort and propulsive landing; the minimum throttle percentage is 20%.

My Reusable Crew Vehicle add-on was supposed to do the same thing as what Dream Chaser would do (abort functionality hadn't been put in the add-on, but in-universe it's supposed to be there). The thrust in orbit was set to be 5% of a 6-g abort. I should have had on-orbit operations only use RCS thrusters, but then people might have been confused as to why the bigger engines weren't functional.
It would have been realistic to show only two of the six main engines firing in orbit: 33% of 20% of 6-g is 0.4-g (or 0.5-g for 8-g), which would be good for urgent burns (such as decelerating relative to an object during rendezvous), but then I would have the same issue. I was actually planning to have that in my release as well.
 
Last edited:
Back
Top