Project Multistage2015 - Development Thread

[fred18]

pseudocode:

int MyVessel::GetDockingPort(DOCKHANDLE hDock){
 for(UINT i=0;i<DockCount();i++){
    if(GetDockHandle(i)==hDock) return i;
 }
return -1;
}

int MyVessel::OtherVesselGetDockingPort(OBJHANDLE h_OtherVessel, DOCKHANDLE hDock){
VESSEL *otherVessel;
otherVessel=oapiGetVesselInterface(h_OtherVessel);
  for(UINT i=0; i<otherVessel->DockCount();i++){
    if(otherVessel->GetDockHandle(i)==hDock) return i;
  }
return -1;
}


int VESSEL::MyOapiDock(OBJHANDLE target, DOCKHANDLE myDock, DOCKHANDLE tgtDock, UINT mode){
return  Dock(target,GetDockingPort(myDock),otherVesselGetDockingPort(target,tgtDock,mode);
}

plus all the safety checks to be included.

The other difference is that moving an attachment point is easy and works, while moving docking port is difficult. So if I want to "move" stages or payloads to fine tune the setup of my rocket I can't do it.

This code above properly written actually works... but still I see other advantages in the attachments apis: the attachment is not automatic while docking is (if I understand it right), so it is much more controllable by the developer, it has also the id string that can be checked, it's really "stable" when deleting attachments (while I experience some CTDs when deleting docking ports), and as said point movement is easy and smooth with attachments so if I want to build a vehicle with various stages I can connect them and then slightly move the points at runtime to make the match perfect.

I think that is all. :tiphat:

---------- Post added 3rd Nov 2018 at 15:03 ---------- Previous post was 2nd Nov 2018 at 22:09 ----------

And I am experiencing this issue (deletion of multiple docking ports brings to CTD)

https://www.orbiter-forum.com/project.php?issueid=921

which is a show stopper for me. If I have 12 boosters to jettison at the same time I have to delete 12 docking ports at the same time and it must work to make this thing worth the effort

---------- Post added at 20:22 ---------- Previous post was at 15:03 ----------

Maybe a "stage attachment" type of connection is needed, which behaves exactly like a docking port, but has its own port numbers and deletes automatically if not attached to something (either at scenario start, as with a core with optional boosters that aren't attached, or if detached in flight, as with a staging sequence)?

I have to say that at first I thought this was crazy... but...

I made a test using a custom type of connection. Basically the system keeps all the vessels at the right place by updating the vesselstatus of each one and in the meantime it transfers to the main vessel the forces applied to the single vessels... what if I tell you that it works quite good? it could be a custom attachment/docking system which works as fine as I would like it to do....

 

[fred18]

Just a small update for those who are interested:
- I managed to get the Link system working very well. It is basically a mix of docking and attachments, since it has a parent child structure as attachments, but it transfers the forces (translational and rotational) from the child to the parents without having to modify the physics characteristics of any vessel. At the moment is thought for rockets so the PMI are simplified for cylinders elements
- I am thinking about making this linking system a plugin module with an exposed API so everyone will be able to use it which whatever vessel... I don't know if it feasible but why not
- There will be no more limitations in any number: infinite number of stages, boosters, engines etc
- Due to this new linking system many things can be simplified: first thing I did is the booster system: no more meshes turned, named with "_1" "_2" etc, but just one mesh for the booster vessel, and the booster vessel will be replicated N times. This allows to change the number of the boosters on a rocket by simply changing the N parameter without doing anything else. I am using as usual the demo SLS for the developing and I just changed N from 2 to 20 or to 5 and ZAP! boosters are there up and running.
- The rest of the tructure should be quite easy to make, I have some doubts with fairings: the system used for the boosters could come in handy, but often textures for one piece of fairing is different than the other, so just replicating a fairing vessel could produce a not perfect result.
- The idea in the end is also to rethink the developer mode, so it will be easy to change or move stages/boosters/payloads directly in the sim with just a few clicks. As said, I never played KSP but from what I saw this could become easily similar to the assembly part of it.

I have to hurry because in 3 weeks time my second daughter will be born and time for developing will be cut dramatically :lol:

keep you posted.

 

[4throck]

The booster system based on a single mesh will not be usable for all rockets.
Ex: Shuttle boosters, they are different visually

But it's a nice option to have!

For the fairings, it's the same.
On some cases a single "cloned" mesh will do, on others we need different fairing part meshes.

 

[jacquesmomo]

Just a small update for those who are interested:
I have to hurry because in 3 weeks time my second daughter will be born and time for developing will be cut dramatically :lol:

keep you posted.

I understand !!!! :thumbup:

 

[fred18]

I'm not sure that I follow your plan, but I wan to add one point regarding multiple attached vessel stacks: JUst make sure that the vessel that ends up in orit is the one that starts outon the pad.

IIRC, in old Velcro rockets, you launched from the bottom stage focus and ended up in the upper stage focus. This made it difficult for intrplanetary missions because it reset all the MFDs, and you had replan your IMFDs, etc.

Hi boogabooga, since I made some progress in the new multistage configuration I was wondering if you could give me some advice on this point which is very important:
1) I made it sure that the focus core-vessel is always the last stage of the rocket.
2) Even though from physics point of view it would be much more correct that payloads' masses are applied to payloads etc the only way to have a proper computation of deltaV of the last stage with payloads on in the various MFDs like TransX or IMFD is to modify the physics of the last stage adding the payloads masses to it
3) that brings burntime mfd for example to a proper deltaV computation in the configuration "last stage + payloads/adapters"

now my questions are:
1) is point 1 above enough for interplanetary planning on the ground? it seems so to me, since the deltaV and all the other datas to get to orbit are not relevant for this part, can you confirm this? Are there numerous examples of ejection burn planned from a non-last stage of the rocket? this could be a game changer...
2) is last stage+eventual adapter+payloads enough as long as masses to be correct for interplanetary ejection burn? my guess is that it should be: fairings are jettisoned far before the ejection, and I can't think of anything else that could be relevant in this case.

Thanks in advance for your time!

Fred

 

[boogabooga]

I'm not sure if I understand your questions ("as long as masses to be correct"?). But I think that if you understand the sequence better, it will help you. In IMFD, this is how it goes, and I think that TransX is similar:

On the ground you plan your interplanetary course. At this stage, you are neglecting the effects of earth's (and destination's) gravity and you only know an idealized eject velocity. It is almost as if the earth itself is your spacecraft.

IMFD hands this plan off to a surface launch program. It tells you when and in what direction to launch.

Once you are in a ballistic trajectory (preferably a parking orbit), IMFD uses both
your interplanetary course that you plotted on the ground and your exact trajectory information to calculate a precise ejection plan. This is the actual burn that the spacecraft performs to leave earth. As you probably know, if you assume infinite acceleration, the delta-V of the burn does not depend on your mass, etc. But, it does for finite acceleration. Depending on if you are using TransX, Burn Time Calc, or one or the other of the different modes for IMFD, you may be making use of the mass informtion or not.

So to sum up, you do your 'big-picture' planning on the ground, and precise burn planning once you get to space. The problem with Velcro is that you cannot communicate your 'big-picture' plan to your burn-planning routine because the spacecraft that you use for each is different.

Actually, now that you mention it, I think that there is a way to do a "direct-ascent" in IMFD from the ground all the way to escape in one step, but I forget how and I would need to look into it more. :hmm:

BTW, while you are updating multistage could you look into the G-limit code from last year. IIRC, you updated for Orbiter 2016 but not Orbiter 2010.

 

[fred18]

Thank you very much for your reply!

I'm not sure if I understand your questions ("as long as masses to be correct"?).

Yep that was not clear from my side. To give you the idea of what I am talking about: there are many ways to do approach multivessel structures. The one on which relies the old vinka (and ms2015) is to have a unique vessel with the physics characteristics (mass, PMI etc) of the assembled stack. This unique vessel then spawns the stages that he jettisons and at each structural change it updates its physicas characteristics as well. The other approach, which I am exploring now, is to have actually multiple vessels attached. This means that even if the focus vessel is always the same (the last stage of the rocket) its physics characteristics stored in orbiter will be the ones of only that vessel, without the rest of the stack. I also developed a particular way of connecting vessels which works similarly to docking. The fact that the focus vessels has its own characteristics that do not have into account the rest of the stack (for example the mass of payloads) is usually misleading for the MFDs like TransX,IMFD or Burntime, which for their burns planning just query the vessel to which they are attached to to get the physical parameters for planning and executing the burns. So the only way to have this working in the way that orbiter users can enjoy it is to have at least the last stage with the physical parameters (mass above all) of the final stack (so I'd say last stage with payloads and eventually any adapter) so when the user will be in parking orbit the MFD he is using will get usable physical parameters of the vessel and will be able to plan and execute the ejection burn correctly.

I was quite comfortable with IMFD sometimes ago, so the procedure you have explained very clearly was what I had in mind, and I think that this approach of having the last stage as always the focus vessel throughout the ascent and with the physics of the final stack could maintain usability of all the MFDs for interplanetary flights.

The only situation that comes to my mind in which this won't be enough is if the ejection burn is not done with the last stage of the rocket but with a previous one. But that was an issue even with the "classic" version of Multistage so it should be ok anyway. I think I will continue on this path and see if I can take it to the end.

Besides this I just tried to implement thrust vectoring and works really nice. That could be a nice option to add.

On the otherside I think I will take away some options that seems unuseful, like explosive bolts and ullage: it seems to me that they are almost never used and are overcomplicating the code in a crazy manner. I don't know about growing particles, if there is really the need of maintaining the option or not, I'll think about it.

BTW, while you are updating multistage could you look into the G-limit code from last year. IIRC, you updated for Orbiter 2016 but not Orbiter 2010.

I'm not sure about this, could be... too much time has gone by and I grew old in the meantime :lol: I'll give it a check. I think this eventual new version of multistage will be only for 2016 though.

 

[gattispilot]

So I am having an issue.

I Was using the same guidance, cfg for a spacecraft3 vessel and no issues. But I made a dll of it and now it doesn't get into orbit?

-30.000 =orbit(241,249,38.0,-1)
-6.0 =engine(0,100,6)
150.0 =inverse()
450 = Destroy()

[STAGE_1]
Height=46.88 
Diameter=8.7
EmptyMass=228878
FuelMass=735322
Thrust=1.33861e7
BurnTime=504.1
off=(-0.05,0,13.401)
MeshName="vstarghost"
eng_1=(-6.0,6,-25.85)
eng_2=(-3.98,6,-25.85)
eng_3=( -1.96,6,-25.85)
eng_4=(1.96,6,-25.85)
eng_5=(3.98,6,-25.85)
eng_6=( 6.0,6,-25.85)
eng_7=( 0,6,-25.85)
DIR=(0,0,-1)
eng_diameter=1.5
speed=(0,0,-10)
ENG_PSTREAM1=solidfuel_exhaust
ENG_PSTREAM2=contrail4
ENG_TEX=Exhaust_atsme
battery=1.5
Reignitable=0

[PAYLOAD_1]
MeshName="queststar"
off=(-0.00,8.13,0.0)
Diameter=23.1
Height=36.2
Mass=0.1
Module=QUESTSTAR
Name=Queststar
SPEED=(0,0.8,0)
Rot_Speed=(0.002,0,0)
RENDER=1
LIVE=1

the only change I made was module to queststar from spacecraft/spacecraft

SCN:

QueststarLaunch:Multistage2015
  STATUS Landed Earth
  POS -80.6209000 28.6261120
  HEADING 0.00
  ALT 15.500
  AROT 151.065 -8.240 4.530
  ATTACHED 0:0,MS_LaunchPad_QueststarLaunch
  AFCMODE 7
  PRPLEVEL 0:1.000000
  NAVFREQ 0 0 0 0
  XPDR 0
  CONFIG_FILE Config\Multistage2015\QueststarLaunch.ini
  GUIDANCE_FILE Config\Multistage2015\Guidance\guidance_shuttle_x-33.txt
  CONFIGURATION 0
  CURRENT_BOOSTER 1
  CURRENT_STAGE 1
  CURRENT_INTERSTAGE 1
  CURRENT_PAYLOAD 1
  FAIRING 0
  MET -90.000
  BATTERY 5400.000000
  STAGE_IGNITION_TIME 0.000000
  STAGE_STATE 1
  TELEMETRY_FILE Config\Multistage2015\Telemetry\guidance_shuttle_x-33.txt
  ALT_STEPS 100.0,350.0,1400.0,35000.0
  PEG_PITCH_LIMIT 35.000
  PEG_MC_INTERVAL 0.100
  RAMP 
END
MS_LaunchPad_QueststarLaunch:EmptyModule
  STATUS Landed Earth
  POS -80.6210270 28.6270830
  HEADING 0.00
  ALT 3.000
  AROT 151.047 -8.224 4.525
  ATTACHED 1:0,VSBASE
  AFCMODE 7
  NAVFREQ 0 0
END
queststar:QUESTSTAR
  STATUS Landed Earth
  POS -80.6209000 28.6261120
  HEADING 0.00
  ALT 0.000
  AROT 122.925 -30.193 18.493
  ATTACHED 0:0,QueststarLaunch
  AFCMODE 7
  PRPLEVEL 0:1.000000
  IDS 0:8 100
  NAVFREQ 0 0
  XPDR 0
  GEAR 0 0.0000
  DOOR 0 0.0000
  LIGHT 0
  HGA 0 0.0000
  SPEEDBRAKE  0.0000
  CHUTE 1 1.0000
END

log:

000000.000: Load State Started
000000.000: QueststarLaunch: Guidance File present: Config\Multistage2015\Guidance\guidance_shuttle_x-33.txt
000000.000: QueststarLaunch: Orbit Call Found! Targets: Apogee:249000.0 Perigee:241000.0 Inclination:38.0 Mode:-1.0 GT initial Pitch: 0.0 Abside:241000.0
000000.000: QueststarLaunch: Config File: C:\Orbiter2016\Config\Multistage2015\QueststarLaunch.ini
000000.000: QueststarLaunch: Number of stages in the ini file: 1
000000.000: QueststarLaunch: Number of boosters group in the ini file: 0
000000.000: QueststarLaunch: Number of Payloads in the ini file: 1
000000.000: QueststarLaunch: Thrust in Real Position
000000.000: QueststarLaunch: Texture n.1 Loaded Exhaust_atsme
000000.000: QueststarLaunch: Texture n.2 Loaded solidfuel_exhaust
000000.000: QueststarLaunch: Texture n.3 Loaded contrail4
000000.000: QueststarLaunch: Texture n.4 Loaded contrail
000000.000: QueststarLaunch: Texture n.5 Loaded contrailSRBA
000000.000: QueststarLaunch: Stage n. 1 Tank Added: 735322.000 kg
000000.000: QueststarLaunch: Stage n.1 Engine Exhaust Stream Added: solidfuel_exhaust to engine n.1
000000.000: QueststarLaunch: Stage n.1 Engine Exhaust Stream Added: contrail4 to engine n.1
000000.000: QueststarLaunch: Stage n. 1 Engines Exhaust Added--> number of engines: 7 , diameter: 1.500, position x: -6.000 y: 6.000 z: -25.850
000000.000: QueststarLaunch: Stage n.1 Engine Exhaust Stream Added: solidfuel_exhaust to engine n.2
000000.000: QueststarLaunch: Stage n.1 Engine Exhaust Stream Added: contrail4 to engine n.2
000000.000: QueststarLaunch: Stage n. 1 Engines Exhaust Added--> number of engines: 7 , diameter: 1.500, position x: -3.980 y: 6.000 z: -25.850
000000.000: QueststarLaunch: Stage n.1 Engine Exhaust Stream Added: solidfuel_exhaust to engine n.3
000000.000: QueststarLaunch: Stage n.1 Engine Exhaust Stream Added: contrail4 to engine n.3
000000.000: QueststarLaunch: Stage n. 1 Engines Exhaust Added--> number of engines: 7 , diameter: 1.500, position x: -1.960 y: 6.000 z: -25.850
000000.000: QueststarLaunch: Stage n.1 Engine Exhaust Stream Added: solidfuel_exhaust to engine n.4
000000.000: QueststarLaunch: Stage n.1 Engine Exhaust Stream Added: contrail4 to engine n.4
000000.000: QueststarLaunch: Stage n. 1 Engines Exhaust Added--> number of engines: 7 , diameter: 1.500, position x: 1.960 y: 6.000 z: -25.850
000000.000: QueststarLaunch: Stage n.1 Engine Exhaust Stream Added: solidfuel_exhaust to engine n.5
000000.000: QueststarLaunch: Stage n.1 Engine Exhaust Stream Added: contrail4 to engine n.5
000000.000: QueststarLaunch: Stage n. 1 Engines Exhaust Added--> number of engines: 7 , diameter: 1.500, position x: 3.980 y: 6.000 z: -25.850
000000.000: QueststarLaunch: Stage n.1 Engine Exhaust Stream Added: solidfuel_exhaust to engine n.6
000000.000: QueststarLaunch: Stage n.1 Engine Exhaust Stream Added: contrail4 to engine n.6
000000.000: QueststarLaunch: Stage n. 1 Engines Exhaust Added--> number of engines: 7 , diameter: 1.500, position x: 6.000 y: 6.000 z: -25.850
000000.000: QueststarLaunch: Stage n.1 Engine Exhaust Stream Added: solidfuel_exhaust to engine n.7
000000.000: QueststarLaunch: Stage n.1 Engine Exhaust Stream Added: contrail4 to engine n.7
000000.000: QueststarLaunch: Stage n. 1 Engines Exhaust Added--> number of engines: 7 , diameter: 1.500, position x: 0.000 y: 6.000 z: -25.850
000000.000: QueststarLaunch: Stage n.1 Mesh Preloaded: vstarghost
000000.000: QueststarLaunch: Stage n.1 Mesh Added Mesh: vstarghost @ x:-0.050 y:0.000 z:0.000
000000.000: Load State Terminated
000000.000: Module EmptyModule.dll ....... [Build 170626, API 160828]
000000.000: Module MS_Camera.dll ......... [Build 170626, API 160828]
000000.000: MS_Camera: Target Vessel Loaded->ET-1
000000.000: Module QUESTSTAR.dll ......... [Build 181114, API 160828]
000000.000: Module VSBASE.dll ............ [Build 181114, API 160828]
000000.000: Finished initialising status
000000.000: Finished initialising camera
000000.000: Finished setting up render state
000000.000: Post Creation Started
000000.000: QueststarLaunch: Gravity Turn Initial Pitch by user: 0.000 Calculated:88.100
000000.000: RESET PEG
000000.000: QueststarLaunch: Planet Reference Pressure = 101325.0 Pa  Atmosphere Altitude Limit:2500.0 km
000000.000: Post Creation Terminated
000000.000: Finished initialising panels
000037.146: Detached from Launchpad
000037.146: LaunchPad Deleted from Scenery
000038.060: QueststarLaunch Stage n: 1 ignited @0.2
000156.865: **** Closing simulation session

 

[fred18]

But I made a dll of it and now it doesn't get into orbit?

Perhaps the masses are defined differently between the ini and your dll?

 

[gattispilot]

Thanks
The mass of the queststar dll is:
SetEmptyMass(228878);
const double MAX_FUEL = 735322;
and the sc3 was:

EMPTY_MASS=228878
FUEL_MASS=735322

Besides that change we moved the launch site from Florida to Edwards.

She launches ok. But doesn't get into orbit

 

[fred18]

Thanks
The mass of the queststar dll is:
SetEmptyMass(228878);
const double MAX_FUEL = 735322;
and the sc3 was:

EMPTY_MASS=228878
FUEL_MASS=735322

Besides that change we moved the launch site from Florida to Edwards.

She launches ok. But doesn't get into orbit

from the manual I get:

If set to 1 creates a live
payload instead of a dead
mesh! If a payload is live
the mass parameter can
be avoided and the
vehicle will load the live
payload mass. If there is
the need of manual
overriding the live payload
mass value, just keep the
mass parameter

so if you keep the mass parameter you will override the payload mass. I don't know why it changes from SC3 to your dll, I surely have to check about those things, but it seems to me that you were launching a 0.1 kg payload and that was why it was flying to orbit fine.

 

[gattispilot]

Ok. So should I try changing the mass in the dll to .1

We are using ms2015 for the guidance part mainly so we have ghost mesh for the main rocket

 

[fred18]

Ok. So should I try changing the mass in the dll to .1

We are using ms2015 for the guidance part mainly so we have ghost mesh for the main rocket

I'd suggest to try to change and see if it works, but if it works for proper realism you then should get the mass back to its correct value and change the engine characteristics of your vehicle in order for it to be able to reach orbit.

 

[gattispilot]

I'd suggest to try to change and see if it works, but if it works for proper realism you then should get the mass back to its correct value and change the engine characteristics of your vehicle in order for it to be able to reach orbit.

I will try. But the ghost ship is what puts it into orbit. Once orbit is reached. it should destroy. And the ship can go about the rest of the flight.


So maybe up the thrust amount of the ghost ship?

 

[fred18]

I will try. But the ghost ship is what puts it into orbit. Once orbit is reached. it should destroy. And the ship can go about the rest of the flight.


So maybe up the thrust amount of the ghost ship?

yes, I mean I don't know the details, but for what I understand it should be the ghost ship's engine

 

[gattispilot]

Thanks. The ghost ship mass and thrust were the same:
EmptyMass=228878
FuelMass=735322
Thrust=1.33861e7

But I will see if changing the mass of the dll will effect it. Not sure if I can set a parameter to reset the mass on the main ship if in orbit and free of the ghostship.

 

[fred18]

Thanks. The ghost ship mass and thrust were the same:
EmptyMass=228878
FuelMass=735322
Thrust=1.33861e7

But I will see if changing the mass of the dll will effect it. Not sure if I can set a parameter to reset the mass on the main ship if in orbit and free of the ghostship.

That seems to me that the issue is that the mass parameter of payload if you use the dll version of your vessel is not overriding the mass, so you're bringing up twice the mass.

But in the meantime it also seems to me that something is not right: if your ghost rocket has the same mass of your vessel the fact that when everything works you're bringing up twice the mass is the correct calculus result, but I think the wrong assumption.

Here's how I would deal with this, that's just an idea, maybe not right...
I'd set the following:
- the ghost rocket empty mass very low, something like 1kg or around there
- the ghost rocket fuel the same as the fuel capacity of the vessel
- the vessel tank with the right capacity but completely empty

once the vessel is on orbit and the ghost rocket is detaching I would get the amount of fuel remaining on the rocket before it destroys itself and I would set the propellant level of the vessel to that amount. That would work and would be highly realistic in my opinion

 

[gattispilot]

ok. I will try that. I can fly the sc3 version and see what the fuel amount is left. And then just set the fuel level to that

 

[4throck]

I did that for the Atlas Agena and it works.

First I defined the payload as upperstage, with all the fuel possible.
Got into orbit and noted how much was used.
Defined it again as a ghost stage (no mesh) with only the amount of fuel needed, and balanced weights and fuel between the ghost stage and payload.
It worked as intended.

 

[gattispilot]

Thanks. So since the sc3 version seem to work fly it and when it gets to orbit get the fuel level.
Then set the dll version fuel mass to that and set the ghost ship mass to .1.

---------- Post added at 03:47 PM ---------- Previous post was at 11:11 AM ----------

So I tried the launch from Edwards with the Sc3 and the same result. But from Florida it is okay?
It makes no sense. The way I have it set up is like the SLS the base as an attachment which is attached to the pad.