Discussion Developing Addons for different Orbiter Versions

[Face]

* In the long run, I want to move away from the concept of bases, and instead implement surface structures as an additional quadtree layer. In that context, a base wouldn't be a physical entity, but just happen to be a place containing an assembly of buildings and runways/pads. (the latter possibly not defined as a structure, but just as part of the surface textures).

This means that there is already a pressing need for a tree merging/diffing tool. Without it, rollout of base development would be even more difficult than it is now.

As a base developer, you'd have to distribute a tree diff that users can merge into their global tree. To make it also easily removable, a concept of a inverse diff must be possible, so users can uninstall it without having to download/extract the complete pristine tree again (and potentially losing other addon patches in the process).

 

[martins]

As a base developer, you'd have to distribute a tree diff that users can merge into their global tree. To make it also easily removable, a concept of a inverse diff must be possible, so users can uninstall it without having to download/extract the complete pristine tree again (and potentially losing other addon patches in the process).

Tree merging would indeed be a very useful feature, not just for a future surface structure layer.

Alternatively for the surface structure layer at least, it may be possible to do the merging at runtime by Orbiter itself, since unlike the other layers this is fairly trivial (just add the surface structure from all available trees for this tile). In that case, every base would come as its own sub-tree file.

This may even make it possible to do a simple LOD approach. If the global tree already has some simple structures for a particular base, an addon could provide a detailed base definition only for the high-resolution tiles, keeping the simple version at low resolutions for efficiency.

 

[Face]

Alternatively for the surface structure layer at least, it may be possible to do the merging at runtime by Orbiter itself, since unlike the other layers this is fairly trivial (just add the surface structure from all available trees for this tile). In that case, every base would come as its own sub-tree file.

It's a bit sad that this approach is not so trivial with the other layers. I think the possibility to encapsulate addon content into confined files - like it was in the past with the exception of base.cfg - makes for a much better addon-developer experience.

So in that light I would vote for a consistent approach, i.e. either have it covered by offline tools with inverse diff capability for uninstall, or get it done in the core by means of runtime merging, but then for every layer.

 

[Urwumpe]

* In the long run, I want to move away from the concept of bases, and instead implement surface structures as an additional quadtree layer. In that context, a base wouldn't be a physical entity, but just happen to be a place containing an assembly of buildings and runways/pads. (the latter possibly not defined as a structure, but just as part of the surface textures).

Will it still be possible to address the bases / pads in the scenario file as short cut for surface coordinates?

Or should we steer away from it already to permit a simpler transition later?

 

[4throck]

* In the long run, I want to move away from the concept of bases...

OK, that's consistent with the way 2016 behaves :thumbup:
No complaints here, and I welcome the road-map.

I'd even go further and depricate the base objects already. This might prevent false expectations and wasted time.

 

[martins]

Will it still be possible to address the bases / pads in the scenario file as short cut for surface coordinates?

Or should we steer away from it already to permit a simpler transition later?

I haven't thought about that yet, but there is no any immediate rush to change anything here. Maybe the base/pad number reference can be replaced by a location identifier that can be added to the quadtree tile, to avoid having to enter the location in the scenario file by hand.

In any case, this particular issue is fairly easily mitigated: If you load a scenario containing base/pad location references and immediately save it again, it converts the references to raw coordinates (I think).

 

[Urwumpe]

In any case, this particular issue is fairly easily mitigated: If you load a scenario containing base/pad location references and immediately save it again, it converts the references to raw coordinates (I think).

Yes, right now that is the best way to get the pad coordinates. Or create a basead scenario and use scenario editor for fine tuning.

Having some camera position marker there would be likely enough.

 

[gattispilot]

I think what user what is every orbiter add on to work with every version. Nice thought but not reality.

For me the big one that isn't working and may never work ins UMMU.

I have tried to use GV and a guy mesh and it does move. But no pick up,.........
But I tried and failed to add press the key the gvguy would appear on the ground like UMMU.

 

[Face]

I think what user what is every orbiter add on to work with every version. Nice thought but not reality.

For me the big one that isn't working and may never work ins UMMU.

The problem of forward compatibility is a very classic one in software development. It is almost impossible to achieve without severely restricting future development.

One solution to this problem especially in an open ecosystem is... surprise, surprise... having an open source culture. Even Microsoft - stubborn a company as it was - realized that before taking the dive.

The Orbiter community will have to realize this as well, or it will suffer the consequences, some of them already showing. And believe me, begging Martin to stop adding awesome features to the core in order to keep addons working will NOT be the solution.

:shrug:

 

[gattispilot]

The problem of forward compatibility is a very classic one in software development. It is almost impossible to achieve without severely restricting future development.

One solution to this problem especially in an open ecosystem is... surprise, surprise... having an open source culture. Even Microsoft - stubborn a company as it was - realized that before taking the dive.

The Orbiter community will have to realize this as well, or it will suffer the consequences, some of them already showing. And believe me, begging Martin to stop adding awesome features to the core in order to keep addons working will NOT be the solution.

:shrug:

Agreed. But for me with the Interstellar System stuff and Space 1999 sure I can update for 2016 but would have to remove all UMMU stuff

 

[Face]

Agreed. But for me with the Interstellar System stuff and Space 1999 sure I can update for 2016 but would have to remove all UMMU stuff

Sure, but please also speak out the reason for this loud and clear: UMmu is closed source, and the author does not want to update it for 2016. You were happy enough to jump on the band-wagon without thinking about the consequences of being locked-in. Remember the peer-pressure "does it have UMmu"? That is what I mean with culture.

If you have one where people don't touch things like SC3 or UMmu precisely because it is too much lock-in, and instead support folks like fred18 or Woo who work on more open platforms, you would not have that dilemma.
But as it was for a long time - and still is now - it is exactly the opposite. Dammit, there is even a kind of zombie obedience regarding things like SC3.

I for one welcome our new terrain overlord and will not look back at 2010. God, it's soon a decade old.

 

[gattispilot]

Agreed closed source is an issue.

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

 

[Face]

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

Why is the fact that the work is volunteer a big BUT?

Open source is not only that the code is included, but also that you can modify it and share this modifications. In a way, even Orbiter's code is available: the machine code. I was able to read it and understand certain aspects of Orbiter's internals. However, I am not allowed to change this code and share the changed version with others, e.g. to put a new API callback into it in order to make collision detection tile loading modifiable.

 

[gattispilot]

Why is the fact that the work is volunteer a big BUT?

Oh thanks
For me it is because perhaps the standard might be less than a paid pro job. Just my thoughts

 

[Face]

For me it is because perhaps the standard might be less than a paid pro job.

Huh? What does this have to do with closed-source vs. open-source view points? It is not like people get paid for developing Orbiter addons, where it would make sense to bring this as a BUT.

 

[Donamy]

I am so hoping VB will replace SC3.

 

[gattispilot]

Huh? What does this have to do with closed-source vs. open-source view points? It is not like people get paid for developing Orbiter addons, where it would make sense to bring this as a BUT.

Not sure. But I see your point. If all the addons were open and allowed to change. That might be nice.


So how to make that happen on stuff I make?

 

[Face]

If all the addons were open and allowed to change. That might be nice.


So how to make that happen on stuff I make?

First of all: abandon closed source middle ware. Stop developing for SC3/4, OS, UMmu, UCGO, and whatever closed source thing there is, no matter how shiny it might be. If available, choose the open-source alternative, if not available, do as if there is no such thing at all.

Be clear about why you do not use a certain closed source platform. If fans complain, explain why sticking to this will actually slow down development in the long run. If they don't understand, explain the SC3 debacle. If they still don't understand, explain the OS debacle. If they still nag you, ignore them.

Support folks like fred18 as best as you can. Create your addon exclusively for their open platforms, and be loud about why you do it. If it is not immediately showing the feature you absolutely want, help by means of contributing code, no matter how crude you might think it is.

Nobody will make this change for you, you have to do it for yourself.

 

[gattispilot]

Thanks.

But as a developer how do I make it open source and sharable.

 

[Face]

But as a developer how do I make it open source and sharable.

By expressing your will in the documentation. Most call it a license. There are many different open source licenses out there that you could take as inspiration, one particulary simple one being the MIT license.