Project OrbiterCrews / OMMU Development

[Mr Martian]

Hi All,

I just wanted to make an announcement/ask for some suggestions regarding a project I am currently working on.

The project is a UMmu alternative for Orbiter 2016, which will include a SDK for addon developers to add crew functionality to their addons. Based on current development rate, I am hoping to release the first version/beta sometime within the next few weeks.

As-is, the project features the following:

• Crew management onboard vessels (selection, airlock selection, etc)
• EVA of crew from vessels and return
• Transfer of crew between vessels
• Crew movement along planetary surfaces in Orbiter 2016
• "Interface Areas" (same principal as Action Areas in UMmu)
• Airlocks which can be defined as either 'standalone' or associated with a docking port
• Crew members can be EVAed with either MMU (RCS jetpack) or none. MMU parameters can be custom user-defined (same as mesh)
• Crew members can pick up items
• User-defined custom meshes and parameters for crew (no coding required)
• User-defined habitable areas on planetary surfaces (no coding required), O2 supply can be replenished in said areas

I still need to implement the following:

• Create a mesh for crew (currently using an edited UMmu mesh for development)
• Write a comprehensive manual
• Code cleanup
• Decide on name, currently working name is OEMU (Orbiter Manned Maneuvering Units), but also thinking of OrbiterCrews, definitely open to suggestion on this!
• Package the addon with some example vessels and SDK

At this point I am open to any suggestions. Please let me know if you have any questions at all, or have any features in mind you would really like to see. Also, I would like to get an idea if this is something people would be interested in seeing/using, personally I decided to work on this since I really do miss the crew element UMmu offered, and curious to see if others feel the same!

Thanks in advance All!

 

[gattispilot]

YES!!!

Let me know if you need help on meshes.

 

[Urwumpe]

What license are you planning to use for it?

About the parameters - what kind of parameters will be allowed? Can it for example also be a handle?

 

[jedidia]

Glad to see you're getting ahead!

Please let me know if you have any questions at all

The major question for me would be, will it be open source? A new crew framework will certainly be welcome, but if it's closed source we'll just have the same problem again down the line...

 

[Mr Martian]

YES!!!

Let me know if you need help on meshes.

Thank you gattispilot! I think that would actually be a great help!

I have used Sketchup to create meshes for many years now. I am very familiar with it, but the texturing capabilities of sketchup are not good enough to create something as non-uniform as a spacesuit, so this is something that ill pose issues for myself. I am aiming to have a very 'typical' spacesuit as the default mesh; the kind of white NASA style.

What modeling software do you use?

 

[Mr Martian]

Glad to see you're getting ahead!

The major question for me would be, will it be open source? A new crew framework will certainly be welcome, but if it's closed source we'll just have the same problem again down the line...

Thank you Jedidia! This has been a big learning curve for me but your input earlier was a true godsend.

Currently I have no plans to make this open source, however if it becomes widely used/open source requested I don't see why not. Orbiter is freeware after all.

The main reluctance I have would be simply to avoid numerous instances of it being circulated with addons reducing cross-compatibility.

 

[Mr Martian]

What license are you planning to use for it?

About the parameters - what kind of parameters will be allowed? Can it for example also be a handle?

Have not thought about licenses at all actually.

And regarding handles, what exactly do you mean? define a custom handle for the 'spawned' crew? spawned crew are vessel classes, so in that case this would be the OBJHANDLE.

What would you wish to do with a custom handle?

 

[gattispilot]

Thank you gattispilot! I think that would actually be a great help!

I have used Sketchup to create meshes for many years now. I am very familiar with it, but the texturing capabilities of sketchup are not good enough to create something as non-uniform as a spacesuit, so this is something that ill pose issues for myself. I am aiming to have a very 'typical' spacesuit as the default mesh; the kind of white NASA style.

What modeling software do you use?

I use Anim8tor.

Something that would be nice. Is the ability to have this so that not just mesh crew could be used? In UMMU it justed a cfg to tell what mesh to use. But what if you wanted a crew vessel where the arms,... moved.

 

[Urwumpe]

Have not thought about licenses at all actually.

And regarding handles, what exactly do you mean? define a custom handle for the 'spawned' crew? spawned crew are vessel classes, so in that case this would be the OBJHANDLE.

What would you wish to do with a custom handle?

Just link the crew members in your add-on to health/skill data in an roleplaying game like framework for adding NPCs. So, I only require as little support and data from your end to include them, and later figure out, how many public parameters my model would need to support to allow exchanging astronauts with other frameworks.

In the best case, it could be a hidden binary handle parameter, that isn't meant to be displayed - or if you support string attributes (like the name), I could simply format the primary key into some string format (base64? Hex? Magic?) and use this for linking the astronaut to the data of the framework plugin.

And for the licence, its just the usual "Is it FOSS or do I risk getting vendor-locked?" question.

 

[N_Molson]

Thank you gattispilot! I think that would actually be a great help!

I have used Sketchup to create meshes for many years now. I am very familiar with it, but the texturing capabilities of sketchup are not good enough to create something as non-uniform as a spacesuit, so this is something that ill pose issues for myself. I am aiming to have a very 'typical' spacesuit as the default mesh; the kind of white NASA style.

What modeling software do you use?

Blender allows that and much more (like procedural texture generation). It is free and has all the features of a professional software. Of course, the learning curve is a bit steep. But you can do anything.

I like OrbiterCrews.

 

[jedidia]

The main reluctance I have would be simply to avoid numerous instances of it being circulated with addons reducing cross-compatibility.

In my experience, this rarely happens. Not with projects this small and uncontroversial.
What does happen is that developers get tired of a project, or are otherwise inconvenienced, and their add-on doesn't keep up with releases and becomes incompatible.
Which is kind of why we there's demand for another crew framework in the first place. Woo started working on one, and seems to have gone a fair stretch, and then suddenly went silent. I really hope he's ok, but it's also sad that we don't have the code, or you'd have had a nice starting point.
What I'm saying is, what is really needed is not just another crew framework. What is needed is one that can be maintained when the original developer doesn't have the will or capacity to keep up anymore, otherwise history is going to repeat...

 

[N_Molson]

So the question would more be like : would you agree to release your source code if for some reason (from our experiences life is full of those unexpected reasons, for the worst but also the best) you don't have time or motivation to keep working on this project ? ?

 

[Mr Martian]

In my experience, this rarely happens. Not with projects this small and uncontroversial.
What does happen is that developers get tired of a project, or are otherwise inconvenienced, and their add-on doesn't keep up with releases and becomes incompatible.
Which is kind of why we there's demand for another crew framework in the first place. Woo started working on one, and seems to have gone a fair stretch, and then suddenly went silent. I really hope he's ok, but it's also sad that we don't have the code, or you'd have had a nice starting point.
What I'm saying is, what is really needed is not just another crew framework. What is needed is one that can be maintained when the original developer doesn't have the will or capacity to keep up anymore, otherwise history is going to repeat...

I have private messaged you

 

[Mr Martian]

So the question would more be like : would you agree to release your source code if for some reason (from our experiences life is full of those unexpected reasons, for the worst but also the best) you don't have time or motivation to keep working on this project ? ?

Absolutely yes. More than happy to do that preemptively too, just want to be able to have a viable product first. As it stands I am thinking to rease some beta, or if people are interested I will share with them individually for beta testing first. Once this is complete and bugs eliminated more than happy to upload the source seperately!

 

[Mr Martian]

Just link the crew members in your add-on to health/skill data in an roleplaying game like framework for adding NPCs. So, I only require as little support and data from your end to include them, and later figure out, how many public parameters my model would need to support to allow exchanging astronauts with other frameworks.

In the best case, it could be a hidden binary handle parameter, that isn't meant to be displayed - or if you support string attributes (like the name), I could simply format the primary key into some string format (base64? Hex? Magic?) and use this for linking the astronaut to the data of the framework plugin.

And for the licence, its just the usual "Is it FOSS or do I risk getting vendor-locked?" question.

Crew information is stored in a struct. the struct is then transmitted from ship to ship or ship to EVAed crew (things like name, age, weight, etc) I could incorperate a handle in that too, but given the architecture of the project I am not sure how useful the handle will be, if that makes sense. If you like I can go into more detail about the structure over private message?

 

[Urwumpe]

Crew information is stored in a struct. the struct is then transmitted from ship to ship or ship to EVAed crew (things like name, age, weight, etc) I could incorperate a handle in that too, but given the architecture of the project I am not sure how useful the handle will be, if that makes sense. If you like I can go into more detail about the structure over private message?

No, if you need to make special code changes for that, that scrap it for now. There are more urgent features. All I really need is a possibility to set and read key-value-pairs essentially, it would make life much easier, since I can then ignore a lot of the process of transfering astronauts from vessel to vessel.

 

[Max-Q]

I vote for OrbiterCrews! This sounds absolutely amazing, cant wait!!!! Will it be UCSO compatible, so astronauts can unpack/move cargos?
May I suggest you have a way to set the astronaut's birthday? That way, crews would get older on long trips.

 

[Thymo]

OrbiterCrews sounds nice. I applaud your effort in bringing a new EVA SDK to Orbiter. I'm excited to try it out.
I do hope you seriously consider making it open source for above mentioned reasons. NASSP could desperately use more advanced EVA functionality and if it is released under a GPL-compatible license we surely can make some contributions back to make both addons better. Unfortunately we won't be able to consider its adoption if you decide to keep it closed.

 

[WolfAngriff]

Hi !

This is the best thing to read since Orbiter 2016 release !

As a true never-happy-end-user (NHEU), i'd like to see those guys and their stuff in all the crewed vessels. But i know it would'nt be possible. So i think it would be a good thing to make it possible to implement in vessels as easily as possible. Because everyone knows a true NHEU does'nt know anything about coding and modeling, and will exclusively use the addon you didn't think about . More seriously, a few lines in a .ini file or .cfg file will be mandatory, of course. If it could be something to copy/paste with a number of variables to fill, it should be the best solution from the NHEU point of view.

With this addon, gameplay as survival and role playing will come back to Orbiter without changing it's core, so long awaited !

Thanx for your efforts !

If you need french translation for the docs, just ask !

 

[Mr Martian]

I vote for OrbiterCrews! This sounds absolutely amazing, cant wait!!!! Will it be UCSO compatible, so astronauts can unpack/move cargos?
May I suggest you have a way to set the astronaut's birthday? That way, crews would get older on long trips.

Hi Max-Q,

I was not aware of USCO up until just now! I will look into this for sure. Currently I have the crews able to 'pick up' items using an attachment point. Cargos could be coded as a vessel class, and 'unpack' on activation of an interface area (see first post of this thread), but I will check out the USCO API and see if I can't implement this!

Regarding ageing, I have implemented the age as a double, and a function to place in a vessel's clbkPreStep, as it stands, declaring this will make crews age (not through date modification in the scenario editor however). This method means hypothetically the ageing function could be declared variably to simulate some kind of rudimentary hybernation for crews.