+- Discovery Gaming Community (https://discoverygc.com/forums)
+-- Forum: Discovery Development (https://discoverygc.com/forums/forumdisplay.php?fid=7)
+--- Forum: Discovery Developers Forum (https://discoverygc.com/forums/forumdisplay.php?fid=183)
+---- Forum: Discovery Unofficial Development (https://discoverygc.com/forums/forumdisplay.php?fid=389)
+----- Forum: Discovery Mod FLHook Projects (https://discoverygc.com/forums/forumdisplay.php?fid=266)
+----- Thread: The future of POBs (/showthread.php?tid=136815)
The future of POBs - Alley - 03-09-2016
The POB rework is something that's been largely discussed and mentioned over the past year, yet any information regarding it was hidden behind the DevShieldTM.
The real issue behind this lack of communication was that we didn't even know if it was feasible in the end as huge aspects of the plugin had to be reworked in order to allow this. After months of work on this plugin, we're getting close to it.
- What of the current POBs?
I expect this to be the first question to be raised.
The currently built POBs have already been separated from the future rework months ago, when the initial splitting was programmed and deployed. All current bases run under a logic known as "legacy". As the rework will introduce specialized POBs, moving legacy pobs to the new system is not recommended due to various issues that may arise. It's not impossible, but it's long, tiresome and complicated.
- What about unofficial servers?
The FLHook developers (aka me) have stopped providing new builds to unofficial servers a while ago after some drama with unexperienced server owners. The code remains freely available on git but it's largely inefficient to waste time with people that have no idea what they're doing. We still need to provide new dsacesrv builds in order to prevent these servers from crashing, but with some server owners refusing to upgrade from XP machines, even this has become a chore and waste of time as two builds need to be made for every change, one of them being on the outdated 2008 codebase.
As we strive to provide a more dynamic (and less boring) experience to the community, at some point harsh decisions must be taken and this is where we're at now.
- An explanation of the problem
Months ago the first part of the rework allowed us to handle POBs with diffent looks, loadouts and functionalities. For instance, the dynamic jumpholes are currently nothing else but disguised POBs. This is bound to change later as a different plugin specialized in solar object handling is introduced.
However the bulk of the problem was still there. The POB system was never intended to be versatile and all new additions were met with the need to rewrite chunks of code, sometimes quite large just to allow a simple feature.
If you dwelled into the POB configuration files, you could be led to believe modules and recipes are loaded dynamically from the config file. Well this is not completely true. The plugin only loads the properties from the configuration files, but all modules and recipes are hardcoded in the plugin. If you were to remove the cloak disruptor factory from the modules or the docking module from the recipes, nothing would change. Players would still be able to build them, which would most likely cause a lot of exceptions to happen for attempting to load uninitialized data. To sum up, BAD.
- How to fix it
The theory is quite simple, but doing it is quite less.
What we have to do is throw away a fair bit of the code and rewrite it to support dynamic loading of modules and recipes. This means replacing everything related to hardcoded modules and recipes then ensuring the modules can still reference themselves properly.
A true dynamic plugin is impossible, down the road you still need to tell it what it will do. You can't, say, create an automatic miner module without coding the system to "mine". But what can be done is creating a generic logic to provide the base with items depending on criterias you are able to define in the configuration. A lot of similar things can be done with minimal effort with this approach, such as shield modules with different damage reduction levels and different consumption commodity & rates. With this kind of approach, we could introduce a new shield module in less than one minute.
Code will always be needed, but the more you can handle with generic foundations, the better.
Part 2 is coming later. I'll explain what you can expect from the new system. The thread will be unlocked for comments once all parts are posted.