Replace using dynamic libraries, loaded on demand, with static libraries linked with core applications.
Keep a clear line between engine and game code; extensions must be possible to use without manual changes to any part of engine repository... and if it does need them, it's no longer an extension, but a candidate for a pull request or fork.
Why?
Simplifies engine changes
Even smallest reordering in any public part of script classes (Critter, ItemCl, etc) requires FOClassic.h edits, .dll/.so recompilation, and so on, and so on... additional work for exposing new stuff, fighting OS limitations, bla bla bla.
Allows game developers to utilize engine to much greater extend
FOClassic.h no longer being a bottleneck, allows games to use everything engine uses to function. Starting from not exposed class members, thru direct access to SScriptFunc, helper classes (Text, FileManager), etc.
Additionally, it opens a way for features which would most likely never go into old system, such as utilizing Debugger.cpp to track game-specific data, customizing game window, adding new datafile formats, custom protocol messages, etc.
When?
v7 forward, interrupting #15 process. I don't have neither time or will to deal with all kinds of .dll issues, so it will go live ASAP.
Extensions are dead, long live extensions.
How?
First version most likely will be pretty close in structure to "old" extensions, with GameOptions* adjusted here and there to keep at least part of old extensions code working as-is. Due to infamous check_look, extensions must be able to consume reserved functions; this have to be addressed by #29.
But. We'll see how it goes :smiling_imp:
Later, class will be expanded to provide deeper customizations which cannot be done within extensions.
As usual, CMake will be responsible for pre-configuring everything, with CMakeFOClassic.txtbeing able to not only add, but also remove any item from list. There might be stock extensions in future, but final decision about including them (or not) should be left to game developers. Stock extensions, if any, needs to be enabled by developers.
B-but...
Project is open-source, everyone and their cats can modify it at will.
While it's true, it's not always a smartest move if you want to keep updating engine; own changes will often end with fighting conflicts during bigger reworks. That time could be used to improve the game itself, instead of maintaining "alien" code.
It will be harder to write game extensions.
That's probably true. FOClassic.h made sure developers don't use something they should't; being "forced" to use engine sources it's easier to shoot own foot. It's up to devs to decide if they want to use safety net which GameOptions* will try to provide, or go wild.
What?
Replace using dynamic libraries, loaded on demand, with static libraries linked with core applications. Keep a clear line between engine and game code; extensions must be possible to use without manual changes to any part of engine repository... and if it does need them, it's no longer an extension, but a candidate for a pull request or fork.
Why?
Critter,ItemCl, etc) requires FOClassic.h edits, .dll/.so recompilation, and so on, and so on... additional work for exposing new stuff, fighting OS limitations, bla bla bla.SScriptFunc, helper classes (Text,FileManager), etc. Additionally, it opens a way for features which would most likely never go into old system, such as utilizingDebugger.cppto track game-specific data, customizing game window, adding new datafile formats, custom protocol messages, etc.When?
v7 forward, interrupting #15 process. I don't have neither time or will to deal with all kinds of .dll issues, so it will go live ASAP. Extensions are dead, long live extensions.
How?
First version most likely will be pretty close in structure to "old" extensions, with
GameOptions*adjusted here and there to keep at least part of old extensions code working as-is. Due to infamous check_look, extensions must be able to consume reserved functions; this have to be addressed by #29. But. We'll see how it goes :smiling_imp:Later, class will be expanded to provide deeper customizations which cannot be done within extensions.
As usual, CMake will be responsible for pre-configuring everything, with CMakeFOClassic.txt
being able to not only add, but also remove any item from list. There might be stock extensions in future, but final decision about including them (or not) should be left to game developers.Stock extensions, if any, needs to be enabled by developers.B-but...
GameOptions*will try to provide, or go wild.