Discussion Simulator Abstraction Layer?

[Artlav]

An idea in the Space Engine thread ( one , two ) got me thinking.
Is there any interest in a common add-on interface for space flight simulators?

An abstraction layer that add-ons are to be written with on one side.
On the other side, this abstraction implemented for a specific simulator.

I've made a thing like that to make my add-ons compatible with both Orbiter and Spaceway.
What i have looks like that: http://orbides.1gb.ru/etc/sal-dump.zip
Ugly, but it works.

Obviously, to make something like that generally usable is a monumental amount of work, so the question up front:
Is it worth it?

Question aimed primarily at add-on developers - would you bother to learn a different framework, rewrite your add-ons to it and so on?

The promise of it is the ability to easily port add-ons between simulators - different Orbiter versions, Spaceway, Space Engine when it gets to vessels, Pioneer, you name it.

There are many technical problems - different sims use different notations and assumptions. Even number representation is different. The SAL should be generic enough to allow for this, yet powerful enough to implement any tool/MFD (short-term goal) or vessel (long-term goal).

Then there are non-technical problems. Even Space Engine don't have a community like Orbiter have - what would attract developers to the SAL?
What could be the appeal of it to make it useful?
How could it be made more popular than porting Linux to an Orbiter's MFD?

I'm open to suggestions.


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?

 

[BruceJohnJennerLawso]

An idea in the Space Engine thread ( one , two ) got me thinking.
Is there any interest in a common add-on interface for space flight simulators?

An abstraction layer that add-ons are to be written with on one side.
On the other side, this abstraction implemented for a specific simulator.

I've made a thing like that to make my add-ons compatible with both Orbiter and Spaceway.
What i have looks like that: http://orbides.1gb.ru/etc/sal-dump.zip
Ugly, but it works.

Obviously, to make something like that generally usable is a monumental amount of work, so the question up front:
Is it worth it?

Question aimed primarily at add-on developers - would you bother to learn a different framework, rewrite your add-ons to it and so on?

The promise of it is the ability to easily port add-ons between simulators - different Orbiter versions, Spaceway, Space Engine when it gets to vessels, Pioneer, you name it.

There are many technical problems - different sims use different notations and assumptions. Even number representation is different. The SAL should be generic enough to allow for this, yet powerful enough to implement any tool/MFD (short-term goal) or vessel (long-term goal).

Then there are non-technical problems. Even Space Engine don't have a community like Orbiter have - what would attract developers to the SAL?
What could be the appeal of it to make it useful?
How could it be made more popular than porting Linux to an Orbiter's MFD?

I'm open to suggestions.


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?

I would certainly be interested as a developer. Spaceway looked absolutely amazing, but the lack of nice vessels and slow performance killed it for me. Being able to port would be well worth it IMO.

 

[Artlav]

lack of nice vessels and slow performance killed it for me. Being able to port would be well worth it IMO.

Performance might be better since today's update.

While i cannot deny that getting Spaceway add-ons for free is among my many motives for this proposal, i still think it's worth something even with SW out of the picture - Orbiter changes, how much easier would it be if the changes could be largely accounted for in one place?
i.e. we could have still had Vespucci D working if SAL was introduced from the start.

 

[N_Molson]

I must say I'm not sure I fully understand how it would work.

It would be a sort a converter, that would require add-ons developpers to use specific C++ libraries to compile their addons ? Or use a different programming language, load it into the converter and let it export to the formats used by the 3 simulators (Orbiter, SpaceEngine, Spaceway) ? :hmm:

 

[BruceJohnJennerLawso]

I must say I'm not sure I fully understand how it would work.

It would be a sort a converter, that would require add-ons developpers to use specific C++ libraries to compile their addons ? Or use a different programming language, load it into the converter and let it export to the formats used by the 3 simulators (Orbiter, SpaceEngine, Spaceway) ? :hmm:

I believe it would be a SDK library type of thing, with generic functions allowing a standard input to be parsed into simulator specific code. For example a library function could take a standard classcaps input, then output an Orbiter specific setclasscaps function when running Orbiter. At least that's what it sounds like.

 

[Enjo]

I think that the mistake that you make is waiting for results before getting motivated to generate them. Small reputation of SpaceWay may result from some seemingly small but important details - not clear Linux compilation, performance and stability issues. But this brings us to the point even closer - even if SpaceWay, or some other simulator lacks something or is annoying at some point, the SAL would let the user switch between the simulators, depending on current needs. For me it's a good promise.

 

[Face]

Do we even have a simulator alternative with an API that is on par with (or even supersedes) the Orbitersdk offerings? If not, wouldn't committing add-on development to this hypothetical "API of APIs" mean that the developer will get little gain for huge refactoring?

I.e. if the only other platform(s) the add-on could run on has less functionality than Orbiter, creating an add-on for the API of APIs will mean still creating (or re-creating) an add-on for Orbiter, but with reduced functionality (e.g. some hacks can't work, lowest common nominator etc.). I don't think that the ROI is very attractive to developers.

What about starting with an easier approach: get things like SC3 and genericvessel working on the other simulators. The feature set is manageable and implementation on other platforms should be easier than having to mirror the huge Orbiter API. If you e.g. implement an SC3 parser for SW (which should be doable given that you already wrote a huge portion of the genericvessel code for the proper platform) and support Orbiter's mesh and texture formats, you'll instantly have an add-on ecosystem for free.

The same would be true for SE.

just my :2cents:,
Face

 

[Artlav]

e.g. implement an SC3 parser for SW

:facepalm:
I can't believe i didn't think of that...
It's bloody there already, all i need is to add *.ini files to the search list.

 

[Face]

:facepalm:
I can't believe i didn't think of that...
It's bloody there already, all i need is to add *.ini files to the search list.

That's cool :thumbup:. So now SW suddenly has a considerable addon community. More than SE, at least .

 

[Urwumpe]

Also... you could implement a Lua interface, that uses the same API as the Orbiter LuaVessel interface.

Would be much simpler than a C++ API abstraction layer for two different simulators.

 

[N_Molson]

I can't believe i didn't think of that...
It's bloody there already, all i need is to add *.ini files to the search list.

It's what I wasn't understanding, seems to me you've already done most of the work

 

[BruceJohnJennerLawso]

It's what I wasn't understanding, seems to me you've already done most of the work

Yeah, but there was never anything stopping Artlav from writing a SC3 lookalike for Spaceway anyways. The real advantage of a "universal compatibility library" would be portability between programs for vessel modules. Imagine being able to fly an XR-2 in spaceway, or even better IMS!

 

[Artlav]

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?

It's what I wasn't understanding, seems to me you've already done most of the work

I really don't know what i was thinking.
Or rather not thinking.
Genericvessel is SC3 converter is Station shipyard is Orbiter Shipyard is Spaceway's vessel core.
I had implicit SC3 support in Spaceway code since forever and never realized that. :facepalm:

Suddenly, that infinite world is filled up with familiar shapes.

That might be something worth making a new release.
Not quite the "killer game element" i was looking for, but something interesting to do in the game anyway.

Also... you could implement a Lua interface, that uses the same API as the Orbiter LuaVessel interface.

Yeah, but there was never anything stopping Artlav from writing a SC3 lookalike for Spaceway anyways.

Spaceway have embedded interpreters for Pascal and GRASP languages to make MFDs and vessels, so it's a bit more than SC3 look-alike.
But all that versatility was a waste without add-on developers.

Imagine being able to fly an XR-2 in spaceway, or even better IMS!

Now that would take a miracle.

 

[BruceJohnJennerLawso]

Suddenly, that infinite world is filled up with familiar shapes.

SQuee!!! rolongeddrool: :bananadance:

Now that would take a miracle.

But that would be the whole point of the library, right? DBeachy pulls up the XR-2 source code, rewrites it in Library form, then the XR-2 flies in Spaceway. IMS would be a horrific amount of work for this, but still, you never know...

 

[Kendo]

I thought the idea of using a dll was to vastly improve what craft can do.
Surely using SC3 limits you greatly.
All I can see this is, is just flying a simple ship so you look at the scenery.

 

[Artlav]

But that would be the whole point of the library, right? DBeachy pulls up the XR-2 source code, rewrites it in Library form, then the XR-2 flies in Spaceway.

Surely using SC3 limits you greatly.

Proof of concept.
SC3 is something within my power - the add-ons are already in an abstracted format, so i can port the SC3 interpreter to another sim and get them flying.
No work needed from the developers.

Full scale SAL, on the other hand, is outside my power - the developers would have to rewrite their work to it before anything can be ported anywhere.

While we got sidetracked here with SC3 support in SW, it actually shows the potential benefit of SAL - write once, fly anywhere.

Actually, true SAL would be something akin to Orbiter's Lua interface - the add-ons being written in interpreted language or virtual machine.
But that is it's own can of worms and convolution.

...All that reminds me of Esperanto - it would have been great to have all people on Earth share a single second language, but why would anyone get interested in learning it in the first place?

 

[Izack]

DBeachy pulls up the XR-2 source code, rewrites it in Library form, then the XR-2 flies in Spaceway.

Easier said than done! Space Engine does not provide an interface nearly as complete as Orbiter's - many functions in the OAPI do not have an equivalent in Spaceway, and much information is impossible or very awkward to obtain there.

 

[BruceJohnJennerLawso]

Easier said than done! Space Engine does not provide an interface nearly as complete as Orbiter's - many functions in the OAPI do not have an equivalent in Spaceway, and much information is impossible or very awkward to obtain there.

I know. Thats where Artlav either has to include the extra OAPI functions in spaceway, or set up the library to ignore those calls.

 

[Face]

I know. Thats where Artlav either has to include the extra OAPI functions in spaceway, or set up the library to ignore those calls.

It is not as easy as ignoring the calls. Think about all those functions that return something, maybe a handle, maybe a value, sometimes even pointers to objects. You can't simply return NULL on all of these, as it would for sure blow up many implementations.

In many cases it means creating mock results, or telling developers that they have to deal with occasionally missing results. The former makes it really hard for the engine developer, the later even more so for the add-on developer.

I think the genericvessel approach to this problem is a very good proof of concept. The ROI is pretty high, and the pressure on both engine and addon devs is as low as it gets.

If you think about it, every "API of APIs" approach eventually ends in implementing compiler/interpreter plug-ins for some turing complete language. I'm not convinced that the amount of work necessary to accomplish this is really justified by the gains of being able to re-use (still non-native) addons in different simulators.

It is interesting how the "SC3 vs. DLL" debate - that somehow sits below this discussion - reminds me of my master thesis. There I also had to deal with the "configuration vs. programming" or "description vs. driver" discussion, and in the end settled for simply doing both in a stacked architecture: http://ieeexplore.ieee.org/xpl/logi...re.ieee.org/xpls/abs_all.jsp?arnumber=1377749 (I can send the full PDF if anybody is interested).

 

[Urwumpe]

...All that reminds me of Esperanto - it would have been great to have all people on Earth share a single second language, but why would anyone get interested in learning it in the first place?

I would say, it is also because of the many design flaws in Esperanto... you simply can't speak it without getting out of breath. Thought it is at least better than Lojban.

Compared to Esperanto, Quenya or Sindarin are absolutely practical. Though some words in both languages are scary for non-Germans.