Discussion Developing Addons for different Orbiter Versions

[fred18]

Orbiter 2010 is not dead !!!!

Great pictures, but... no. Orbiter 2016 has a terrain and a lot of other features.

You know that it is not an either-or, right? You can have both versions.

To be honest I think that in general if users "support" (in the sense of like more) a almost 10 year old version of a software/game instead of the latest version it is something to be concerned about. Orbiter2010P1 was surely far ahead of his time being superstable, userfriendly to approach and graphically beautiful leading to a whole amount of wonderful addons, I like it a lot of course. But if there is a version which came 6 years later (and a beta almost ten years later) it should be the preferred choice of all the users (except the nostalgic ones which anyway are always there). But it seems that many many users are big fans of 2010P1 "against" 2016 or the Beta. For example I talked with the developer of AMSO and he clearly stated that he hasn't even downloaded orbiter2016 because he is "not motivated to do it". In general I think it is something to think about for Martin in first place and then for all developers including me.

 

[Face]

In general I think it is something to think about for Martin in first place and then for all developers including me.

I thought about it and my take is that there is a need for conversion tools, especially for the terrain aspect. Tried that, but failed, though.
Another alternative that comes to mind is that Martin should maybe scrap the 2016 version officially. Perhaps we will then see some "underground" teaming up to "rescue" this progressive version, instead of the other way around, like it is now. :rofl:

All in all, most of the problems we see here are due to the closed-source affinity of the community. Many of the higher quality projects for 2010 were done so that nobody could pick up the ball and bring it to the more shiny playground but the original author. And of the later ones, many simply lost interest. This is the reason for this dilemma. If the community is not learning from its failures (middle-ware like SC3 stalled, must-haves like OS4 and UMmu stalled, closed-source praised while open-source practically shunned), it will continue to slowly decline and in the end wither to nothing. (Ok, that's a bit apocalyptic, but you sure get the point. :lol

my :2cents:

 

[kuddel]

AMSO sources would be highly appreciated:thumbup:
But no one can be forced to release their sources.

 

[fred18]

I thought about it and my take is that there is a need for conversion tools, especially for the terrain aspect. Tried that, but failed, though.

From my point of view there is a need for:
- "auto flattening" for terrain around bases so people can import the bases from 2010 to 2016 or easily create new ones. I was testing a space plane that I was trying to develop and I realized that in 2016 on earth I had like 4 runways to land on, while in 2010 I had some hundreds... (if you know Cities Skylines when you put a road in the middle of a hill the hill gets cutted smoothly in half, that's what I mean)
- a model that helps defining stiffness and damping of touchdown points: the harmonic oscillator is the right model but not easy to manage for everybody.

I think that with this 2 improvements then the "music" may change.

I am sorry going off topic, if mods want to move this it is ok for me.

 

[GLS]

- a model that helps defining stiffness and damping of touchdown points: the harmonic oscillator is the right model but not easy to manage for everybody.

If I know my physics well, those parameters depend mostly on the vessel mass, so a spreadsheet might be enough to allow those parameters to be calculated for a certain amount of suspension movement. I had the idea of making this, but have been too caught in SSU to do anything else. Hopefully it won't be long before there is a SSU for Orbiter 2016.

 

[fred18]

If I know my physics well, those parameters depend mostly on the vessel mass, so a spreadsheet might be enough to allow those parameters to be calculated for a certain amount of suspension movement. I had the idea of making this, but have been too caught in SSU to do anything else. Hopefully it won't be long before there is a SSU for Orbiter 2016.

yes that's most of it.

here's how I determine some defaults usually working points:

double x_target = -0.5;
double stiffness = (-1)*(Mass*9.81) / (3 * x_target);
double damping = 0.9*(2 * sqrt(Mass*stiffness));

where Mass is vessel mass of course.

 

[4throck]

Back in the day I pointed out that backward compatibility was important and easily maintained.

If I remember correctly, UCGO/UMMU crash in 2016 because text output was changed.
Sure, I guess there's a trade-off somewhere in 2016, but at what cost?

If you define a .cfg vessel with 3 landing points, stiffness and damping get calculated, or at least default to something that works.
Yet if you load a .dll that defines just 3 points, you don't get a working behavior!

I personally feel a bit betrayed by this, since the changes that break 99% of stuff can be easily fixed on the core. Wouldn't be hard to add fred's code to the core...
It's insane to think about how much time it would take to rebuild AMSO, a single add-on, compared to what it would take to fix 2016's backward compatibility (fixing it for all addons).

 

[Urwumpe]

All in all, most of the problems we see here are due to the closed-source affinity of the community.

Also, this is made worse by the long release cycles. An add-on is done in 2010 and then the developer moved on. Now its 2019. And many are simply no longer active and not even interested.

I would really say: If it is not open-source, you should not be surprised if it is broken after nine years.

And if there is going to be a "oldtimer community" being more active to support 2010 than work for 2016... I would say this community is too busy looking backward than forward.

---------- Post added at 15:15 ---------- Previous post was at 15:05 ----------

I personally feel a bit betrayed by this, since the changes that break 99% of stuff can be easily fixed on the core. Wouldn't be hard to add fred's code to the core...
It's insane to think about how much time it would take to rebuild AMSO, a single add-on, compared to what it would take to fix 2016's backward compatibility (fixing it for all addons).

You are wrong there - this code would fix NOTHING in the core. Its still the job of the add-on developer to get this right.

How would you create backwards compatibility for an add-on assuming a flat moon? When the moon is no longer flat at all...

And betrayed? You get Orbiter for free... without ads. Without lootboxes and pay to win. :facepalm:

 

[4throck]

A real example:
I tried to help a member with a C++ ~1000kg lunar lander.
We tried everything, from fred's calculations to the copy/paste DG parameters.
The lander never settled into a landed position, slowly moving sideways.
So the add-on remains unreleased....

Sure, perhaps we are dumb, but we really can't "get this right" for 2016.
All would be well if others could get it right. But nobody seems to, and we can't all be dumb

That's why I say there's something wrong with the core.
Because up to 2016 nobody had any problems with it and development was actually fun. Something changed with 2016.

 

[Urwumpe]

Sure, perhaps we are dumb, but we really can't "get this right" for 2016.
All would be well if others could get it right. But nobody seems to, and we can't all be dumb

That's why I say there's something wrong with the core.
Because up to 2016 nobody had any problems with it and development was actually fun. Something changed with 2016.

And if one gets it right, what would this mean? (Which lander, add-on and landing site, BTW?)

A lot changed in 2016. People asked for it! And now people complain about it meaning extra work? Really?

 

[kuddel]

...getting waaay off-topic.
@Moderator Maybe move posts #15 - ... to a new thread "Best practice / Wishes for 2010 to 2016 migration"?

 

[martins]

I don't want to hijack this thread, which after all is an announcement of a new AMSO version, which is big news in its own right for many users.

However, it looks like some response is in order, so here goes:

I don't see any problem with developers writing addons for previous Orbiter versions. If they are happy with a tried and tested platform, and don't value features added in later versions sufficiently to justify the work in converting to a new interface, then this is perfectly fine. After all, I am still linking Orbiter against DX7 because for me personally this is not a sufficiently important part of Orbiter to go chasing the latest graphics interface, so I am not really one to complain here

For example I talked with the developer of AMSO and he clearly stated that he hasn't even downloaded orbiter2016 because he is "not motivated to do it".

This sounds like it was never intended to be ported to a newer version anyway, so I guess all discussion on this point is moot.

About backward compatibility: While I am not intentionally trying to break addons in a new version, sometimes it can't be avoided. Take the touchdown point issue. In 2010, for a tailsitting rocket is was sufficient to place the touchdown points anywhere in a plane z=const to make it sit rock solid on the flat surface. In 2016, if the points weren't distributed symmetrically around the projection of the CoG, it would lean and probably fall over until the positions and/or stiffnesses were correctly adjusted. (not to mention that 2016 now actually allows a rocket to fall over, so needs additional points for a complete convex hull). These values can't be guessed automatically, so it needs a bit of re-working by the developer. If that doesn't happen, it's not a big deal, as far as I am concerned. It simply means that the addon remains a Orbiter2010 addon. If users like it, they can be expected to keep a 2010 installation. If 2010 turns out to be the definitive Orbiter version, good for it . I'll keep tinkering on with 2016 and beyond as long as I have fun with it, but I am mainly doing this for my own amusement. I am not expecting every developer and user to follow.

 

[Urwumpe]

...getting waaay off-topic.
@Moderator Maybe move posts #15 - ... to a new thread "Best practice / Wishes for 2010 to 2016 migration"?

I would say, a "New to Orbiter 2016 development" thread would be helpful for many. Just like a "New to Orbiter 2010 development" thread SHOULD have been helpful, but was somehow avoided, since Orbiter 2010 was too backwards compatible to 2006 IMHO.

Many broken add-ons are not broken because of Orbiter 2016, but because API features of 2006 are no longer working well in 2016.

 

[GLS]

On my experience upgrading SSU for Orbiter 2016, the major problems were not due to Orbiter itself but more in the way things were implemented inside SSU (I'm referring to us not caring about the altitude of runways before). If I remember well, there were 2 Orbiter changes that we had do deal with, one related to changes in Orbiter's loading sequence and another on separating vessels, but those were nothing much in terms of changes). The touchdown points took some math, but where solved without major issues. The terrain work is something that isn't "easy", but it is something new, so "pains of birth" are expected. Anyway, it's an amazing addition, and I usually start drooling at the mountains and crash... :uhh: :lol:

So, I'd say only about 10-15% of work was a direct result of the new Orbiter version.

I won't say what SDK I have to put up with at work, except it is from a major international company and you all probably used their products, but Orbiter's SDK, even with its flaws, is far far superior to that pile of manure.

(sorry for the off-topic)

 

[Donamy]

Fred19's VesselBuilder is the biggest thing for us mere addon tinkerers right now. When it gets finished and people learn how to use it. I don't think 2010 will hold a candle to 2016. JMO

 

[fred18]

I'd like just to add that when I said

In general I think it is something to think about for Martin in first place and then for all developers including me.

I was not saying that Martin, or anybody else is doing anything that I judge "wrong", I was just saying that this "reluctancy" towards the new orbiter, (which on the opposite I find literally fantastic!) is an aspect that anybody who contributes somehow to the development of this community should just have on a small side of his mind. Basically what I am saying is that the new orbiter is so beautiful that if just a couple of things get more friendly it will be a boom of users!

but Orbiter's SDK, even with its flaws, is far far superior to that pile of manure.

I will never thanks Martin enough for this. It is really designed greatly, and it helped me a lot learning at the beginning!

 

[martins]

I was not saying that Martin, or anybody else is doing anything that I judge "wrong", I was just saying that this "reluctancy" towards the new orbiter, (which on the opposite I find literally fantastic!) is an aspect that anybody who contributes somehow to the development of this community should just have on a small side of his mind. Basically what I am saying is that the new orbiter is so beautiful that if just a couple of things get more friendly it will be a boom of users!

No worries at all, mate, and I do appreciate the constructive criticism.
I definitely agree that user-friendliness is important, so the VesselBuilder addon is a huge step in that direction.

Hopefully the new tileedit tool will make it easier to flatten runways, so that problem might be addressed as well.

Anyway, I do agree that the latter part of this thread should probably be moved to a separate topic (2010 vs 2016 megawar? :lol to decontaminate the AMSO announcement.

 

[4throck]

These values can't be guessed automatically, so it needs a bit of re-working by the developer.

So why not allow these values to be defined in the vessel's config?
Shouldn't must have parameters be definable at the most basic level (a vessel .cfg) ?
Right now Orbiter seems to use some defaults (DG values) for them...

Not being ungrateful, just trying to understand the reason behind this.

For me it seems simple enough to be able to add the needed values to a config.
That's re-working by the developer as I see it.

 

[Xyon]

OF Staff Note: The preceding posts were moved from [AMSO] New AMSO version 1.22 released to aid the discussion of this topic while keeping the AMSO announcement clear of it.

 

[gattispilot]

So With 2016 we have terrain so now uneven areas. But we wanted that.

So with the Change Lander It didn't land well slid around. Even in VB.

So in real spacecraft would they be level by adjusting gear?

Not sure why in sc3 the vessel flys nicely but not the dll?


It would be nice if easier to flatten areas? Not sure how that has come. Not just landing strips but base areas like MoonBase Alpha,.....