Discussion Developing Addons for different Orbiter Versions

[Urwumpe]

Agreed closed source is an issue.

At least for frameworks and middleware. There it should be mandatory, unless it is YOUR own framework or YOUR own middleware. I could know what is inside the XR-series, but don't really care as long as it works.

BUT most of not all the work is volunteer. By open source I think you mean the code is included, right

Not to get this wrong. It is not about being unthankful about the voluntary contribution to the community. I know the tone of the discussion goes easily in that direction, but its sure not meant to be that way.

It is just: Basing your own add-ons on the closed source work of somebody else was a risk and that risk now got invoked.



Also, open source is not the same as including the source code. Open source is also the permission to continue work with that source code, modify it and release it again. And thus, it is more than just the source code, but also a work ethic: You develop your add-on with the other and later developers in mind. You write more comments, document your work processes, explain decisions better than you would do for closed-source work. All to make sure, your work can go on with other people arriving and to make sure even decades later, people will know your intentions and vision and respect it.




The show must go on.

 

[4throck]

I too support the notion of open source but limited for usage on Orbiter, no use elsewhere. I don't want my meshes and textures ending up on other places.

This can work based on OH. Not a perfect solution but it's better to start with what we have.
So we could upload a "Orbiter Licence" to OH (a text document really) and add-ons that use it only need to link it as "required"

For multiple similar releases, we can always check by date to see what came first.

 

[Urwumpe]

I too support the notion of open source but limited for usage on Orbiter, no use elsewhere. I don't want my meshes and textures ending up on other places.

You could also use a different license for artworks (the branding of a program, after all).

Just remember though, that this makes it harder to continue development, which runs contrary to the open source idea. Not impossible, but essentially you can in the worst case force people to reverse engineering despite having your source code.

One well working solution there is having an organisation behind official main line development, that has the copyright for the artwork and ensures the official development continues, even after the EOL of the artist.

Another option could be having base line graphics, that are open source and available to all, and use specially branded artworks for the releases.


(Having an open-source framework in Orbiter to allow swapping a set of artworks without needing to change the add-on module would be a great tool there - maybe I can take a look there.)

 

[4throck]

Yes, something like that would be great.
Could be as simple as loading assets from an alternate folder...

This would be better than just releasing a repaint that overwrites the original work...

That's one of the things we should solve: file overwrite and folder clutter.
We should have a rule for development that stating that all assets must be loaded from addon specific folders. Never from "textures" or "meshes" directly...

 

[Urwumpe]

That's one of the things we should solve: file overwrite and folder clutter.
We should have a rule for development that stating that all assets must be loaded from addon specific folders. Never from "textures" or "meshes" directly...

I agree - actually I do this in most of my projects because of that. We had something like a "add-on etiquette" once in the past, with lots of those simple rules.

https://www.orbiterwiki.org/wiki/Add-on_etiquette

 

[Donamy]

I hope you don't mean retro-active. :shifty:

 

[Urwumpe]

I hope you don't mean retro-active. :shifty:

What do you mean with retro-active?

 

[GLS]

What do you mean with retro-active?

Addons that have already been released? :shrug:

 

[Urwumpe]

Addons that have already been released? :shrug:

Well, why not? If they are open-source?

 

[Face]

This can work based on OH. Not a perfect solution but it's better to start with what we have.
So we could upload a "Orbiter Licence" to OH (a text document really) and add-ons that use it only need to link it as "required"

We had this discussion already years ago, and nothing happened. Why should it be different this time?

 

[4throck]

Good :thumbup:

This will be even more important if we go open source and redistribute things. Thinking about those dozens of DG repaints.

So "your" tool to manage asset swapping would be great here.
On the scenario for example:

ALT_TEX_FOLDER shuttles\early

 

[Urwumpe]

Good :thumbup:

This will be even more important if we go open source and redistribute things. Thinking about those dozens of DG repaints.

So "your" tool to manage asset swapping would be great here.
On the scenario for example:

ALT_TEX_FOLDER shuttles\early

Hmm... would this be possible? I would need to replace the texture loader then....

 

[4throck]

I'm just interpreting "(Having an open-source framework in Orbiter to allow swapping a set of artworks without needing to change the add-on module would be a great tool there - maybe I can take a look there.)"
For me that reads as texture and mesh replacement

 

[n122vu]

It is just: Basing your own add-ons on the closed source work of somebody else was a risk and that risk now got invoked.

It's always been a risk though with developing addons for Orbiter. Not that he would do so maliciously, but Dr. Schweiger could at any time make, and has made, a change to the core that effectively breaks the best of addons (UMMu being the example). Broken addons that relied on UMMu are actually just a daisy-chain, or domino effect of that change. An open framework alternative for UMMu would allow someone in the community to fix that particular problem, but the fact remains we're developing addons for a closed-source work. it's no different than developing addons for X-Plane 11 or P3D. At any time they could make a change to the core sim that breaks something on an aircraft I love to fly. The difference here is we don't all have our own team of developers on-staff to jump on things, test, and release an update for the latest version with each change. Do I go back to X-Plane 10 because I know all my addons work and the sim is stable and locked? Not so much recently, but I have in the past simply because something in X-Plane 11 was not working and a fix was in the pipeline, but I wanted to fly in the meantime without having to reinstall the entire sim up to a previous version.

I'm 100% for open source and releasing source code with addons, but until the core itself becomes such, this risk will remain. That's not a complaint, nor a criticism of martins, just a statement of fact.

 

[Urwumpe]

I'm just interpreting "(Having an open-source framework in Orbiter to allow swapping a set of artworks without needing to change the add-on module would be a great tool there - maybe I can take a look there.)"
For me that reads as texture and mesh replacement

I rather thought of having a way to describe meshes and animations outside the DLL, so even the 3D modeller himself (or his design tool) could create the needed input file and how to replace the artwork is then just a matter of how restrictive the vessel module likes to be.

In the simplest way, you just change the reference to the artwork description in the cfg file. So, for example, you have a "ssu.artwork" file with the definitions of the main SSU project and a "ssu_community.artwork" for the project that contains just basic textures and meshes that are free to use for modification and re-release.

In the best case, those artwork files could be cryptographically signed and encrypted together with the meshes, so they can not be modified except by those who know the private key.

Of course, adding a repainting support would also be possible then, if you know all loaded meshes of a project and can apply replacement rules. Just using the list of meshes in a visual might be lacking the needed meta-data there - which mesh is now which, we have no file names, no group names.

For example then, you could chain artwork files - the repaint artwork file only specifies the folder of the new textures and references to an encrypted master artwork file, that permits repainting in its rules.

 

[Face]

It's always been a risk though with developing addons for Orbiter. Not that he would do so maliciously, but Dr. Schweiger could at any time make, and has made, a change to the core that effectively breaks the best of addons (UMMu being the example). Broken addons that relied on UMMu are actually just a daisy-chain, or domino effect of that change.

I think this is a good argument against the statement you quoted, but only if seen in isolation.

The problem at hand is not that somebody broke some interface in the daisy-chain, but the very chain itself by refusing to update the middle-ware that affects many addons downstream. If you want to compare it, it would be better to do so with Martin not wanting to change the graphics driver, up to a point where the OS doesn't support Orbiter anymore. He almost was at that point, but solved it by open sourcing it.

 

[4throck]

Indeed, but just let me add that TIME is important here.

a) Time to keep retro-compatibility
b) time create a new version
c) time to update to the new version.

Our "problem" is time, not the decision between a, b or c.

2016 is past the point where you could create a good add-on over a weekend. So the solution is automation (using things like Multistage or Vessel Builder) and possibly open-source (or whatever enables cooperation).

 

[GLS]

2016 is past the point where you could create a good add-on over a weekend. So the solution is automation (using things like Multistage or Vessel Builder) and possibly open-source (or whatever enables cooperation).

Orbiter 2016 has many more capabilities that Orbiter 2006 did, and what was a good addon in 2006, simple enough to develop during the weekend, now might look "cheap" in 2016 due to all the new things available (code and graphics). All part of evolution IMO.

I don't think the dev process got harder in Orbiter 2016, at least for vessels. The 3D modelling part is the same as it was, and creating animations is unchanged. The code part is also pretty much the same: the user now needs to define more touchdown points so the ground collision works, and define the damping parameters, but IMO that's part of using a more recent version. It's not like a vessel in 2016 needs a totally different implementation from previous versions.

Anyway, automation is always welcome as it provides an easier path to development. I agree with Face: the trick is keeping the "middle-ware" updated, and having it open-source makes that possible.

 

[Urwumpe]

Also, already in 2010, the old 2D panel mechanism got replaced by the new and better Panel2D system that also works better on rendering clients.

Yes, it is a bit more complicated than just painting bitmaps. But it improved performance a lot and was made for the future.

The lack of a middleware just means that every developer had to invent the wheel there.

 

[indy91]

Also, already in 2010, the old 2D panel mechanism got replaced by the new and better Panel2D system that also works better on rendering clients.

Yes, it is a bit more complicated than just painting bitmaps. But it improved performance a lot and was made for the future.

The lack of a middleware just means that every developer had to invent the wheel there.

Yeah, that's where NASSP still stands. We are using the old 2D panel mechanism. Which seems to perform worse in Orbiter 2016 than it did in Orbiter 2010, CPU wise. W have a multiple of bitmap panels and basically every switch in the CSM is functional (with even more bitmaps for that) so changing the system is going to be a big step. It's probably going to be a direct step to a 3D panel, with the old 2D panel staying in place until the 3D panel has completely replaced it. Probably no reason to go to an intermediate Panel2D system, unless that is easier than I am imagining it. Converting bitmaps or creating new meshes etc. If someone wants to spend a year of their time on this project, you are welcome to join the NASSP team, haha.

I wanted to make a long post in this thread about how the general Orbiter 2016 experience has been for us NASSP developers but I never found the time. So here the short version. It has been a struggle in the beginning, especially the changes to PreStep and PostStep and the touchdown points took a long time to sort out. But it's definitely worth it, landing on the Moon is just on another level in Orbiter 2016. I also still hope to build a version of NASSP 8 for Orbiter 2010; while you won't be able to do everything in 2010 (docked PMI are bad) it shouldn't been too much effort to do this. And I really hope there is going to be a stable Orbiter 2016 patch release (e.g. Orbiter 2016P1) soon so that we don't have to release NASSP 8 for the Orbiter Beta only, which is not super convenient to set up. Orbiter 2016 still has the same (and more) issues as 2010.