Idea Orbiter Community API

[Urwumpe]

Mind your language my friend.
Idiot is offensive on my book, regardless of being directed at me or not.

Read up on the term "idiotes" in the ancient greek world. I mind my language. I really subscribe to the term in that context, because I really mean "self-centered persons lacking professional skills".

And yes, UMMU for velcro makes sense. Have you ever used Velcro Saturns? There's a Velcro LEM....

And? THAT is really a problem for you or somebody else? You can also use attachments with Velcro, it is not limited to the old historic CVEL interface of the past before attachments.

You mostly need such a "community standard" for fixing problems, that you wouldn't even have without such a standard.

 

[Linguofreak]

They are, in shape of Genericvessel.
With permission from Vinka, no less.

And not just backwards compatibility, but extension of it.
UMMU is already supported, for example.

All it would take is a push to get it up to full SC3 compatibility, and there you have it.
I'm about to post an updated version with all the fixes ported back from SW, so it's not even all that far-fetched.

OK, let's assume that Genericvessel will be the wrapper library for vessel-oriented parts of OCAPI.

One of the major things that causes interoperability issues is the fact that a stock Orbiter config file can only specify one module. Would it be possible for Genericvessel to have a config file line of the form "HelperModules = Foo, Bar, Baz" to specify modules that provide functionality for the vessel beyond what Genericvessel implements? This would be a highly desirable feature for the core OCAPI module for each module type (vessel, planet, etc).

 

[Urwumpe]

When has this ever happened?

Quite frankly I think the idea is fine, although it will be a lot of work. Projects like these tend to work better when done in small individual packets, like UCGO, UMMU, Orbitersound, and Camshake. If one component can work effectively on its own, no work will be wasted if one feature ends up being a dead end.

I consider those all the "one size fits all solution" its unrealistic, limited and often causing more trouble in the design, than it helps to solve.

Take camshake. It doesn't care about my add-on and I can't control it. I only use it, if I need a stupid cam shake effect, that I have not yet implemented. So, usually never.

This discussion all goes into the same direction: How can we enable more people to make more and much worse add-ons?

Generic vessel could be the optimal solution for non-programmers. LuaVessel is great for those who can program a bit.

Why overload this all now with some strange pseudo-standard, that only makes developing good add-ons harder?

Really: I have never seen worse crap than the spacecraft3 add-ons. They look mediocre and play bad. You can stick great meshes there. And ruin them that way, because players have not only to fly a mission, but also hit some number keys in the right order to prevent badly designed animations from fowling up - you execute essentially add-on software on the brain of the player. Great. Back to the stone age.

Where is the discussion about that? How will a standard that only strengthens the weaknesses of the generic add-on module population really improve the situation?

Why not for example suggest that genericvessel could implement Lua event handlers for it, so it is easier to customize genericvessel add-ons?

Why not rather work on a framework of really useful low-level code objects to make developing DLLs simpler, instead of kerbalizing Orbiter?

Why not just do things, instead of talking about standards that should only apply to other people?

I think I said enough here about my opinion, who has to complain about my POV, should better do it via PM, instead of encouraging me scaring potential add-on developers away. :facepalm:

 

[Loru]

I'll ask that again. Why can't it be done within existing standard??? Genericvessel already provides sc3 with UMMU. Adding multistage support and cargo management will result exactly in what you're proposing. Project is not dead and is opensource so why in the name of probe coming up with another standard? Why not focus instead on building on already laid foundation? Foundation that can be expanded?? Yes abstraction layers are fun but then you reach the point you have onion insted of spaceflight simulator.

As for velcro: yes - I used this tool. My first add-on is velco stage for DG but apart from meshes velcro is virtually the same text file as multistage is - few parameters differ and few have just different name. Converting vessel from velcro to generic vesselcan be done in probably less than 10 minutes.

 

[Donamy]

We try to make the best crap, with what we have.:uhh:

 

[Linguofreak]

Like requiring UMMU for Velcro.... HELLO? :facepalm:

When did I ever say anything about requiring UMMU for Velcro? Under OCAPI, UMMU and Velcro (assuming they were the modules used by OCAPI for their particular functionality sets) would remain independent modules, and developers could use either independently in an addon. They could also use both *if* they felt that the planned feature set for their addon required it.

If a developer were developing a vessel that was manned, but could benefit from being a Velcro stage (such as [ame="http://orbithangar.com/searchid.php?ID=2569"]this[/ame], or maybe an S-IVb derived manned ), the developer would be able to use both UMMU and Velcro in the same vessel.

 

[Face]

What I see here is a proposal of a huge undertaking, outlined in a few sentences along the lines of "let's make everything communicate with everything else... somehow". TBH, I can't really see a picture beyond that one-fits-all scheme. The discursive advices here don't help it, either.

Linguofreak, perhaps it would be better if you mold your vision into a small prototype and come back to discuss it based on code (even if it is rudimentary). I think great ideas without some hands-on experience often are ridiculed because of misunderstandings. Like with drawings being the best technician talk, I guess code is the best computer scientist talk.

my :2cents:

 

[Linguofreak]

What I see here is a proposal of a huge undertaking, outlined in a few sentences along the lines of "let's make everything communicate with everything else... somehow". TBH, I can't really see a picture beyond that one-fits-all scheme. The discursive advices here don't help it, either.

Even "let's make everything communicate with everything else" is a broader scope than what I'm really after.

I'll distill what I'm after to this one sentence:

The core idea of OCAPI is "let's make sure modules that provide different functionalities don't exclude each other".

The interoperability I'm talking about here is passive: Except for the modules that implement the OCAPI framework itself, an OCAPI module need not be aware that other OCAPI modules exist, let alone communicate with them, but two OCAPI modules whose functionalities don't overlap should be able, by interacting with the core OCAPI framework, to provide functionality to the same vessel/planet/MFD/whatever whether or not they're aware of each other.

I may have confused you somewhat by talking about including an intermodule communication library in OCAPI, and not differentiating sufficiently between (A) The interoperability framework itself, and (B) The set of modules built on top of that framework providing standard implementations for various functionalities not built in to Orbiter itself (such as staging, crew/EVA, cargo, etc).

Intermodule communication would be a desirable component of (B), but would not necessarily be a part of (A).

 

[Face]

I'll distill what I'm after to this one sentence:

The core idea of OCAPI is "let's make sure modules that provide different functionalities don't exclude each other".

The interoperability I'm talking about here is passive: Except for the modules that implement the OCAPI framework itself, an OCAPI module need not be aware that other OCAPI modules exist, let alone communicate with them, but two OCAPI modules whose functionalities don't overlap should be able, by interacting with the core OCAPI framework, to provide functionality to the same vessel/planet/MFD/whatever whether or not they're aware of each other.

That doesn't go together IMHO.

Almost every functionality will overlap in some way except mere displays of information, because the vessel it operates on will change states. So if you e.g. have an autopilot feature and some MFD with attitude-hold or somesuch, they might compete with each other for the RCS control. Or if there is a trader plugin that manages your UCGO cargo stack, and a plugin like Universal cargo-deck, they might present an incoherent cargo inventory, or even crash due to mechanics inside UCGO.

In the end, you will need some form of plugin communication, may it be active by means of interfaces or passive by means of a complicated property/version/compatibility description like with package managers.

Really, please show us some code so we can discuss this more in-depth. As it is now, there is too much vague stuff to seriously comment on.

Or perhaps start with a user-story. How do you think the system should work in your favorite case of Velcro and UMmu? Describe what the developers of Velcro and UMmu, respectively, will have to do to make it fit in your vision. And please be specific, "they have to implement OCAPI interfaces" is just the specification's equivalent of business language - hollow and without commitment. It doesn't have to be a set-in-stone function signature, just something along the lines of "an OCAPI module has to link to the OCAPI lib and register on load, then submit its properties and descriptions, then whenever a vessel is created in simulation, the OCAPI framework informs all modules of the vessel's preferences (what modules should be support)". And so on, I think you get what I mean. Cover all roles from OCAPI framework maintainer over module (or wrapper) and vessel developers up to end-users.

In other words: don't just setup a bunch of requirements (everybody wants that everything JustWorks(TM), anyway), instead describe how this requirements could be met with implementation.

I know that this sounds like much work, but at this scope, I'm afraid your idea is not really sound yet.

regards,
Face

 

[Linguofreak]

Or perhaps start with a user-story. How do you think the system should work in your favorite case of Velcro and UMmu? Describe what the developers of Velcro and UMmu, respectively, will have to do to make it fit in your vision. And please be specific, "they have to implement OCAPI interfaces" is just the specification's equivalent of business language - hollow and without commitment. It doesn't have to be a set-in-stone function signature, just something along the lines of "an OCAPI module has to link to the OCAPI lib and register on load, then submit its properties and descriptions, then whenever a vessel is created in simulation, the OCAPI framework informs all modules of the vessel's preferences (what modules should be support)". And so on, I think you get what I mean. Cover all roles from OCAPI framework maintainer over module (or wrapper) and vessel developers up to end-users.

What I was thinking was something along these lines (I haven't done any module-based addons for Orbiter, aside from one unreleased MFD back in the M6 days, so this may betray some misunderstanding on my part of how the Orbiter API works):

A vessel uses the line "Module = OCAPIVesselWrapper" in its config file, or specifies a custom module that links to the OCAPI vessel wrapper, followed by a line something like "HelperModules = Velcro, UMMU". When an instance of that vessel is created and Orbiter calls OCAPIVesselWrapper to set it up, OCAPIVesselWrapper reads the HelperModules line, checks to see if the Velcro and UMMU modules are available (which they should be, if they're both part of the standard OCAPI distribution, otherwise the user needs to download the appropriate modules and activate them in Orbiter), and if they are, links to them (here Velcro will need to be modified to allow OCAPIVesselWrapper to link to it, UMMU already can be linked to by a vessel module) and points them at the new vessel instance in-simulation and at the config file. Velcro then proceeds to read and process config file lines specific to it as it already does, then UMMU reads and processes config file lines specific to it (AFAIK this will require some modification to UMMU, although Genericvessel seems like a good candidate for OCAPIVesselWrapper, and according to Artlav already wraps UMMU, so it may not even be necessary to include UMMU in the "HelperModules" line, or to modify it, if Genericvessel can generate a UMMU vessel from a config file already).

I'm out of time for now, more later.

 

[Face]

A vessel uses the line "Module = OCAPIVesselWrapper" in its config file, or specifies a custom module that links to the OCAPI vessel wrapper, followed by a line something like "HelperModules = Velcro, UMMU". When an instance of that vessel is created and Orbiter calls OCAPIVesselWrapper to set it up, OCAPIVesselWrapper reads the HelperModules line, checks to see if the Velcro and UMMU modules are available (which they should be, if they're both part of the standard OCAPI distribution, otherwise the user needs to download the appropriate modules and activate them in Orbiter), and if they are, links to them (here Velcro will need to be modified to allow OCAPIVesselWrapper to link to it, UMMU already can be linked to by a vessel module) and points them at the new vessel instance in-simulation and at the config file. Velcro then proceeds to read and process config file lines specific to it as it already does, then UMMU reads and processes config file lines specific to it (AFAIK this will require some modification to UMMU, although Genericvessel seems like a good candidate for OCAPIVesselWrapper, and according to Artlav already wraps UMMU, so it may not even be necessary to include UMMU in the "HelperModules" line, or to modify it, if Genericvessel can generate a UMMU vessel from a config file already).

Now it gets clearer, thanks. Let me try to unroll that a bit:

1. "A vessel uses the line "Module = OCAPIVesselWrapper" in its config file, or specifies a custom module that links to the OCAPI vessel wrapper.." - So is it a generic vessel implementation or a library with functions for vessel implementations to use?
2. "followed by a line something like "HelperModules = Velcro, UMMU". When an instance of that vessel is created and Orbiter calls OCAPIVesselWrapper to set it up, OCAPIVesselWrapper reads the HelperModules line,.." - This could be implemented by vessels without the need for a wrapper.
3. "checks to see if the Velcro and UMMU modules are available (which they should be, if they're both part of the standard OCAPI distribution, otherwise the user needs to download the appropriate modules and activate them in Orbiter), and if they are, links to them (here Velcro will need to be modified to allow OCAPIVesselWrapper to link to it, UMMU already can be linked to by a vessel module).." - What does "activate in Orbiter" mean? Should they be plugins to be activated in the modules tab? Also, what does "link" mean? UMMU can't be linked to a vessel by configuration, it is a library with functions for vessel developers to use in their code. Do you mean that every OCAPI module must use a generic approach, kind of like UMMUFA provides UMMU capabilities for all vessels in a scenario?
4. "and points them at the new vessel instance in-simulation and at the config file. Velcro then proceeds to read and process config file lines specific to it as it already does, then UMMU reads and processes config file lines specific to it (AFAIK this will require some modification to UMMU,.." - So every OCAPI module must use a passive instead of a dynamic configuration approach, aka INI-file vs. implemention, if I understand this correctly.
5. "although Genericvessel seems like a good candidate for OCAPIVesselWrapper, and according to Artlav already wraps UMMU, so it may not even be necessary to include UMMU in the "HelperModules" line, or to modify it, if Genericvessel can generate a UMMU vessel from a config file already)" - Genericvessel indeed implements UMMU features, but it is by far not a full representation of UMmu's capabilities. And it will never be, because you can't implement things like Doug's XR-UMmu features through a configuration description language without it becoming a Turing-complete language in the end. I can't really speak for Artlav's vision of genericvessel, but to me it is at first an SC3 successor that wants to grow with Orbiter, not a replacement for C++. This is perhaps one of the reasons people dismissed your proposal so quickly: it tends to become the lowest possible denominator.

Let me try to summarize this a bit in my own words, just to see if I got your idea better this time:

1. OCAPI is basically a generic vessel with a domain specific language (DSL) behind it.
2. The OCAPI DSL is simple: it resembles Orbiter's configuration file syntax and has only one element: "HelperModules". All other configuration file elements will be ignored.
3. The HelperModule element is a list of keys that specify other generic vessels, also called OCAPI modules.
4. These generic vessels are loaded at run-time, initialized with the appropriate configuration file for that vessel, then started to do whatever they do.
5. This approach is taken because even with the existence of multiple generic vessels for different features, a developer can only specify one single generic vessel implementation.

If I got that right, your initial problem triggering this proposal is the lack of a possibility to combine multiple generic vessels. However, I think you misinterpreted UMmu for a generic vessel feature. You'd have to implement one based on UMmu functions first.


What I don't understand here is the bias towards generic vessels. You can already create a generic module implementation that gets activated in Orbiter's module tab, which could then work on all vessels in the scenario. Give it a vessel-based DSL and you are set. You could postulate that only such modules should be implemented, so everybody can benefit from it just by activating multiple generic modules. There is absolutely no need for an additional common interface beyond OAPI, then.


regards,
Face

 

[Urwumpe]

What I don't understand here is the bias towards generic vessels.

I think it is just because you are much faster used to the concept, even if it is the wrong concept for solving a problem.

Its like mathematics at school. First you learn to count and do simple calculations, then you are usually drilled by the school system to calculate faster and faster until you come into the higher classes and are forced to suddenly learn how to think first before you calculate.

Thus, many people and even many computer science students will do what they know best when they see a formula. They will calculate it, even if reading the task again and thinking first about the implications of the task will result in them being able to finish the task without a single calculation, just be writing a single short sentence of the definitions and concepts that apply.

I think the approach with generic vessels is the same. You first see what you want to do, and then implement it in spacecraft3. And then tweak and fix things around this solution, despite it getting more and more complicated. And that only because you did not think first about the task that you actually want to do.

Also, by the way how Orbiter operates, you need at least one single blank configuration file to let it create a single blank vessel with the generic module.

But otherwise, it should all work fine.

 

[Face]

Also, by the way how Orbiter operates, you need at least one single blank configuration file to let it create a single blank vessel with the generic module.

Well, a vessel developer will anyway need a configuration file to put the configuration items for the appropriate modules in. The end user will then have to activate all the modules addressed in the vessel configuration file to actually see something.

 

[jedidia]

because you can't implement things like Doug's XR-UMmu features through a configuration description language without it becoming a Turing-complete language in the end.

You could make generic dialogs for better control of such features, however (not just UMMU, also robotic arms for example). This way the keystroke overhead could get reduced a bit...

 

[Face]

You could make generic dialogs for better control of such features, however (not just UMMU, also robotic arms for example). This way the keystroke overhead could get reduced a bit...

Sure. This is just not the same as a neat custom button in a VC. And if we are at it, what about O2 consumption with people on board, what with safe-mode, crash detection, etc. ? Since UMmu is a function library, you can't please all needs with a generic implementation.

What about implementing UMmu right into Velcro, though? This seems to be the only case put up as example for this idea here so far.