With the growing number of third-party add-ons, I think it's time LFS gets a plugin manager.

I'm thinking of something like the plugin manager of Firefox. You should be able to:
- View a list of currently installed plugins.
- Enable/disable a plugin.
- Uninstall a plugin.
- Check for updates of plugins, and download & install them.

In addition, LFS should fire up each plugin.

Other possibilities:
- View a list of available plugins, and download & install one.
- Resolve port conflicts between plugins.
- Verify if each installed plugin is version-compatible with LFS.

LFS has no plugin system whatsoever, no way of knowing how any existing addon is supposed to work, and no way of knowing how and when to start the application. This wouldn't just need a manager, it would need a complete system.

Good idea but quite a huge project.

Well in front-ends like Browse For Speed you can configure the add-ons that you want to start up along with LFS. This could (and should) be done by LFS itself.

OK, that's merely manual configuration. But once that is in, you can add some sort of protocol between LFS and the add-ons (e.g. by LFS reading a standardized config file from each add-on.)

Quote from wsinda :

OK, that's merely manual configuration. But once that is in, you can add some sort of protocol between LFS and the add-ons (e.g. by LFS reading a standardized config file from each add-on.)

What you're proposing isn't a solution to the hell we've currently got. What you're suggesting is a framework and a work around. Just what we need, another framework.

InSim/OutSim/Outgauge is cool, but it wasn't designed to work for more than one application connecting to each (I'm ignoring the fact that outsim and outgauge are talkable from within an InSim connection), and I can fully understand why. But it would be nice to see it all Just Work(TM), I'll agree.

Dygear presented an interesting idea in this thread: http://www.lfsforum.net/showthread.php?t=14927, which is an interesting way to go and would extend the current scripting system we have. I'm personally not sold on all the points, but thats neither here nor there.

At the end of the day, depending on how much Scawen would mind breaking all the existing tools out there, will result in how long it takes the situation to be fixed.

Personally I'm of the opinion that whilst the current system was good, its now time to die.

Quote from the_angry_angel :

What you're proposing isn't a solution to the hell we've currently got. What you're suggesting is a framework and a work around. Just what we need, another framework.

I wasn't going to suggest a framework. I simply noticed that there are many add-ons, that some people run several add-ons at the same time, and that it's a hassle to install them and make them tolerate eachother. For the geek it's a nuisance, for the non-geek it'll be terrifying. Something should be done IMHO.

Note that this is independent of the technology that the add-ons use to do their job (InSim, scripting, whatever). When you run multiple add-ons and/or want to try out new ones quickly, then a way to manage them comes in handy.

Quote :

InSim/OutSim/Outgauge is cool, but it wasn't designed to work for more than one application connecting to each (I'm ignoring the fact that outsim and outgauge are talkable from within an InSim connection), and I can fully understand why.

I haven't run into that myself, but then I only use one add-on, sometimes. If you're right then it's indeed useless to manage the add-ons.

Quote :

Dygear presented an interesting idea in this thread: http://www.lfsforum.net/showthread.php?t=14927, which is an interesting way to go and would extend the current scripting system we have. I'm personally not sold on all the points, but thats neither here nor there.

At the end of the day, depending on how much Scawen would mind breaking all the existing tools out there, will result in how long it takes the situation to be fixed.

(Hmm.. interesting thread.)
A good scripting system would be very nice -- but I guess it will require a major redesign of the engine. For S3, perhaps? Then Scawen has an excuse for breaking existing interfaces.

Quote from wsinda :

I wasn't going to suggest a framework.

The reason why I argue that its a framework is that, under your suggestion, all the addon program writers need to buy in to the idea of a standard config format (i.e. a standard interface, therefore a framework) and develop their programs around it. Unless you actually break the existing system in such a way that everyone has to conform to the new standard (rather than use something built on top the existing system), you'll never get every application to use the new method.

I love the idea, I honestly do, but I'm not convinced how useful it would be right now

Then again, its not my call. Who knows