Discussion "Orbiter Council" to guide open-source development

[Urwumpe]

Why the big push for 64 bit? 32 seems to be doing fine, especially given the performance increase with D3D9. To me, is seems a bit silly to knowingly break literally thousands of addons for… what?

x86 is more and more turning into legacy and will eventually die out.

So, we need a x64 version one day. But it isn't today.

Also, its hard to tell what Orbiter did wrong. Orbiter 2016 just added those features, that the community really wanted for years: 3D terrain, docking on the ground and wind.



If it is just about the complaints about the community.... maybe its better to simply make a new simulator engine without any historic limitations, compatibility to Orbiter and a completely new community.

 

[Face]

Why the big push for 64 bit? 32 seems to be doing fine, especially given the performance increase with D3D9. To me, is seems a bit silly to knowingly break literally thousands of addons for… what?

AFAIK, getting Orbiter into 64 bit was originally Martin's intention, because the 2/3GB process memory limit worried him regarding ever growing tile resolution and corresponding memory consumption.
I'm not sure if that limit was ever hit with 2016, but I can imagine that complex scenarios with many instances of sophisticated vessels will do the trick.

 

[jedidia]

maybe its better to simply make a new simulator engine without any historic limitations, compatibility to Orbiter and a completely new community.

Now that's what I'd call "Das Kind mit dem Bad ausschütten"!
But I agree with you in general. The main difference between O2010 and O2016 was that add-on developers updated their add-ons much quicker. Less complex projects with less legacy, and overall higher motivation. DBeachy has to be commended in this regard, he was pretty fast in updating the entire fleet.

There are a few things that O2016 might have messed up a bit, like touchdown points. Those caused quite some headaches when upgrading, and they don't really have the required tooling to use them properly without doing either a lot of trial and error or being preeetty good at math... Things that might have been addressed with better post-launch support, but then, you can't really expect that from a one-man hobby project.

All in all though, it has to be said that if there is no need to bring Orbiter in the 64 bit age, is there a need to update Orbiter at all? Apparently it was fine back in 2010, and that version is still around, so... yeah.

 

[N_Molson]

x86 is more and more turning into legacy and will eventually die out.

So, we need a x64 version one day. But it isn't today.

Also, its hard to tell what Orbiter did wrong. Orbiter 2016 just added those features, that the community really wanted for years: 3D terrain, docking on the ground and wind.



If it is just about the complaints about the community.... maybe its better to simply make a new simulator engine without any historic limitations, compatibility to Orbiter and a completely new community.

What Orbiter did wrong is KSP, mostly. Which was created by an Orbinaut ! ? The "brain drain" has been quite extensive since then.

Orbiter might not be perfect but it is. Keep Faith in the Holy Probe ! ?? Again the priority should be to show people around what is going on. I have nothing against Open-Source but 1) I still hardly understand what it is 2) for the little I understand it is a very specific software-engineer-way (German) of doing thing most people are completely unfamiliar with (the whole concept of "branches" is quite alien to me, and I'm trying to understand). ???

It would be good to have a summary each month, that says who has been doing what. We need "the big picture". ?️

And yes, Orbiter has to go x64, unless it wants to become a retro-gaming thing, which is not my definition of fun.

 

[JDat]

What about Martins last release with DX7 on x86 before mowing to x64 and @jarmonik graphic engine?

 

[N_Molson]

What about Martins last release with DX7 on x86 before mowing to x64 and @jarmonik graphic engine?

Feel free to open a museum.

 

[n72.75]

While I can respect that legacy addons are near and dear to the orbiter community, the future of Orbiter and of the community cannot survive on them. New development has to be taking place. If Dan had released UMMU etc. for 2016 when it came out, the 2010/2016 split would not exist. Don't get me wrong, I love those addons, but hanging our hat one one developer's closed source work is a gamble. I could get hit by a bus tomorow, and you'd all still have access to my code.

Over the years there have been 3rd party APIs that have facilitated development either by simplifying the development process or offering interoperability between addons of different users with no prior knowledge.

We really need to think about attracting new users. This can be done by the following:

*Facilitate representing real-world situations with a high degree of physical accuracy. This improves Orbiters usefulness for a wider audience. 2016/R90 already does this really well.

*Facilitate better visuals. Look at the time and effort people put into KSP addons, simply because it looks better. And it's not like the extremely modded setups are super accessible, but they look cool and that's it's own advertisement.

*Better tools for in-sim use/navigation etc. It is hard to navigate with the default MFDs, and that's really a problem of lacking the proper tools, not of the physics being too realistic.

Let's move forward. I know we can do it.

 

[Urwumpe]

All in all though, it has to be said that if there is no need to bring Orbiter in the 64 bit age, is there a need to update Orbiter at all? Apparently it was fine back in 2010, and that version is still around, so... yeah.

Well, what I mostly miss are tools. For example a base editor that has no Visual Basic Quirks

 

[Urwumpe]

*Better tools for in-sim use/navigation etc. It is hard to navigate with the default MFDs, and that's really a problem of lacking the proper tools, not of the physics being too realistic.

Well, how to make it easier? A simpler MFD for interplanetary navigation than IMFD?

 

[OvalDreamX]

*Facilitate better visuals. Look at the time and effort people put into KSP addons, simply because it looks better. And it's not like the extremely modded setups are super accessible, but they look cool and that's it's own advertisement.

Some of us are trying it, either doing texture work or completely new models, but most of us are learning along the way so it is very slow and not very professional models or textures. And there's also skybolt project that really overhauls the visuals both with volumetric clouds and cockpit shadows (a must if you ask me, 3d virtual cockpit are the main environment in which people fly in flight sims pretty much since fsx). But we are in separate projects and kinda just doing what we see fit. Some kind of organization may help with it

 

[OvalDreamX]

Well, how to make it easier? A simpler MFD for interplanetary navigation than IMFD?

While I agree that there is a VERY steep learning curve for Orbiter, navigating by mfd are kind of it's thing. Maybe a good idea would be to look at how ksp mods (raster prop monitor I think) handle navigation from within the IVA.
Here's a good example where you can see it in action I think

 

[gamer19]

x86 or x64 version they are both fine to me. as I don't understand the most of the things you say
I have I'll say a middle range PC and never saw some memory or any other graphic limitation, to be honest.

but I would really really love to see, wherever the future takes it, a little bit less of crashes in this great game. Simulator that's it.
whatever, no matter how tiny it is, part is missing - it just simply crashes. wish it could report error, don't show those textures/models but doesn't crash every time.
like, the other day I was trying to play some Space shuttle scenario. from 7 or 8 just one loads up. and I have them all you know... Shuttle Ultra, Shuttle Fleet, Atlantis, some through ISS scenarios and not sure now but probably that one scenario from Atlantis loads up. and that's probably stock game version, right

don't get me wrong , love O, tons of fun, tbh what's most important to me - AMSO is working pretty great ??
(even more since I've learned that when some of your scenario crashes for as it seems no reason, you just load it up again and - it works! always!!)
but constant crashes can be tiresome sometimes. especially when it seems like you have every little extra add on that those particular add on require ?!?

anyway... these small annoyances aside....
agree, would be such a shame if Orbiter become some kind of space lost abandonware.
hope this turns out great. fingers crossed ?

 

[DaveS]

it just simply crashes. wish it could report error, don't show those textures/models but doesn't crash every time.
like, the other day I was trying to play some Space shuttle scenario. from 7 or 8 just one loads up. and I have them all you know... Shuttle Ultra, Shuttle Fleet, Atlantis, some through ISS scenarios and not sure now but probably that one scenario from Atlantis loads up. and that's probably stock game version, right

Better error reporting and logging has been proposed by me as an addition: https://www.orbiter-forum.com/threads/better-error-reporting-and-logging.40043/

 

[N_Molson]

Well, how to make it easier? A simpler MFD for interplanetary navigation than IMFD?

IMFD is a very powerful tool, but it is not anything like "simple" by today's standards.

I'd say it has something to do with the fact MFDs display in 2D a 3D situation. KSP solved this with the "manoeuver gizmo". Now in KSP orbits are very easy to display - in Orbiter, with the n-body problem properly simulated, it is entirely another can of worms. But still, something probably can be done there in terms of user-friendlyness of the interface (for "macro-scale" stuff like Earth to Moon trajectory plotting, you don't need to display a very accurate trajectory - a few kilometers won't be even like a pixel on the screen -, values can be rounded a lot).

Where KSP was a bit a "stab in the back" is that it "cheated" using college-grade maths (and many people are in known territory there) while Orbiter was dealing with university-grade maths (which narrows the audience to a handpicked elite).

 

[Urwumpe]

I am not sure, HOW much easier it could get - as you say, the world in Orbiter is a lot more complex and way more chaotic. Some amount of intelligence of the user has to be expected, since artificial stupidity might not be what the user expects.


The question is, can we maybe get something easier to use by changing the usual "university grade" UI to something more gradual, that allows tweaking the solution with increasing detail, instead of directly starting at the most mathematical way?

 

[n72.75]

Maybe I'm off on that one. Just something to think about. I feel like it's taking us off topic a bit, and is probably squarely in the "features that should be addons" category.

 

[4throck]

is there a need to update Orbiter at all? Apparently it was fine back in 2010, and that version is still around, so... yeah.

There's a need to update Orbiter 2010 with 2016 style terrain and visuals
It's a joke but it might actually be that !

But I repeat that we are all guessing here. It would be better to do a poll and to see what people really want.
It might turn out that like the OpenRA example, all we need is a way to run old software on new computers...

 

[N_Molson]

It might turn out that like the OpenRA example, all we need is a way to run old software on new computers...

I, for myself, don't feel any motivation to work on addons "for old software".

 

[Urwumpe]

I, for myself, don't feel any motivation to work on addons "for old software".

I agree - especially Orbiter 2010 and its add-ons are not just old software. Its dead software. You can still use it, but nobody maintains it.

 

[GLS]

I just noticed that Martin has actually left as developer/maintainer in Orbiter's git repo...