Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Addons > Addon Development
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Addon Development Developers post news, updates, & discussions here about your projects in development.

Reply
 
Thread Tools
Old 11-01-2018, 06:42 PM   #991
fred18
Addon Developer

Default

Quote:
Originally Posted by 4throck View Post
 A "vesselcontrol.dll" would be nice and could be used standalone (without multistage) if needed.

It could run on top of existing vessels and add the landing point equation for instant 2016 compatibility.
That alone would make the effort worth your time....

The basic functionality would be:
- define a set of vessel parameters for launch, another set after jettison;
- support 2016 only parameters to make older payload vessels compatible;
- intercept or send key presses;
- handle vessel focus, attachment or docking during / after jettison
- work standalone from multistage, adding functionality to existing vessels
I think that could be interesting but it would be beyond the scope of what I am looking for here.

Recapping: the point is the actual multistage structure (the unique vessel which spawns the various stages) works fine, BUT I always had the doubt if it would be nicer to have a more realistic multistage structure with each stage a single vessel that it just separates on the flight.

Recently in a discussion Urwumpe (which is a very knowledgeable user here) pointed out the same and stated that it would be much nicer to basically be able to choose payloads and maybe stages architecture on the go (if I got it right).

While this is theoretically almost possible with the current Developer Mode Dialog of MS2015, it tickled my fantasy again of making the multistage module flying an actually multistage vessel, composed by various vessels, as said before.

Now the process I am in the middle of is:
  1. physics in Orbirer is currently properly computed with docking and it is not with attachments.
  2. to do it properly docking should be used (now that it is possible in Orbiter 2016).
  3. the docking APIs provided with orbitersdk are poorer comparing to the attachment APIs. I could elaborate this a bit more and try to recreate the same commands of attachments, but it is not immediate since docking is thought for something different.
  4. using docking will probably mean to generate wrong atmospherical drag foces, due to the fact that the orbiter core would probably not consider that the stages are one on the tail of the other
  5. therefore maybe attachments are better. They are also much more versatile. But then there will be the need of updating the whole set of physics of the rocket at each staging event, exactly like the current system.
  6. so in the end I keep the doubt if it's worth the effort...
  7. the only proper way I see to do it IMHO is to just use the last stage as core. An independent plugin can be used for general management, maybe to make it usable more like KSP (even though I never played KSP).
  8. the developer mode dialog shall be untied from the multistage code and walk with its own code (but that is another story).

And that's it, there I am with my doubts about this...
fred18 is offline   Reply With Quote
Thanked by:
Old 11-01-2018, 07:39 PM   #992
DaveS
Addon Developer
 
DaveS's Avatar


Default

Quote:
Originally Posted by fred18 View Post
 the only proper way I see to do it IMHO is to just use the last stage as core.
This is how it's done on real LVs, the actual flight computer(s) are located on the last common stage. For Delta IV, this is the DCSS and for Atlas V, it's on the Centaur. The lower stages only react to commands sent from the upper stage.


The Saturn V/1B flight computer, called the Launch Vehicle Digital Computer (LVDC), was located inside the Instrument Unit (IU) ring that sat on top of the S-IVB stage. This was true even for the Saturn V that launched Skylab as Skylab was just a modified S-IVB stage.
DaveS is offline   Reply With Quote
Thanked by:
Old 11-02-2018, 01:13 PM   #993
4throck
Enthusiast !
 
4throck's Avatar
Default

On multistage the user defines each stage parameters, including the position of the meshes.
With vessels, the parameters will already be there, they come from the vessel's .dll
If you use docking, vessels limit you to the existing docking ports.

So you'll need to overwrite all of that to make it work for the end user.
And then you will end up with my broader scope suggestion
What you are thinking is MultiVessel, not Multistage
4throck is offline   Reply With Quote
Old 11-02-2018, 02:26 PM   #994
martins
Orbiter Founder
Default

Quote:
Originally Posted by fred18 View Post
 ... (I said attached, because docked is possible but I found the docking available commands too general to manage such a complicated situation like Multistage module is).
Could you expand a bit on what you mean by "too general"? If there are specific interface functions missing in the API you would need to implement your module, I'd be happy to consider adding them. In general, I'd like to encourage using the docking, rather than attachment mechanim, since it takes into account the modified physics of the assembly (mass, PMI, angular moments, merged touchdown hulls, etc.) Attachments don't do any of this, so the addon developer would have to implement those things manually. Attachments were really only meant for sticking small bits onto the main vessel that wouldn't change the vessel behaviour significantly.
martins is offline   Reply With Quote
Thanked by:
Old 11-02-2018, 03:22 PM   #995
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by fred18 View Post
 Recently in a discussion Urwumpe (which is a very knowledgeable user here) pointed out the same and stated that it would be much nicer to basically be able to choose payloads and maybe stages architecture on the go (if I got it right).
Nonono... just payload (and maybe upper stage) would be enough. Do you remember Kulchs Payload Manager SDK? Something like that would be sweet.

http://www.kulch.spb.ru/Eng/PM_project.html

Sadly, it is a bit outdated now.

---------- Post added at 16:22 ---------- Previous post was at 16:21 ----------

Quote:
Originally Posted by DaveS View Post
 This is how it's done on real LVs, the actual flight computer(s) are located on the last common stage. For Delta IV, this is the DCSS and for Atlas V, it's on the Centaur. The lower stages only react to commands sent from the upper stage.
Not always, you can also have hybrid solutions there - for example a launch vehicle guidance for the first two stages and a guidance for upper stage and payload by the payload guidance computer.
Urwumpe is offline   Reply With Quote
Old 11-02-2018, 04:45 PM   #996
fred18
Addon Developer

Default

Quote:
Originally Posted by martins View Post
 Could you expand a bit on what you mean by "too general"? If there are specific interface functions missing in the API you would need to implement your module, I'd be happy to consider adding them. In general, I'd like to encourage using the docking, rather than attachment mechanim, since it takes into account the modified physics of the assembly (mass, PMI, angular moments, merged touchdown hulls, etc.) Attachments don't do any of this, so the addon developer would have to implement those things manually. Attachments were really only meant for sticking small bits onto the main vessel that wouldn't change the vessel behaviour significantly.
Sure, the main issue is that the AttachChild/DetachChild commands of the Vessel class uses the attachmenthandles to attach the vessels, while the Dock/UnDock command of the vessel class uses docking port numbers instead.
And there is no API to go from Handle to Port number (only the other way around). Considering that everytime there is a deletion of a docking port all the numbers after it make a step back, when there are a lot of docking ports it soon becomes quite a mess to keep trace of the correct port to use.
Even if I don't delete the docking ports and just undock the stages, I can pick the correct port only if I have kept a very linear trace of docking creations.

Now, it just came to my mind that a possible solution could be to make a small function which recursively checks through all the ports available if the dockhandle that I am looking for is equal to the dockhandle of any of the ports and in that case returns the port number and then basically create some MyOapiDockFunction and MyOapiUnDockFunciton which use that system.

pseudocode:
Code:
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.

---------- Post added at 17:45 ---------- Previous post was at 16:40 ----------

Quote:
Originally Posted by Urwumpe View Post
 Nonono... just payload (and maybe upper stage) would be enough. Do you remember Kulchs Payload Manager SDK? Something like that would be sweet.

http://www.kulch.spb.ru/Eng/PM_project.html

Sadly, it is a bit outdated now.
That is already basically possible. not super quickly as it was with Kulch's addon, but neither this far.





And payloads can be live as well, so not spawned. Relevant to live payload it is possible to make the shuttle by placing the orbiter as payload, making the rest as multistage jump in the VC of the orbiter and command the sequence from there. Same for capsules above any other rocket of course.
fred18 is offline   Reply With Quote
Thanked by:
Old 11-02-2018, 05:35 PM   #997
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

So in theory - spawning a MS2015 vessel during runtime is possible?
Urwumpe is offline   Reply With Quote
Old 11-02-2018, 05:43 PM   #998
fred18
Addon Developer

Default

Quote:
Originally Posted by Urwumpe View Post
 So in theory - spawning a MS2015 vessel during runtime is possible?
I never tried from 0 with the scenario editor actually... but if you start your scenario with just a monostage basic vessel with just the most basic definitions needed then you can change everything, add stages, boosters, payloads, place them in correct place, test the rocket and then reset it to the ramp,... you can also edit the ini file and then reload the rocket during runtime (which gives the idea that you can do anything you want).

For making it spawnable from 0 with the scenario editor it would be just a matter of creating a series of initialization definitions for vessels loaded without any ini file
fred18 is offline   Reply With Quote
Old 11-02-2018, 05:44 PM   #999
Linguofreak
Orbinaut
Default

Quote:
Originally Posted by fred18 View Post
 Sure, the main issue is that the AttachChild/DetachChild commands of the Vessel class uses the attachmenthandles to attach the vessels, while the Dock/UnDock command of the vessel class uses docking port numbers instead.
And there is no API to go from Handle to Port number (only the other way around). Considering that everytime there is a deletion of a docking port all the numbers after it make a step back, when there are a lot of docking ports it soon becomes quite a mess to keep trace of the correct port to use.
Even if I don't delete the docking ports and just undock the stages, I can pick the correct port only if I have kept a very linear trace of docking creations.
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)?
Linguofreak is offline   Reply With Quote
Old 11-02-2018, 06:13 PM   #1000
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by fred18 View Post
 For making it spawnable from 0 with the scenario editor it would be just a matter of creating a series of initialization definitions for vessels loaded without any ini file

Yes, about that. Practically, I just want to be able to build a space station and spawn a rocket to launch the modules. Of course, an assembly building would look better, but its not needed for the "game".
Urwumpe is offline   Reply With Quote
Old 11-03-2018, 07:22 PM   #1001
fred18
Addon Developer

Default

Quote:
Originally Posted by fred18 View Post
 pseudocode:
Code:
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.[COLOR="Red"]
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.

---------- 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 ----------

Quote:
Originally Posted by Linguofreak View Post
 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 is offline   Reply With Quote
Old 11-08-2018, 11:19 AM   #1002
fred18
Addon Developer

Default

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

keep you posted.
fred18 is offline   Reply With Quote
Old 11-08-2018, 06:51 PM   #1003
4throck
Enthusiast !
 
4throck's Avatar
Default

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.
4throck is offline   Reply With Quote
Thanked by:
Old 11-08-2018, 07:02 PM   #1004
jacquesmomo
Addon Developer
 
jacquesmomo's Avatar
Default

Quote:
Originally Posted by fred18 View Post
 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

keep you posted.
I understand !!!!
jacquesmomo is offline   Reply With Quote
Reply

  Orbiter-Forum > Orbiter Addons > Addon Development


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 11:12 AM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.