Project VesselBuilder for Orbiter

[4throck]

Great news! Fred, will it support keyboard commands? You mention animations, so I guess it will.

You also mention 2 touchdown point sets.
Could this be extended to handle 2 (or more) configuration states ?
For example, redefining a docking port or attachment location ?

Thinking about the Chang'e lander where the rover goes on top, but then needs to be released on the ground.

 

[gattispilot]

Will it be able to load a VC mesh. I think adding vc animations and mfd might be too much.

 

[fred18]

will it support keyboard commands? You mention animations, so I guess it will.

yes, for animations the users will have the possibility to choose almost for any key they want. Right now the key modifiers for animations are fixed (SHIFT + key to start the animation, CTRL+SHIFT+key to stop or start backward) but in a future version I could focus on this and let the modifiers also an option.

Here's a screenshot of the animations dialog with the key combo open:

The users may also choose for the animation not to have a particular key and a manual cycle for the animation. In this case the users will be able to actuate the animations manually with predefined keys (similar to the robotic arm system of SC3/GV)

The other keys set at the moment are the CTRL+G to grab objects when using robotic arms and I will implement the J key for jettison payloads with the procedure I mentioned a couple of posts earlier.

You also mention 2 touchdown point sets.
Could this be extended to handle 2 (or more) configuration states ?
For example, redefining a docking port or attachment location ?

Thinking about the Chang'e lander where the rover goes on top, but then needs to be released on the ground.

To be honest I haven't thought of a total reconfiguration of the vessel. but for the Chang'è lander I think that a robotic arm implementation should work: the attachment point will move everywhere you set it up to.

I can think of a "vessel exchange option", that will load a brand new vessel on command. but I'm not so sure about this, I will look on how it could work.

Will it be able to load a VC mesh. I think adding vc animations and mfd might be too much.

The idea I have at the moment is give the ability to load the mesh, to set up HUD, and all the MFDs that a user wants, together with all the relevant buttons (not animated, just points where the users will click). VC is the last point of the list at the moment. I think that giving the opportunity to make things like animations in the VC is a bit useless because the users would also have to implement what each animation/switch/button will do. It's something that needs to be coded, not possible through a general module.

---------- Post added 27th Feb 2019 at 02:23 ---------- Previous post was 26th Feb 2019 at 21:29 ----------

As anticipated airfoils are going smooth up to now.

here's a pic of the dialog. The graph can be shown or hidden and it is updated live as the points for the CL calculations are added or modified. The picture shows the Shuttle CLs, which one of the possible defaults configurations (DeltaGlider,Space Shuttle or Capsule).

As anticipated the capsule values have not been entered yet, and if someone has a valid set of CL and CM function of AOA to share they will be very welcome!

Cheers guys
Fred

 

[4throck]

I can think of a "vessel exchange option", that will load a brand new vessel on command. but I'm not so sure about this, I will look on how it could work.

This would be good. I was thinking about connecting new (partial) configs to keys, but a global option is a start.

Also keep open the possibility using events besides keys: altitude, pressure, is landed, is docked
I know this adds complexity but it would be good to trigger a parachute at a certain altitude.

Anyway, keep up the good work, it's appreciated!

 

[fred18]

I can think of a "vessel exchange option", that will load a brand new vessel on command. but I'm not so sure about this, I will look on how it could work.

This would be good. I was thinking about connecting new (partial) configs to keys, but a global option is a start.

Also keep open the possibility using events besides keys: altitude, pressure, is landed, is docked
I know this adds complexity but it would be good to trigger a parachute at a certain altitude.

Anyway, keep up the good work, it's appreciated!

I was thinking that I could add a section called "Events" where users can define a series of events that will be triggered when a set of conditions are met or when a key is pressed. The "easiest" thing would be a complete vessel reconfiguration.

Anyway this will not be there in the very first release: first and most important thing everything must work as it should, without bugs or issues, so the first release must have a vessel builder that works properly.

I can say that in order to test airfoils I started to reproduce the DeltaGlider with VesselBuilder and it took me 10 minutes to have it flying and working. It looks really really promising.

 

[4throck]

Yes, 'Events' will do, what you describe is what I had in mind.
For a test latter on, think about the Soyuz and how it separates into 3 vessels, and how propulsion changes with that.

But get it working first :thumbup:
Undefined scope is the biggest problem with any development, so focus just on the core.

 

[fred18]

Yes, 'Events' will do, what you describe is what I had in mind.
For a test latter on, think about the Soyuz and how it separates into 3 vessels, and how propulsion changes with that.

But get it working first :thumbup:
Undefined scope is the biggest problem with any development, so focus just on the core.

I made a quick test for curiosity and the overall reconfiguration of the vessel works fine. What troubles me relevant to partial reconfiguration is that many sections are interrelated: think about meshes and animations or exhausts and thrusters... But it is also true that I should warn developers about this but then it will be their responsability not to mess up with interrelated sections... so maybe I should not make it "my" issue.
About events what comes to my mind is something like:
possible events:
- spawning of a child
- triggering of an animation
- firing of thrusters
- vessel partial or total reconfiguration
possible triggers:
- keypress
- altitude threshold (from above or from below)
- fuel tank level threshold (this is a longshot, thinking of a possible multistage vessel)
- velocity threshold (from above or from below)
- time (mission time? simulation time? mjd? that's something to think about)

all this is feasible without crazy work, because as anticipated, I'm working hard on the code to make it the more versatile possible. Speaking of the code I will probably rewrite the animations part because from a first review it seems that for that part I lost the Keep It Simple approach, and I have ideas to make it much much easier to code.

Speaking of something like the Soyuz I think that this module will bring also some needings of a new way of thinking addons: maybe the optimum would be to make the soyuz with three vessels docked together. We are all very used to Vinka's style, but I think that now there could be many new approaches to explore.

In the meantime the Control Surfaces are perfectly working, so in my list only lights, cameras and Virtual Cockpit are missing then the module pre-release will be ready.

I reiterate here my requests to anyone listening:
1) Is there anybody interested in making a video tutorial on the usage of the module? please let me know because it could be very useful
2) Does anybody have a set of CL and CM function of AOA for a typical capsule he is wishing to share to set it as Capsule default parameter?

Cheers
:tiphat:
Fred

 

[Donamy]

I have one that I used for the Shenzhou9, but I can't remember where I got it. You're free to use it.

 

[4throck]

maybe the optimum would be to make the soyuz with three vessels docked together.

Sure. We can fly the Soyuz return module and change the propulsion configuration once the service module separates.


If I may suggest, in the far, far future, try to add solar radiation calculation as a base for 2 things - solar panels and temperature.
This is zero priority but might add some "playability" to vessels. Something like if temperature and power are off limits, the vessel stops being controllable.

 

[fred18]

So, I rewrote the animations part and it seems much better now. Before I had something like 4 classes and an infnite number of methods and parameters, now I have one class and some 20 methods. The KISS approach has been correctly restored :thumbup:

now I'm noting down some issues and things that can be a bit better while testing. I'll also have to add the variable drag elements, I don't know if I'll add a specific section or if I'll include them in the control surfaces. But anyway it's not a big issue to add.

I have to say that I'm intrigued by the "events" section from the idea of 4throck... if the testing keeps going smoothly I will try to add an experimental events section soon...

 

[jacquesmomo]

Hi Fred

Just a question by the way ....

Will it be possible to simulate an umbilical mat with cryogenic arm and umbilicus ?

(I do not know if you remember but we already talked about this)


That is to say a "immobile vessel" placed on the ground with the cryogenic arms and umbilicals that can retract during the launching of the rocket...


Like this :

That would be great and the ultimate....

 

[fred18]

Hi Fred

Just a question by the way ....

Will it be possible to simulate an umbilical mat with cryogenic arm and umbilicus ?

(I do not know if you remember but we already talked about this)


That is to say a "immobile vessel" placed on the ground with the cryogenic arms and umbilicals that can retract during the launching of the rocket...


That would be great and the ultimate....

Absolutely yes... With the events section it will be possible to trigger animations at certain time, so it will be enought to sync the times between tower and rocket.

I have been thinking and with the events sections the implementation also of a multistage vessel could be possible. I think that the big thing about the current multistage is above all guidance, but bringing guidance to the VesselBuilder would be risky, so once this is done an external plugin, like an mfd, could be done which simply adds multistage guidance capabilities to a VesselBuilder vehicle.

I have to honestly say that I am very happy with the current development status: I did all I could to make the module the more versatile possible, and the approach is paying! In order to make tests I have a series of example test vehicles:
- A robotic arm (the SSRMSD of the video)
- the DeltaGlider rebuilt with VesselBuilder
- a part of the ISS, so a complex space station
- a simple satellite model

All done with this VesselBuilder... I think that the versatility is there. Now I have to keep working hard to finish the job and fix any bug.

 

[jacquesmomo]

Absolutely yes... With the events section it will be possible to trigger animations at certain time, so it will be enought to sync the times between tower and rocket.

Great !!! :banana: Super !!! :tiphat: https://www.surlatoile.com/smileys/repository/Drapeaux/france-cool.gif

 

[Donamy]

Will you make is so the attachments, only grapple certain ID names ?

 

[GLS]

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!

A quick search returned this for the Apollo CM: https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19680021973.pdf

 

[fred18]

Will you make is so the attachments, only grapple certain ID names ?

At the moment that function is not implemented. The current implementation of grappling foresees a user-defined range for each attachment. the module scan if there are vessels with attachment points within the range and choose the closest one.

In theory the check on the ID could be implemented, I just wonder if it is really used by users.

A quick search returned this for the Apollo CM: https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19680021973.pdf

Wow, thanks a lot, that's a fantastic starting point to derive a set of average points! Thanks!! :tiphat:

In the meantime i'm working on the VC... HUD is working perfectly, so the VC positions. MFD are displaying correclty and if I stop there it could be done. But I'm trying to implement a click system for MFD buttons even though is not so easy. Besides HUD and MFDs there isn't much to do in the VC, since the rest of the functions are too highly specific for each vessel, it's impossible to implement them in a general module.

so here's a quick shot of the VC of the DeltaGlider done with VesselBuilder:

 

[Donamy]

At the moment that function is not implemented. The current implementation of grappling foresees a user-defined range for each attachment. the module scan if there are vessels with attachment points within the range and choose the closest one.

In theory the check on the ID could be implemented, I just wonder if it is really used by users.



Wow, thanks a lot, that's a fantastic starting point to derive a set of average points! Thanks!! :tiphat:

In the meantime i'm working on the VC... HUD is working perfectly, so the VC positions. MFD are displaying correclty and if I stop there it could be done. But I'm trying to implement a click system for MFD buttons even though is not so easy. Besides HUD and MFDs there isn't much to do in the VC, since the rest of the functions are too highly specific for each vessel, it's impossible to implement them in a general module.

so here's a quick shot of the VC of the DeltaGlider done with VesselBuilder:

It is with the SAL. It has to distinguish between hand holds and WIF attachments. Some attachments are the same position, but different directions.

 

[fred18]

It is with the SAL. It has to distinguish between hand holds and WIF attachments. Some attachments are the same position, but different directions.

Ok, I will add it as a possible option: the user will be able to define a custom ID for that attachment and if the option is activated the attachment will be able to grapple only the correct children. I'll do it before the pre_release, but I will first finish the current round of checks.

I'm finishing the VC, from my plan, apart from various glitches to fix, the only thing missing would be light emitters, but I'm very unsure about them. It seems to me that are rarely used from addon developers and building a working interface for them is not easy at all. There is the risk to make it the most complicated section and the least used... I'll give another thought about it

 

[gattispilot]

the only thing missing would be light emitters, but I'm very unsure about them. It seems to me that are rarely used from addon developers and building a working interface for them is not easy at all.

So will this have lights and beacons?

 

[fred18]

So will this have lights and beacons?

Any suggestions? is it something that developers use a lot or not?

I guess that since I did all the job up to now it would be silly not to include also them, even though it will be an headache...