API Question Trying not to break existing add-ons

[D-mo]

I've been making some changes to the Orbiter code and trying carefully not to break the existing add-ons. I know this is very subjective, but are there like 5 top add-ons that everybody uses that I can test against? I am thinking: IMFD, LunarTransfer, XR ships.

Any others?

 

[MaxBuzz]

1 Multistage2015
2 VesselBuilder
3 GeneralVehicle

 

[GLS]

Why not follow the (what I think was the general) consensus in some other thread about this, which was not change the API until the x64 version?
Yes, it is very nice and there are many reasons to have a clean house, but I don't think char* will stop working tomorrow and we need to start throwing addons out of the window to save ourselves.

 

[Gondos]

Why not follow the (what I think was the general) consensus in some other thread about this, which was not change the API until the x64 version?
Yes, it is very nice and there are many reasons to have a clean house, but I don't think char* will stop working tomorrow and we need to start throwing addons out of the window to save ourselves.

I hope I'm mistaken but I don't think it will happen that way. Once an official 32bit version is established, the move to 64bit will probably be feature frozen to consolidate the version without interferences from API changes. Modders will release 64bit versions of their software to see that they are compatible and at that point it will be too late for any API change ; we'll be back to square one.
Apart from cosmetic changes such as const correctness or char * to std::string conversion, there are some really heavy reworks that are required if we want to push for more portability (removal of GDI dependencies from the API, Windows only code to replace or remove in the core (DirectInput, MOGE, windows and events handling...)).
I did a proof of concept that does just that, and given the underwhelming feedback I got, I'm starting to doubt there is a will to go in that direction.
That being said, Orbiter's experience revolves a lot around addons and we can't expect modders to release binary versions for every possible platform, so I can understand why Windows will probably stay the main, if not the only target. Future will tell...

 

[D-mo]

Why not follow the (what I think was the general) consensus in some other thread about this, which was not change the API until the x64 version?
Yes, it is very nice and there are many reasons to have a clean house, but I don't think char* will stop working tomorrow and we need to start throwing addons out of the window to save ourselves.

I am. But life is not that simple. For example, I thought I could replace a struct with an alias to a specialized template. It turns out I can't. The fact that certain function parameter is a struct or a union is embedded into the function signature (not just the name of the type).

So, to make sure I don't inadvertently break stuff, I was thinking I can test with a few common add-ons. Hence my request.

 

[D-mo]

I hope I'm mistaken but I don't think it will happen that way. Once an official 32bit version is established, the move to 64bit will probably be feature frozen to consolidate the version without interferences from API changes. Modders will release 64bit versions of their software to see that they are compatible and at that point it will be too late for any API change ; we'll be back to square one.

Sadly, @Gondos is probably correct.

Apart from cosmetic changes such as const correctness or char * to std::string conversion, there are some really heavy reworks that are required if we want to push for more portability (removal of GDI dependencies from the API, Windows only code to replace or remove in the core (DirectInput, MOGE, windows and events handling...)).

We start with replacing some of the Windows-specific code with STL (eg, filesystem, strings, math, etc.). IMHO anything outside of the Orbitersdk dir can and should be replaced with generic C++ code.

But, yeah, at some point we'll have to bite the bullet and the DirectInput, DirectX, etc stuff. @Gondos how do you feel about Qt? It's cross-platform and covers just about anything. Event handling, joysticks, GUI, 3D graphics, etc, etc.

My general approach in life is to use STL as much as possible, then whatever is not covered by the STL -- use Qt.

I did a proof of concept that does just that, and given the underwhelming feedback I got, I'm starting to doubt there is a will to go in that direction.

Your repo has 161 forks (including mine). I wouldn't call this underwhelming.

One thing though, is that IMHO you went too far ahead without trying to maintain compatibility with the main repo. I think if we consistently contribute cross-platform changes into the main repo and @Xyon keeps up the good work of merging them, at some point we'll get there...

That being said, Orbiter's experience revolves a lot around addons and we can't expect modders to release binary versions for every possible platform, so I can understand why Windows will probably stay the main, if not the only target. Future will tell...

I would expect the add-on developers to follow the example of Orbiter and release their add-ons as open-source... Just saying

 

[GLS]

Once an official 32bit version is established, the move to 64bit will probably be feature frozen to consolidate the version without interferences from API changes. Modders will release 64bit versions of their software to see that they are compatible and at that point it will be too late for any API change ; we'll be back to square one.

Almost every addon will have to make some changes to work in the x64 so, IMO, changing the API at this point is "for free". Someone correct me if I'm wrong, but with the exception of some planet/moon modules, the x64 version is working fine, right? If so, then there is no point in releasing the x64 without changes.

 

[n72.75]

@GLS you are correct. At least to the best of my knowledge.

@Gondos your Linux work has been incredibly, and I hope you continue, you have also made some great contributions 5o NASSP code and that is appreciated as well. I think cross-platform support is going to be important at some point down the road, even more so than it is now.

Broad question to everyone:
Is there a good reason we can't try for a 32bit "release" now? (I am aware of a few bugs that need to be fixed first).

Now seems like a rather good time to do that, the current 32bit OO is very similar to 2016, with a few major new features and a few major bug fixes. It seems like the sort of thing (maybe with one or two more fixes) that would be great to send the average (non-programmer) user/ or new user to go download. It should get some rigorous testing, through checks that everything is packaged correctly, and then we can ship it out as "Orbiter 2023"

That would free up future development to deviate from the Orbiter 2016ish codebase a lot more, and it would vastly improve the experience of new users getting into Orbiter, and it would allow addon devs to target a newer release.

So in conclusion, why don't we make the 32 bit release the priority, get that solidly out of the way. Then work on a future 64bit release with new features, etc.

 

[D-mo]

Almost every addon will have to make some changes to work in the x64 so, IMO, changing the API at this point is "for free".

If the APIs are the same between 32 and 64 bit builds, the add-ons shouldn't have to make any changes.

Now, the last thing we want to do is have different APIs between the two versions. That will be a nightmare for both the Orbiter devs and the addon devs.

The route that we can go is to start adding new functions to the API, so as the addons get updated, they can start using the new functions. And, eventually some of the old functions (eg, using raw char* instead of std::string can be deprecated and removed).

 

[D-mo]

Is there a good reason we can't try for a 32bit "release" now? (I am aware of a few bugs that need to be fixed first).

I would like to see these fixed:


The XR vehicles get buried in some of the scenarios. Not all. I am guessing this might be some rounding error and the vehicle ends up being partially underground?

 

[GLS]

Is there a good reason we can't try for a 32bit "release" now? (I am aware of a few bugs that need to be fixed first).

My position right from the beginning was: fix bugs (some in the famous list I keep mentioning), update documentation and then release. That way, we would have a solid base for higher flights, or if dev dries up we would be left with a working version.
IMO, some of those bugs should be fixed before (animation limitations and terrain issues), but other than that, it seems ready.

If the APIs are the same between 32 and 64 bit builds, the add-ons shouldn't have to make any changes.

I'm speaking from personal experience:

 

[D-mo]

I'm speaking from personal experience:

@GLS I believe you. I am just saying that this shouldn't have to happen. And if it is, then something needs to be fixed upstream.

 

[GLS]

@GLS I believe you. I am just saying that this shouldn't have to happen. And if it is, then something needs to be fixed upstream.

The changes related to the D3D9 integration are hard to avoid. The others I think were talked in some thread at the time.

 

[Xyon]

Selfishly, I suppose, I'm most interested in the move away from Windows specific stuff, especially in the building process, but also because it would allow me to go back to doing some Orbiter add-on dev myself without having to resurrect my old msvc toolchain - I don't really have any appetite for that. To that end I've been keeping a close eye on your fork, @Gondos - it looks really promising.

The discussion around what to do in the development space really does feel quite circular, though. Most often it seems to come crashing back to "yes but let's do the 32-bit release first"... so let's do it. I can draw all the arbitrary lines in the sand that I want, but as someone who's free time is really quite limited I don't think that would be very helpful; I do, however, think it would help us all to come to an agreement on the featureset that is required before we say goodbye to x86. I have spent exactly no time looking to see if a thread to collect that together already exists, but if it doesn't yet, let's make one, and let's get a prioritised list of things that must be in the release before we can consider it "done".

I intend to be at least a little ruthless in skimming that list down to the bare essentials, so fair warning here, but there may be a fair few things that get relegated to "nice to have" status.

 

[GLS]

on the featureset that is required before we say goodbye to x86

So, to separate the waters here:

• for the next (x86) release, probably good to go with the exception of a couple of issues
• for the last x86 release, fix as many bugs as possible, so it dies gracefully

A question that need to be answered first is: are these 2 versions are the same or not?

I intend to be at least a little ruthless in skimming that list down to the bare essentials, so fair warning here, but there may be a fair few things that get relegated to "nice to have" status.

Since the beginning I've been saying "fix bugs first, add features later", and my (small) contribution to Orbiter so far has been bug fixing, and I've been holding on to 1 or 2 new things that I feel should only appear later.

 

[D-mo]

A question that need to be answered first is: are these 2 versions are the same or not?

I believe there are some binary-only DLLs that are causing issues with 64-bit builds, so we might have to keep it around until those are replaced. @n72.75 can chime in if I am wrong. I believe he was looking into that.

 

[Gondos]

I believe there are some binary-only DLLs that are causing issues with 64-bit builds, so we might have to keep it around until those are replaced. @n72.75 can chime in if I am wrong. I believe he was looking into that.

Maybe we can revert to legacy orbital elements if there is no handy alternative at the moment? That's what I did on linux but I have no idea about the accuracy of this solution.

 

[n72.75]

Maybe we can revert to legacy orbital elements if there is no handy alternative at the moment? That's what I did on linux but I have no idea about the accuracy of this solution.

@Ajaja generated some elements from recent data that we can use, I was going to try to incorporate them, but I've been either busy with real-world stuff, or trying to finish up NASSP projects before I start new projects.

 

[Gondos]

To keep the ball rolling, I just pushed a prototype that integrates Dear ImGui into OpenOrbiter :

To demonstrate, I replaced the legacy Select/InputBox with ImGui controls. I also converted the ExternalMFD to use ImGui and ported the DlgMap/VectorMap to sketchpad to remove some Windows dependencies.
Do you think it could be a viable solution to replace the Windows stuff used for dialogs?
Also, the D3D9Client seems to have a bug when it comes to filling concave polygons...

 

[misha.physics]

The Map window seems to be nice with smooth movement (the default one causes fps drops).