kwan3217
Addon Developer
Sorry I dropped out there for a moment. I was working on another project, which ultimately failed (see http://stkwans.blogspot.com/ for details)
Anyway, I am currently working on two projects, one just a simple weekend endeavor, and one my long-term plan to change the very nature of launch vehicles: VesselMass.
As I have mentioned before, the main purpose of VesselMass is to automatically and properly account for the center of mass and inertia tensor of all the parts of a spacecraft as they are dropped, as well as the center of mass and inertia tensor of the fuel as it is burned. This has mainly been accomplished.
The secondary purpose is to make it easy to drop vehicle parts. Dropping inert parts is done and works great. I am now working on dropping less-inert parts, with a focus on solid fuel motors continuing to burn through a stage drop. Think about the Space Shuttle, with its main propellant grain still smoldering through the drop and its booster separation motors firing just after separation.
One of the hard parts is identifying thrusters and propellant handles through a drop. Right now I am making the identification right at the drop, at the creation of the stage, by comparing PROPELLANT_HANDLE values, but this doesn't easily scale with depth of the VesselMass tree. It fails right now with PropMass parts, since they are actually still attached to their propellant resources on the original vehicle, which are emptied at separation.
So, I need to do this identification by some kind of name. I hate doing string comparisons, especially every frame. So, the name is just some unique ID number, with a named constant in the source code.
My other project is a Cowboy Bebop style hypergate. A hyperspace route consists of a gate pair to get from normal space to hyperspace at the start, combined with another pair to get from hyperspace to normal space at the destination. Four gates, plus a "TunnelSparkly" feature to generate the hyperspace tunnel.
You put the normal space gates in orbit around the start and destination worlds. Not on the ground, since even suggesting that after the Gate Disaster of 2021 will get you lynched. The hyperspace ends go in some distant corner of the solar system, far from the gravity of any planet.
The fun part of this is rendezvous and transit of the gate. In any normal rendezvous, you want to end up with a speed exactly matching the target station so that you can dock. With a hypergate, you can transit the gate at any speed you want as long as you are on a course that stays within 100m of the gate axis. With the gate properly oriented and a proper rendezvous, you can hit the gate at 100m/s and keep that speed through hyperspace and out the other end.
With this system, transit between any two worlds arbitrarily far apart requires DeltaV to launch from the surface to low orbit of the start world, a small amount of DeltaV to rendezvous and transit the gate, then however much DeltaV you need to deorbit and land at the target world, perhaps zero if that world has an atmosphere and you exit the gate right.
Anyway, I am currently working on two projects, one just a simple weekend endeavor, and one my long-term plan to change the very nature of launch vehicles: VesselMass.
As I have mentioned before, the main purpose of VesselMass is to automatically and properly account for the center of mass and inertia tensor of all the parts of a spacecraft as they are dropped, as well as the center of mass and inertia tensor of the fuel as it is burned. This has mainly been accomplished.
The secondary purpose is to make it easy to drop vehicle parts. Dropping inert parts is done and works great. I am now working on dropping less-inert parts, with a focus on solid fuel motors continuing to burn through a stage drop. Think about the Space Shuttle, with its main propellant grain still smoldering through the drop and its booster separation motors firing just after separation.
One of the hard parts is identifying thrusters and propellant handles through a drop. Right now I am making the identification right at the drop, at the creation of the stage, by comparing PROPELLANT_HANDLE values, but this doesn't easily scale with depth of the VesselMass tree. It fails right now with PropMass parts, since they are actually still attached to their propellant resources on the original vehicle, which are emptied at separation.
So, I need to do this identification by some kind of name. I hate doing string comparisons, especially every frame. So, the name is just some unique ID number, with a named constant in the source code.
My other project is a Cowboy Bebop style hypergate. A hyperspace route consists of a gate pair to get from normal space to hyperspace at the start, combined with another pair to get from hyperspace to normal space at the destination. Four gates, plus a "TunnelSparkly" feature to generate the hyperspace tunnel.
You put the normal space gates in orbit around the start and destination worlds. Not on the ground, since even suggesting that after the Gate Disaster of 2021 will get you lynched. The hyperspace ends go in some distant corner of the solar system, far from the gravity of any planet.
The fun part of this is rendezvous and transit of the gate. In any normal rendezvous, you want to end up with a speed exactly matching the target station so that you can dock. With a hypergate, you can transit the gate at any speed you want as long as you are on a course that stays within 100m of the gate axis. With the gate properly oriented and a proper rendezvous, you can hit the gate at 100m/s and keep that speed through hyperspace and out the other end.
With this system, transit between any two worlds arbitrarily far apart requires DeltaV to launch from the surface to low orbit of the start world, a small amount of DeltaV to rendezvous and transit the gate, then however much DeltaV you need to deorbit and land at the target world, perhaps zero if that world has an atmosphere and you exit the gate right.
