kwan3217
Addon Developer
A few more words about VesselMass.
1) It is not an MFD, a DLL, a library, or anything like that. It is a couple of C++ files you include in your project when you make your own vessel
2) Q: Why am I attaching airfoils, thrusters, and prop resources to your objects instead of directly to the vessel?
A: So that when you detach a stage, there is enough information to reconstruct the stage as an independent vessel.
Take for instance a Space Shuttle SRB. It is one of the more complicated things to drop, since it has resudual propellant and eight booster separation motors. Solid fuel engines are odd in that when they burn out, they don't really burn out.
The Shuttle boosters are detached at roughly the point when the thrust from the boosters is no longer pulling their own weight. This is well before the booster actually burns out, as it is smoldering for minutes after drop, I think almost all the way to the water.
Also, from the shuttle ascent rocketcam videos I have seen, the booster sep motors fire slightly before the booster is cut free, so that the BSMs are actually running at full thrust when they are needed. Something like a half-second delay, and the BSMs are running for about 3 seconds.
So, when you build a rocket, you create a VesselMass object representing each dropped component, attach some MassElements to it to represent the actual masses, but then attach the propellant resources, thrusters, airfoils, meshes, and control surfaces to the VesselMass object for its reference when it is time to jettison. The VesselMass object then takes all that stuff and uses it to build a new vessel at the appropriate time.
In the SRB case, I expect VesselMass to know that there are 2.5 tons of propellant left, the main thruster is here, the BSMs are on and have been for 0.5 seconds, etc. and to create a new vessel with all these properties copied. The new vessel will be firing nine thrusters the right amount for the right time.
Here is what I am getting at about VesselMass accreting rather than being designed. You build a thruster using VESSEL::CreateThruster( ) then use VesselMass::Attach( ) to attach it. CreateThruster( ) attaches it to the vessel as a whole, but VesselMass::Attach( ) to tell the correct VesselMass component that this thruster is associated with it.
However, you use VesselMass::CreateAirfoil3( ) and pass it all the airfoil parameters. This function records all the airfoil properties in its own arrays, then calls VESSEL::CreateAirfoil3( ) itself to actually create the airfoil.
The reason for the difference is that there is a complete API to read and write any parameter of a thruster, but not for an airfoil. In the first case, it is easy to use VESSEL::GetThrusterXXX( ) or ::SetThrusterXXX( ) to do anything you want to a thruster. However, there is for airfoils only EditAirfoil( ). VesselMass has its own CreateAirfoil3 just to record all the airfoil parameters itself, since there is no equivalent VESSEL::GetAirfoilXXX( ) for most parameters. I could use a memory hack, but I prefer to use any legitimate API way first before doing that, for obvious reasons. For control surfaces, the situation is even worse, since there isn't even a VESSEL::EditControlSurface( ) at all.
So, should I be consistent and make a VesselMass::CreateThruster( ), ::CreatePropellantResource( ), etc for VesselMass, should I use some kind of ::Attach( ) for everything, or is a mixture like this OK? Should I have both VesselMass::CreateThruster( ) and ::Attach(THRUSTER_HANDLE)?
Side-mount HLV is coming along. Thanks for the meshes, Donamy!
Planned features for the cargo-only HLV are:
1) It is not an MFD, a DLL, a library, or anything like that. It is a couple of C++ files you include in your project when you make your own vessel
2) Q: Why am I attaching airfoils, thrusters, and prop resources to your objects instead of directly to the vessel?
A: So that when you detach a stage, there is enough information to reconstruct the stage as an independent vessel.
Take for instance a Space Shuttle SRB. It is one of the more complicated things to drop, since it has resudual propellant and eight booster separation motors. Solid fuel engines are odd in that when they burn out, they don't really burn out.
The Shuttle boosters are detached at roughly the point when the thrust from the boosters is no longer pulling their own weight. This is well before the booster actually burns out, as it is smoldering for minutes after drop, I think almost all the way to the water.
Also, from the shuttle ascent rocketcam videos I have seen, the booster sep motors fire slightly before the booster is cut free, so that the BSMs are actually running at full thrust when they are needed. Something like a half-second delay, and the BSMs are running for about 3 seconds.
So, when you build a rocket, you create a VesselMass object representing each dropped component, attach some MassElements to it to represent the actual masses, but then attach the propellant resources, thrusters, airfoils, meshes, and control surfaces to the VesselMass object for its reference when it is time to jettison. The VesselMass object then takes all that stuff and uses it to build a new vessel at the appropriate time.
In the SRB case, I expect VesselMass to know that there are 2.5 tons of propellant left, the main thruster is here, the BSMs are on and have been for 0.5 seconds, etc. and to create a new vessel with all these properties copied. The new vessel will be firing nine thrusters the right amount for the right time.
Here is what I am getting at about VesselMass accreting rather than being designed. You build a thruster using VESSEL::CreateThruster( ) then use VesselMass::Attach( ) to attach it. CreateThruster( ) attaches it to the vessel as a whole, but VesselMass::Attach( ) to tell the correct VesselMass component that this thruster is associated with it.
However, you use VesselMass::CreateAirfoil3( ) and pass it all the airfoil parameters. This function records all the airfoil properties in its own arrays, then calls VESSEL::CreateAirfoil3( ) itself to actually create the airfoil.
The reason for the difference is that there is a complete API to read and write any parameter of a thruster, but not for an airfoil. In the first case, it is easy to use VESSEL::GetThrusterXXX( ) or ::SetThrusterXXX( ) to do anything you want to a thruster. However, there is for airfoils only EditAirfoil( ). VesselMass has its own CreateAirfoil3 just to record all the airfoil parameters itself, since there is no equivalent VESSEL::GetAirfoilXXX( ) for most parameters. I could use a memory hack, but I prefer to use any legitimate API way first before doing that, for obvious reasons. For control surfaces, the situation is even worse, since there isn't even a VESSEL::EditControlSurface( ) at all.
So, should I be consistent and make a VesselMass::CreateThruster( ), ::CreatePropellantResource( ), etc for VesselMass, should I use some kind of ::Attach( ) for everything, or is a mixture like this OK? Should I have both VesselMass::CreateThruster( ) and ::Attach(THRUSTER_HANDLE)?
Side-mount HLV is coming along. Thanks for the meshes, Donamy!
Planned features for the cargo-only HLV are:
- Thrust Vector Control for steering
- VesselMass for proper center of mass, moment of inertia and staging
- Thrust curves for the SRBs
- Automatic thrust vectoring of SSMEs to compensate for off-axis and SRB thrust curve
- Autopilot for unmanned launch
- Flight-director HUD for automatic guidance but manual control
- No virtual cockpit for the unmanned version
- Standard Orbiter attachments for cargo. Cargo modules are first-class vessels themselves. Maybe even Vinka's if his system allows attachments.
