Idea: Add-on or plugin for Flare

[sujiniku]

About the features that have been proposed for engine but not decided to use in flare-game, I think that these feature should be independent from the engine, such as a plug-in or add-on.

Also, flare should provide the such development environment of add-on or plugin.

When installing Mod that is using add-on, you will also need to C++ compile add-ons. That is, the add-on is not an INI file, add-on may be written C++,

The add-on used for each game is different, Therefore installing the add-on needs to be installed on the Mod side, not the engine side. For this reason, Mod will should be separated into an add-on part and an original part.

Perhaps, when installation, the user(player) will need a new command like the below. cd flare-game-addon cmake . && make

Also, the add-on will depend on the engine version. If the version with the engine is incompatible with the engine, the add-on will not be usable.

So, documents such as wiki for add-on developers need to be improved. #1558 "Textbook of Flare is needed."

[ghost]

Hello. This is not a bad idea, in itself, but i would like to remind people that a plug-in system is really hard to implement correctly. There are several problems, here:

• ABI compatibility: C++ ABI is not defined by the standard, which means that even different versions of the same compiler might have incompatible binaries. So, people usually do this by implementing a C library, because in C, binary compatibility is a lot easier to achieve, and to not broke. Easier. Not easy. People interested in this might be interested to search for the hourglass model in C++.
• licence compatibility: well, flare's code is under GPL, so... well, I'm not sure how that works with plug-ins. I mean it.
• API compatibility: considering flare is not closed-source, ABI might not be that much a problem, same as for licences. Or, at least, more a philosophical problem than a technical one. But, what about keeping APIs compatible for such a plug-in system?
• finally, the obvious security problem: a plug-in, at least on all systems I know about (well, not that hard, windows few years ago, and now linux, still have not tried the *BSDs) have the same rights as the process that calls it. If you can suppose that all plug-ins installed system-wide are reputed safe, how can you suppose the same from random code? A plug-in system is exactly like having LD_LIBRARY_PATH redefined.

Now, I think plug-ins are a very good idea, I just wanted to remind people eventually working on the subject to think about those points. Good luck.

[sujiniku]

Only when installing Mod, if we allow installing plugin, the player would almost prevent cracking aimed at plugins. Although it is unknown whether it is "plug-in".

Perhaps it may be better to say "extra runtime" etc.

Also, perhaps due to software dependency at compile time, it may be technically difficult to add plugin except during Mod installation.

When updating an plugin, by asking the player to reinstall together mod and plugin, we may optimize the combination of Mod and add-on , so I think that compatibility will be easy to secure. Also, Mod developers should provide to the players such plugin built-in Mod by himself / herself.

In other words, it is the Mod developer's responsibility and authority to incorporate plugin to use for Mod.

[sujiniku]

Perhaps in combination with the "Feature idea: Interaction in books via Events" #1625 function, this plugins may be written as INI files instead of C++. We should lead the Modder to using rather only INI as much as possible.