Project VesselBuilder for Orbiter

[fred18]

Hi guys,

I decided to open a new thread about my current project which is the in-sim Vessel Builder for Orbiter.
It all started with the ISS AtoZ unique vessel project but then I found out that it could become more complete so from a "station builder" it soon became a Vessel Builder.

It is basically a module which brings in a small simple dialog almost the whole set of Vessel's API available in Orbiter, and it tries to be intuitive and simple.

It reads and stores all the value in the vessel's cfg file, allowing the vessels to be easily spawned during simulation and completely customized without writing a single line of file, just doing everything in-sim.

The module comes with a tool that I find it very useful which is called the "FollowMe" tool, which allows to "go around" the module, assume proper orientation and then simply copy and paste the vectors inside the control dialog.

The customizable items are planned to be:

• General Vehicle Settings (Empty mass, PMI etc) [COMPLETED]
• Meshes (a lot of options here, including mess rotations and live placement for multimeshes vehicles) [COMPLETED]
• Docking Ports (with the option to see the docking ports live on the vessel) [COMPLETED]
• Attachments (with the option to see the attachments live on the vessel) [COMPLETED]
• Animations (almost everything possible here) [COMPLETED]
• Propellants [COMPLETED]
• Exhausts Textures [COMPLETED]
• Particle Streams Definitions [COMPLETED]
• Thrusters (with the option to see the thrusters live on the vessel and test them)[COMPLETED]
• Thruster Groups [COMPLETED]
• Touchdown Point definitions (with the capability of setting 2 sets of TD points switchable through an animation of choice) [COMPLETED]
• Airfoils and Control Surfaces [COMPLETED]
• Lights [COMPLETED]
• Cameras [COMPLETED]
• Gyroscopic Attitude Control [TO DO]

Once the Vessel Builder is done the ISS AtoZ Unique Vessel will be one of the very first (and very big) examples of its capabilities.

I hope that this module will get people closer to orbiter and to addon development, since it could become both intuitive and fun.

Here below some videos of the first tests of the module during development (some things have already changed but the videos give the idea of what I am talking about)

Cheers guys

Fred

---------- Post added at 21:33 ---------- Previous post was at 21:32 ----------

PRERELEASE DOWNLOAD LINK

GITHUB PROJECT PAGE

 

[Wolf]

Thank you so much for this amazing addon fred! IMO this will bring the Orbiter experience to a totally new level (expecially for non-developers)
I guess we will be able to manage and configure also payloads for any vessel, right?

 

[Donamy]

Thank you so much for this amazing addon fred! IMO this will bring the Orbiter experience to a totally new level (expecially for non-developers)
I guess we will be able to manage and configure also payloads for any vessel, right?

It'll make my life easier.


:hail:

 

[Wolf]

It'll make my life easier.


:hail:

Maybe I could request to add an in sim texture tool :lol:

 

[fred18]

I guess we will be able to manage and configure also payloads for any vessel, right?

That's a very good point that was around my mind in this days. We are all very accustomed to the Vinka structure with a vessel with all its payloads (which are dead meshes attached to it). But shall we consider simply docking and/or attachments for payload management? it's an open question, I still haven't made up my mind about this.

Maybe I could request to add an in sim texture tool :lol:

You could, but not to me, I'm both bad at texturing and ignorant about graphic software develpment :lol:

 

[Donamy]

I think what you'll see, is alot of people using models that they download, to make them usable in Orbiter.

 

[Zandy12]

Amazing work so far fred18! This add-on will make in-game vessel configuration so much easier. Will you be needing testers for the project?

 

[fred18]

Amazing work so far fred18! This add-on will make in-game vessel configuration so much easier. Will you be needing testers for the project?

I surely will! As soon as a pre-release is ready I will count you in

 

[jacquesmomo]

Prodigieux !!! (prodigious) :tiphat:

I surely will! As soon as a pre-release is ready I will count you in

:banana:me...

 

[Interceptor]

Excellent fred18,looking foward to the final product,Thanks.

 

[Donamy]

Will this make the vessels a .dll ?

 

[fred18]

Will this make the vessels a .dll ?

Nope, i'd say that it is somehow halfway between a dll and Vinka's Spacecraft: the module still stores its values in a text file, but the file is the cfg of the vessel (which is special) and it will not be needed to edit the file manually.

 

[DaveS]

Nope, i'd say that it is somehow halfway between a dll and Vinka's Spacecraft: the module still stores its values in a text file, but the file is the cfg of the vessel (which is special) and it will not be needed to edit the file manually.

So if I understand this correctly: VesselBuilder exists both as a front-end and back-end with the front-end being the GUI and the back-end being the parser. The GUI is optional as the back-end parser will store everything in a readable format in a text file, similar to MS/SC and Orbiter's own Lua engine. Things can be edited outside the sim thanks to the back-end parser. The GUI front-end just allows for in-game editing as well as visualization of the vessel as the changes are taking effect.


Is this about right?

 

[fred18]

So if I understand this correctly: VesselBuilder exists both as a front-end and back-end with the front-end being the GUI and the back-end being the parser. The GUI is optional as the back-end parser will store everything in a readable format in a text file, similar to MS/SC and Orbiter's own Lua engine. Things can be edited outside the sim thanks to the back-end parser. The GUI front-end just allows for in-game editing as well as visualization of the vessel as the changes are taking effect.


Is this about right?

Yep!

I also have thought about giving the option of encrypting the cfg and make it password protected for those who are willing to keep the vessel source closed. Would that be an interesting option? I don t like it much because i would have to keep also the encryption alghorithm closed source, but if users think that it s a must i could work on it

---------- Post added at 11:12 ---------- Previous post was at 06:38 ----------

Relevant to payload I had this idea, any feedback is welcome:
the best option to manage payloads is through docking ports, since docking manages also all the physics. The "issue" I see is that once a docked vessel is released the docking port remains available for further docking and that is unrealistic to me.

So my idea for a solution is to mark a docking port as a "payload port", that will be available for just one docking (when you dock your payload) and once you released the payload the docking port will be automatically deleted. In this way it would be easy also to setup the initial scenario of an addon using the scenario editor. I would also add the mangement of jettison through the usual "J" key instead of having to using CTRL+D to undock.

In this way it would also be possible to have nested payloads, rotated payloads... the whole package...

Do you guys like this option?

 

[Wolf]

Yep!

I also have thought about giving the option of encrypting the cfg and make it password protected for those who are willing to keep the vessel source closed. Would that be an interesting option? I don t like it much because i would have to keep also the encryption alghorithm closed source, but if users think that it s a must i could work on it

---------- Post added at 11:12 ---------- Previous post was at 06:38 ----------

Relevant to payload I had this idea, any feedback is welcome:
the best option to manage payloads is through docking ports, since docking manages also all the physics. The "issue" I see is that once a docked vessel is released the docking port remains available for further docking and that is unrealistic to me.

So my idea for a solution is to mark a docking port as a "payload port", that will be available for just one docking (when you dock your payload) and once you released the payload the docking port will be automatically deleted. In this way it would be easy also to setup the initial scenario of an addon using the scenario editor. I would also add the mangement of jettison through the usual "J" key instead of having to using CTRL+D to undock.

In this way it would also be possible to have nested payloads, rotated payloads... the whole package...

Do you guys like this option?

I think this would create an issue with those payloads that were released and later during the mission retrieved back in the cargo bay. The MPLM in some STS missions is an example.

 

[fred18]

I think this would create an issue with those payloads that were released and later during the mission retrieved back in the cargo bay. The MPLM in some STS missions is an example.

Wait, 1 second: attachments, docking etc will keep working the normal way. I think that at the moment the Cargo bay has an attachment point and the mass of the orbiter gets updated if anything is attached to it.
If you want to recreate it, you just create a regular docking port that will not get deleted so you can use it how many times you want.

I was referring in particular to the "SC3 Style" payloads, like Cassini and Huygens probe for example.

 

[Wolf]

Wait, 1 second: attachments, docking etc will keep working the normal way. I think that at the moment the Cargo bay has an attachment point and the mass of the orbiter gets updated if anything is attached to it.
If you want to recreate it, you just create a regular docking port that will not get deleted so you can use it how many times you want.

I was referring in particular to the "SC3 Style" payloads, like Cassini and Huygens probe for example.

Ok then. Sorry about the misunderstanding

 

[fred18]

Don't be sorry, all the inputs are super welcome!! :thumbup:

 

[Donamy]

I wouldn't want a password system. I'd forget it sure.

 

[fred18]

In the meantime:
- General Settings of the vehicle completed: Empty Mass, Size, PMI, Cross Sections and Gravity Gradient Damping.
- Touchdown Points settings completed: it is possible to define 2 sets of touchdown points. The first is the main set and there is also the possibility to just apply a default set of points which will anyway work in most of the cases. If the second set of points is enabled the user shall choose a Change Over animation, and the vessel switches from one set to the other when the animations gets to its status 1 and revert back. Typical use of this: landing gear-> When retracted there is set 1, when extended there is set2 or viceversa.

Tonight I am starting to work on the Airfoils. I hope that it's not too harsh, because the pre release is getting very close...

---------- Post added 26th Feb 2019 at 16:34 ---------- Previous post was 25th Feb 2019 at 21:22 ----------

Hi guys,

the airfoil part is proceeding much better than I thought. I hope in the end everything works as it should, but the fact that in the liftcoefffunc there is the possibility to pass a void* context parameters makes everything much much easier.

Having said so, I am currently adding 3 default models for lift coefficient functions: Deltaglider, Space Shuttle and Capsule, so users may have a starting point to work on. For DG and Shuttle models I will use the data provided by the code made available by martins, but for the capsule I have to look around for suggestions. I don't want to "steal" data made available from other addons (I am thinking for example about the Dragon of BrianJ whose code is available and which is a capsule).
So the question is:
Does anyone have a set of CL and CM function of AOA parameters relevant to a typical capsule (Apollo CM for example) that is willing to share for this project? of course everything will be credited!

Thanks in advance
Fred