SilentRuin
July 23rd, 2022, 17:06
A suggestion for FGU devs,
If nothing else, the last few weeks have hammered home the point that FGU devs really do not know what aspects of the rulesets and engine extensions are using to do things they need to do. My greatest fear is when I hear that things are being rewritten to make things easier - only to discover the changes were made with no real understanding on what extensions were doing and in some cases making things harder and more confusing. I also regularly get burned by the "didn't think anyone would need to do this, why don't you do this?" reasoning when they make these changes. The real reason there are extensions are that they are doing something the FGU devs, for whatever reason, deemed "undoable" or just did not think it was needed. Guessing what we need in terms of functionality, and my experience these last two years have shown me is a losing proposition for impact to extension developers.
Most of the extensions I have written have been done doing things I was told really could not be done. Largely by trial and error, and the rule of thumb of "not perfect, but good enough". I seem to be prone to being burned by more changes "to make my life easier" than anything else - and this largely due to the fundamental issue that FGU devs have no clue on what or why we had to do things to get things that should not work in the existing framework - to work. I'm not sure how this educational gap can be bridged - but I would like there to be some effort to bridge the gap.
Examples of Overrides that FGU does not "think" need to be overridden to get the job done, but really is the only way to do it in the engine/ruleset framework we have to work with. Its especially problematic when they go in thinking they know what is needed to be done without ever actually having tried to do it in the existing engine/ruleset framework. Personally I do things like the following that ends up getting broken a lot:
Turning PC to NPC or NPC to NPC and back again with modifications in the CT. Controlling the NPC at player end completely - with no need of vision option and able to have host CT actions of NPC usable by player regardless of faction. Allow player CT to only see what they own/same faction/group in order to never have players see something in CT that they can't see on map. Doing common functionality where PC/NPC DB entries are forced to be managed in the same way and same place. Manipulating the host and client CT's to support groups of CT entries that can be visible or not at host or player side but still fully functional in map on either side (without CT entry visible). Managing data fully across inventories in PC/NPC/party sheet/parcels. Support of 3rd party supplemental modules to main modules and allowing module priority as opposed to random alphabetical order global search priority (which can be changed simply by removing and readding a module) - this includes modifying charwizard to actually give control to users on what modules are actually used and priority they are accessed.
And a lot more. None of which are done by FGU or even possible without serious overrides of some very low level functions that will allow things to be manipulated in a common set of code. Even when they claim it can be done in some cases - it really cannot in the cases we are trying to actually do.
And that's just me. Somehow FGU devs need to be brought on board with how their code is used by extensions so we suffer less from code changes designed to "help us".
How will this be done? No idea. But in the programming world where the app claims they support manipulation by 3rd parties (extensions/rulesets) its very common for the devs to get a thorough understanding of how the 3rd parties are using their code. Not just guessing on how they are using it.
If nothing else, the last few weeks have hammered home the point that FGU devs really do not know what aspects of the rulesets and engine extensions are using to do things they need to do. My greatest fear is when I hear that things are being rewritten to make things easier - only to discover the changes were made with no real understanding on what extensions were doing and in some cases making things harder and more confusing. I also regularly get burned by the "didn't think anyone would need to do this, why don't you do this?" reasoning when they make these changes. The real reason there are extensions are that they are doing something the FGU devs, for whatever reason, deemed "undoable" or just did not think it was needed. Guessing what we need in terms of functionality, and my experience these last two years have shown me is a losing proposition for impact to extension developers.
Most of the extensions I have written have been done doing things I was told really could not be done. Largely by trial and error, and the rule of thumb of "not perfect, but good enough". I seem to be prone to being burned by more changes "to make my life easier" than anything else - and this largely due to the fundamental issue that FGU devs have no clue on what or why we had to do things to get things that should not work in the existing framework - to work. I'm not sure how this educational gap can be bridged - but I would like there to be some effort to bridge the gap.
Examples of Overrides that FGU does not "think" need to be overridden to get the job done, but really is the only way to do it in the engine/ruleset framework we have to work with. Its especially problematic when they go in thinking they know what is needed to be done without ever actually having tried to do it in the existing engine/ruleset framework. Personally I do things like the following that ends up getting broken a lot:
Turning PC to NPC or NPC to NPC and back again with modifications in the CT. Controlling the NPC at player end completely - with no need of vision option and able to have host CT actions of NPC usable by player regardless of faction. Allow player CT to only see what they own/same faction/group in order to never have players see something in CT that they can't see on map. Doing common functionality where PC/NPC DB entries are forced to be managed in the same way and same place. Manipulating the host and client CT's to support groups of CT entries that can be visible or not at host or player side but still fully functional in map on either side (without CT entry visible). Managing data fully across inventories in PC/NPC/party sheet/parcels. Support of 3rd party supplemental modules to main modules and allowing module priority as opposed to random alphabetical order global search priority (which can be changed simply by removing and readding a module) - this includes modifying charwizard to actually give control to users on what modules are actually used and priority they are accessed.
And a lot more. None of which are done by FGU or even possible without serious overrides of some very low level functions that will allow things to be manipulated in a common set of code. Even when they claim it can be done in some cases - it really cannot in the cases we are trying to actually do.
And that's just me. Somehow FGU devs need to be brought on board with how their code is used by extensions so we suffer less from code changes designed to "help us".
How will this be done? No idea. But in the programming world where the app claims they support manipulation by 3rd parties (extensions/rulesets) its very common for the devs to get a thorough understanding of how the 3rd parties are using their code. Not just guessing on how they are using it.