Discussion Simulator Abstraction Layer?

[Fizyk]

ADHD version: I propose to make an add-on API to end all add-on APIs. Can you think of a way to do it that won't be a wasted effort?

First thing that came to my mind:

 

[RacerX]

As a non coder myself at first glance I think it is a great Idea Artlav. But Fizyk does bring up a good point. Where does it end? It reminds me for instance of me and my wife buying our first house. We had plans of what renovations we wanted to do with the house. The more we did to the house the more we discovered as work progressed more renovations got put on top of the previous renovations. And it became a never ending project constantly needing to be upgraded the more we improved the house. Ohhh the "honey do's" are never ending :facepalm:

 

[jedidia]

The trouble is, I kinda like to go where noone has gone before. So far I have only contributed two add-ons to the orbiter community (both unfinished), but in both I tried to do something that simply wasn't there. One of them, as you well know, basically an attempt to turn Orbiter into something like Spaceway (and quite frankly, it wouldn't have gotten anywhere without Spaceways very own procedural generation which you graciously let me use)... :shifty:

The other, currently being finished and rewritten at the same time, is similar. The problem is, in both cases I have been and still am pushing the limits of the Orbiter API. As such, a common denominator wouldn't really motivate me to develop add-ons for the sake of higher distribution and usability. I'll always go for the highest available complexity, because usually I run into problems even there (as you always do if you use stuff for purposes it wasn't intended for), which is a part of what motivates me.

On the other hand, I would be very willing to port IMS2 (I won't butcher the old version anymore, that would just be a nightmare) to Spaceway as it comes along, even while being aware that such a port would basically require another rewrite of all the stuff that actually connects directly to Orbiter. Because let's face it, IMS is abusing orbiter functionality to no end for stuff it hasn't really been intended. But since I just started a rewrite, I could move all calls to the orbiter API to another layer, making future porting somewhat easier...

What I really can't be bothered with is learning yet another language. Might be lazy, but I have never and will never work in any branch even remotely connected to programming, and for a Hobby it's just a bit too tiresome to start at syntaxes again...

 

[Urwumpe]

I think we could make SSU multiplatform enough to compile with Spaceway with some months of refactoring and abstracting Orbiter concepts... but what gain would we have? It would be nice for Spaceway and since SSU is open-source, anybody could make a Spaceway fork of it... but it wouldn't be nice for the project SSU since both platforms are free and it already works on one platform.

 

[Ripley]

Question to SC3 vessel developers: How do you feel about your add-ons being used in Spaceway?
They are not going to be distributed with it, just now one can download them from OH and install on another simulator.
Any objections?

I think this question could be promoted, or rephrased, as a stand-alone poll to let it get more visibility.
Here is "hidden" in a very technical thread, which (maybe) not everyone is interested in following.

:tiphat:

 

[Enjo]

Ok, so we've got vessels sorted out. What about MFDs? How far is the TransX port from something that is a rewrite based on a more generic API?