So many addons that do not work

[Urwumpe]

We could maybe have a research project that analyses why add-ons crash and what is the most common cause. And then decide how to avoid these. I am pretty sure, the causes are in many cases really trivial.

Also, and the older ones of you know it, I am a proponent of changing the way how add-ons are stored. The current Orbiter approach is easy, but also can introduce many errors. I would prefer modularizing it, in most use cases, we don't even need to change the API for this. But some add-ons that parse configuration files or want to have their own file formats could be in trouble then.

The next change possible in Orbiter would be sandboxing the add-ons.... but thats a can of worms and will eat performance.

Enforcing Lua only add-ons also sounds like a bad idea and could be just as buggy as before.

 

[misha.physics]

The current Orbiter approach is easy, but also can introduce many errors. I would prefer modularizing it

The current approach of add-on installation is just unzipping an add-on archive into Orbiter main directory. Could you please explain what you mean by "modularizing" approach of add-on installation, namely how is this supposed to work?

 

[JDat]

Remember, I saw an add-on. Don't remember what it does, but something related to remote control or whatever. It was made for Orbiter 2006. How it works? It check few bytes in Orbiter.exe, if they match, add-on patch executable. Really "cool" approach to add functionality to Orbiter. These kind of old add-ons must be killed with fire instead of supporting them no matter how useful these old add-ons was!

Only way to get add-ons working is to recompile them for latest Orbiter. If no source for old add-on it must be written from scratch. There was one guy, who can write MDF in 1 hour using AI, so... He can try and show his AI skills to rewrite old add-ons for Orbiter 2024...

If seriously, what add-ons users need? It would be interesting to see list of most wanted add-ons. Maybe there is chance to rewrite most wanted add-ons. This also really helps to get Orbiter into 64-bit world.

I vote for Orb:connect, VNCMFD and Orbiter master/slave. All by @kamaz, but no time to recompile them for Orbiter2024 right now.

 

[Urwumpe]

The current approach of add-on installation is just unzipping an add-on archive into Orbiter main directory. Could you please explain what you mean by "modularizing" approach of add-on installation, namely how is this supposed to work?

Currently, you have special subfolders in Orbiter, into which you have to place your files. meshes to meshes, textures to textures, etc. If you install another add-on, it installs itself into the same folders. If one add-on overwrites a file of another add-on, chaos happens. If a mesh is missing in the add-on zip, it crashes. A missing texture just looks strange.

I would suggest copying the approach of many other games and install each mod into its own folder. Instead of Orbiter/Meshes, they would go into Orbiter/Add-ons/MyAddon/Meshes. Converting old into new format wouldn't be hard, so if somebody would like to use an old mod, they just install it into their own add-on folder

Next, I would recommend a plain YAML or text file, that declares which files should be used by the add-on, which files should be automatically loaded already on start-up, etc. If there are undeclared files in a mod folder, this could be detected automatically, same for typoes etc. If a file is supposed to be reused by another add-on, you could also declare it here or declare that you depend on that add-on. This way, we could make relations between add-ons more explicit, and instead of requiring C++ code for certain cases, this could happen already in the text file.

Also, adding and removing add-ons is much easier that way.

One troublespot I see there are planet textures, that might be better handled the old way, but we also have little to no bugs with them. Most bugs we get are in vessels and, much more rarely, in MFD plugins. Bases and Planets are pretty rare to cause errors, mostly because of the 2016 format change filtered out many older add-ons in general....

 

[Urwumpe]

Remember, I saw an add-on. Don't remember what it does, but something related to remote control or whatever. It was made for Orbiter 2006. How it works? It check few bytes in Orbiter.exe, if they match, add-on patch executable. Really "cool" approach to add functionality to Orbiter. These kind of old add-ons must be killed with fire instead of supporting them no matter how useful these old add-ons was!

If they really messed with the code of another module, I'd bring some flourine to the fire, you can be sure....

 

[JDat]

If they really messed if the code of another module, I'd bring some flourine to the fire, you can be sure....

That add-on messed with Orbiter.exe if version is correct. Version check was happened by reading particular bytes in Orbiter.exe Do I need to find that add-on? I can try...

LOX is totally OK there!

 

[Urwumpe]

That add-on messed with Orbiter.exe if version is correct. Version check was happened by reading particular bytes in Orbiter.exe Do I need to find that add-on? I can try...

LOX is totally OK there!

Ok, maybe just some N2O4....

(Luckily Orbiter is FOSS now, so such functions could also be included clean and directly as Pull-Request....)

 

[misha.physics]

@Urwumpe, thanks for explanations.

 

[N_Molson]

Currently, you have special subfolders in Orbiter, into which you have to place your files. meshes to meshes, textures to textures, etc. If you install another add-on, it installs itself into the same folders. If one add-on overwrites a file of another add-on, chaos happens. If a mesh is missing in the add-on zip, it crashes. A missing texture just looks strange.

I would suggest copying the approach of many other games and install each mod into its own folder. Instead of Orbiter/Meshes, they would go into Orbiter/Add-ons/MyAddon/Meshes. Converting old into new format wouldn't be hard, so if somebody would like to use an old mod, they just install it into their own add-on folder

Next, I would recommend a plain YAML or text file, that declares which files should be used by the add-on, which files should be automatically loaded already on start-up, etc. If there are undeclared files in a mod folder, this could be detected automatically, same for typoes etc. If a file is supposed to be reused by another add-on, you could also declare it here or declare that you depend on that add-on. This way, we could make relations between add-ons more explicit, and instead of requiring C++ code for certain cases, this could happen already in the text file.

Also, adding and removing add-ons is much easier that way.

One troublespot I see there are planet textures, that might be better handled the old way, but we also have little to no bugs with them. Most bugs we get are in vessels and, much more rarely, in MFD plugins. Bases and Planets are pretty rare to cause errors, mostly because of the 2016 format change filtered out many older add-ons in general....

Ah ok, like in KSP

 

[cbradbury]

As far as installing addons, I always use the jones mod enabler for ALL my games, as you can instantly remove any addon which causes problems without affecting the main install.

As to which addons are the most popular, and thus worth updating, surely that list will vary wildly depending upon how people use the sim. For myself, I spend probably 90% of my time in LEO as I like station building. So orbiter 2010 is the one for me as I have access to dozens of station components. I also prefer real, or close to real, vessels (my favourite program of all is Gemini). Someone else would come up with a very different list to me if they preferred wandering around the solar system.

 

[jarmonik]

Currently, you have special subfolders in Orbiter, into which you have to place your files. meshes to meshes, textures to textures, etc. If you install another add-on, it installs itself into the same folders. If one add-on overwrites a file of another add-on, chaos happens. If a mesh is missing in the add-on zip, it crashes. A missing texture just looks strange.
I would suggest copying the approach of many other games and install each mod into its own folder. Instead of Orbiter/Meshes, they would go into Orbiter/Add-ons/MyAddon/Meshes. Converting old into new format wouldn't be hard, so if somebody would like to use an old mod, they just install it into their own add-on folder

That sounds like a good idea. It could be easier for everybody if add-on specific files are located in add-on folder.

Next, I would recommend a plain YAML or text file, that declares which files should be used by the add-on, which files should be automatically loaded already on start-up, etc. If there are undeclared files in a mod folder, this could be detected automatically, same for typoes etc. If a file is supposed to be reused by another add-on, you could also declare it here or declare that you depend on that add-on. This way, we could make relations between add-ons more explicit, and instead of requiring C++ code for certain cases, this could happen already in the text file.

That is also great idea, it's been on my mind long time. There's no dependency management of any kind right now and it must improve. Maybe the dependencies could be checked after liking the Launch button and before opening the rendering window. Maybe a popup window could display the missing dependencies and contain a download links.

One troublespot I see there are planet textures, that might be better handled the old way, but we also have little to no bugs with them. Most bugs we get are in vessels and, much more rarely, in MFD plugins. Bases and Planets are pretty rare to cause errors, mostly because of the 2016 format change filtered out many older add-ons in general....

Planetary textures are trouble some. There are not much bugs related to them but they are lacking mipmaps which is a performance problem because we need to generate and compress them on the fly. Also, if we could have a converter to convert old textures into a new format, we could discontinue the support and cleanup and simplify the code base.

We could maybe have a research project that analyses why add-ons crash and what is the most common cause. And then decide how to avoid these. I am pretty sure, the causes are in many cases really trivial.

That's a good idea. Maybe 20% - 40% of crashes could be avoidable. One common cause is likely a missing mesh and a null handle. Add-on dependency management could help with that. Also, we could consider loading a dummy mesh if the mesh not found, thus avoiding a null handle. But then again all mesh related API functions would need to know what to do with a dummy mesh like oapiGetMeshTexture(). The next this in likely GetDC failing to provide DC, maybe a dummy DC could be returned which might prevent a CTD. Also there are older addons simply not designed to work with external graphics clients and there's not much we can do about it.

 

[Urwumpe]

Planetary textures are trouble some. There are not much bugs related to them but they are lacking mipmaps which is a performance problem because we need to generate and compress them on the fly. Also, if we could have a converter to convert old textures into a new format, we could discontinue the support and cleanup and simplify the code base.

What functions would such a converter need to cover? For example, could a conversion "current version -> current version" make sense, that just looks for missing mipmaps and generates them?

And couldn't this also be used to introduce a new format for planet textures, that could make add-on installation and reusability better? After all, its just one source format more to cover.

Also, could make an index generating tool for Orbiter make sense, that could produce a texture catalog for each cbody after new textures were installed? This could maybe improve performance, allow more error checks without cutting into performance.

 

[JMW]

One troublespot I see there are planet textures, that might be better handled the old way, but we also have little to no bugs with them. Most bugs we get are in vessels and, much more rarely, in MFD plugins. Bases and Planets are pretty rare to cause errors, mostly because of the 2016 format change filtered out many older add-ons in general....

Planetary textures are trouble some. There are not much bugs related to them but they are lacking mipmaps which is a performance problem because we need to generate and compress them on the fly. Also, if we could have a converter to convert old textures into a new format, we could discontinue the support and cleanup and simplify the code base.

I've been dreaming of this since 2016.
Way over my head tho'

 

[nbcfrosty]

I think these ideas are great... Another thing that's possible is putting together a guide for an Orbiter install that's fully configured. A well put together guide can validate demand.

There are tools like this:

Wabbajack

Wabbajack is a Free and Open-Source automated Modlist Installer.

www.wabbajack.org

There are modlists for everything including minecraft.
I also remember going through lengthy overhaul guides for overhauling Morrowind for example.

Imo this is a good start:

Addon icon N

Orbiter 2016 - Fully Loaded - Distribution

Jul 29, 2024

an Orbiter 2016 distribution

• nbcfrosty
• Miscellaneous

If there was 1 fully loaded distribution of Orbiter that has a good chunk of the addons available properly configured/updated and it's maintained built by the community, imo that'd be ideal. So many people connect over modlists/overhauls.

 

[Lucy]

The nice thing about Orbiter's current approach is it's utterly unopinionated, so you can bring whatever addon management strategy you like to it - as long as Orbiter finds the files, it's happy. So you can manage those files via JSGME or depot or whatever, which is a freedom I quite like.

Changing how Orbiter finds addon content might break every currently existing addon, which isn't great but might be worth it. I would be in favour of a cleaner solution than just unzipping into the orbiter root too, like some more modern games do things with a mods folder as described - but, if those addon subfolders just shadow the Orbiter folders they need to copy files into then Orbiter can dirwalk the mods folder on startup and construct a sort of virtual filesystem with all the addons' files in their respective places, and load in from there. That approach would mean you could make existing addons work by just extracting them into a subfolder of their own.

 

[N_Molson]

These are valid concerns, but let's also keep in mind that KSP, which offers that kind of modularity, was launched in 2011 - which is now (already) 14 years ago. Also some of the older stuff won't work as it is with Orbiter 2024 anyway, and I fear we just have to bite the bullet there.

 

[Boxx]

I think "bundles" or "distro" make sense, but they'll have to come with "missions". A good example is OMP, that I am taking over as OMX: it is a complex addon and, without a gameplay, it is a huge work with very very few users. That's why I decided to develop OMX (the engine) as the continuation of OMP addon, and Nex'Orbiter (a distro, use case for OMX), with a selection of addons (so far 5) that are thoroughly tested before releasing (and, still, I need to develop the gameplay, which will be amazing, of course...). At least, the Nex'Orbiter distro is a single .zip to download and install, it is functional and will be growing further...

IMO, it is up to a user to offer a bundle and to make sure it is functional. A little help from the forum could be to create a subcategory of addons, or a flag, to identify bundles, where the bundle's creator could also promote the addons that are part of the bundle and explain the "missions" provided (or the intent, or gameplay...).

 

[Urwumpe]

@Boxx Yes, or simply put: If you want people to use your add-on, you have to provide scenarios, examples and manuals. Also, I don't mind people publishing even better scenarios involving one or more add-ons. It just adds more value to all of them.

What we currently can't do, is defining which add-ons (including version) are used in a scenario and only display scenarios, that are at least claimed to be compatible. What we could have in Orbiter with minimal effort is hiding scenarios with references to missing files.