Plugins directory in Spring and in mods?

[hughperkins]

It could be interesting to add the possibility of loading plugin dlls into Spring. This would make it possible to extend Spring, and to publish these extensions immediately for use within the current release version of Spring.

From an admin point of view, all dlls in the plugins directory of Spring could be loaded, and also all dlls in the plugins directory of the loaded mod.

The dlls could be loaded by calling a single function InitSpringPlugin() during PreGame, just after loading the mod file system.

For this to be useful, obviously EXPORT_DLL would need to be added to most classes within Spring.

It's possible that conserving many extensions permanently within plugin dlls would not only make their upgrade and distribution easier, but would also significantly streamline spring core, reducing build time.

Examples of plugin dlls:
*Lua mission plugin with extended lua functionalities, such as ability to run AIs within the mission. This exists within Spring SVN but it's unusable by other players prior to the next Spring release rollout
*Mission script plugin that loads missions written in other languages, such as Python or Mono
*New pathfinder
*New weapon types (what we normally see in Sim/Weapons)

Note that ultimately much of what is in Spring core, such as weapon and move types, could be shifted into plugin dlls, significantly reducing Spring core build type, and enhancing Spring flexibility.

Thoughts?

[AF]

This is what groupAIs are.

Altho weapon types arent supported by them.

You can also put globalAI's/skrimish AI in helper modes sharing with users but the lobby doesnt support it so nobodies ever written one for that purpose.

[hughperkins]

This is what groupAIs are.

Altho weapon types arent supported by them.

Nor are missions.

[Tobi]

You'd have to take special care to not make classes that run any kind of synced code overridable, unless a system is written to checksum plugins too in multiplayer games (or not load them).

Also it will make the build system a whole lot more complex.

Cross platformness is most probably harder to maintain if this gets popular.

[hughperkins]

You'd have to take special care to not make classes that run any kind of synced code overridable, unless a system is written to checksum plugins too in multiplayer games (or not load them).

That's a good observation. That's a good argument for only loading plugins from within the mod itself (so everyone has the same plugins), at least for multiplayer games.

Are mods included in the checksumming process? In other words, can we assume that each person in a multiplayer game will have the same mod and therefore the same plugins?

[Peet]

Isn't this the sort of thing that OSRTS will acheive?

[jcnossen]

You'd have to take special care to not make classes that run any kind of synced code overridable, unless a system is written to checksum plugins too in multiplayer games (or not load them).

Also it will make the build system a whole lot more complex.

Cross platformness is most probably harder to maintain if this gets popular.

IMO those are all very good arguments for sticking to a scripting language such as lua only ...

Isn't this the sort of thing that OSRTS will acheive?

Yes, part of it. OSRTS is being designed from start with pluggability in mind.

[hughperkins]

Cross platformness is most probably harder to maintain if this gets popular.

IMO those are all very good arguments for sticking to a scripting language such as lua only ...

Oh, hmmm, portability means cant put a native-code plugin into the mod.

[Tobi]

Yup, thats what I mean. It shifts the responsibility to make spring cross platform from us, engine developers, to modders.

And - no offense - I don't really trust modders to write good, cross platform C/C++ code (will just give lots of crashes ).

So indeed I agree with jcnossen: for mods, stick with scripting.

[hughperkins]

Yeah, I've been using C# so long, I forgot that it's possible to create non-portable dlls.

Note that it would really be a shame if osrts became a victim of the same issue.

[jcnossen]

That's why we're going to have C# binding for osrts.

[hughperkins]

That's why we're going to have C# binding for osrts.

Bindings are good, but there's a significant development overhead to create these.

[hughperkins]

(Or, to put it another way: whether you use C# or C++ you're going to have bindings. The choice is between:

*create bindings for each interface exported by osrts, osrts core is in C++
*create bindings for osg, osrts core is in C#, plugins are seamless
)

[AF]

That would require bindings for CEGUI and so on, and it would also be nuking any chance of editing osg in any meaningful way. Not to mention the overhead of


[data]->osg->bindings->engine->bindings->cegui->bindings->engine->osg->bindings->engine->plugins->engine->bindings->cegui->bindings->engine->cegui...

versus

[data]->osg->engine->cegui->engine->osg->engine->bindings->plugins->bindings->engine->cegui->engine->cegui...

And what if jelmer wanted to change osg to use his own data structures? Or to share CEGUI structures etc? It'd be a heck of a lot more work with what you've been suggesting with a C# core engine.

And what about C++ code thats planend to be brought forward? For example TDFParser and the other classes that use boost, I very much doubt there's a boost library for C#, or a wish tor code those classes that work fine as is..

[jcnossen]

And what if jelmer wanted to change osg to use his own data structures? Or to share CEGUI structures etc? It'd be a heck of a lot more work with what you've been suggesting with a C# core engine.

OSG is very open and very much centered around implement your own classes that fit in the scene and renderstate manager. I think that's its going to kill anyone's motivation if you have to build a C# wrapper for that, we would never even get started with osrts itself.

And what about C++ code thats planend to be brought forward? For example TDFParser and the other classes that use boost, I very much doubt there's a boost library for C#, or a wish tor code those classes that work fine as is..

As a sidenote, the boost based TDFParser is GPL, so its unusable for us (And boost::spirit is way to much for a config parser, my "hand written" TDF parser is 4 kb )

[MadRat]

I'd rather use the modinfo file for loading DLL's at startup of a game. That way you don't load unnecessary files.