Better support of Extension developers by learning what they actually are doing

[SilentRuin]

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.

[Moon Wizard]

Unfortunately, given that we have a single developer (me) who is handling generalization and backward compatibility for 2500 DLC spread over 15 years, in addition to helping the developer community with their questions and planning new core features; there is a very limited amount of bandwidth we have to spend on modding support. Even larger titles that allow modding that employ hundreds of developers break mods with updates regularly. We do the best we can with the resources available that can be supported by the market size of the community; and the fact that mods are not the primary driver of business. Since we are so resource-constrained, our strategy is generally to publish a rough idea of what has changed for larger updates, and depend on mod developers to monitor and update their code. Realistically, I already support close to 50 game system rulesets in varying degrees; and I don't have the bandwidth to support 100s of mods as well.

One of the reasons why I often tell you this ("Most of the extensions I have written have been done doing things I was told really could not be done.") is because the level of interaction that is needed to override behaviors at that level is often very intrusive and fragile to any core code changes; as well as usually not able to be well-implemented in a way that we would like to see for official support (or sometimes just bandwidth limit or lack of general need). If a developer moves ahead in building these very intrusive systems, it is expected that many updates will break their code.

I've been working to increase the visibility of the changes in the core code by posting in the forums; but realistically, not everyone even looks at the notes until something breaks in their mod. You are an exception in that case.

The quick patch I did last week to prepare for an upcoming feature was less announced and smaller in scope, but needed to better support internal build/testing of a new feature. I apologized for moving that one quickly as it broke a few mods that are more intrusive in their coding, even though the scope was small.

As you have stated, extensions are a risk, and we suggest that users start with no extensions in order to get an understanding of the product before adding additional code complexity.

Regards,
JPG

[Zarestia]

Just to add my own 2 cents:

I haven't had any critical impacts in extension & ruleset development which weren't fixable on the day they occured and I can count them on one hand, so this "problem" differs greatly from person to person.

[bmos]

Just to add my own 2 cents:

I haven't had any critical impacts in extension & ruleset development which weren't fixable on the day they occured and I can count them on one hand, so this "problem" differs greatly from person to person.

I agree. It's been especially easy since I started using git to provide diffs of the update packages and with Moon Wizard's more comprehensive documentation of updates of late.

[Valyar]

For me, the key to properly support developers is to have up to date and well written documentation with examples. The worst part is the DB, where there are so many options to do something and sometimes I spend a lot of time trying to figure out why and what I should do in this case. There is nothing worse for a developer of incomplete documentation or no examples.

Changes - I easily can find out what has changed, since I have CoreRPG in reference repository and every now and then I diff the ruleset between versions.

Thanks to Moon Wizard for the support before each release, I find very helpful the pro-activeness of identifying what should be updated in the store rulesets.

[MeAndUnique]

I'll echo the sentiment that (when I'm not on vacation) I've never had any real problems with quickly adapting to updates. Even when the functional goals of my extension necessitate being highly intrusive into the ruleset logic, I do my best to work with the underlying paradigms, so I typically only need to mirror the update changes.

I also fully agree that having complete API documentation is super useful. Though I'll disagree with the implication that examples are lacking; CoreRPG is rich with practical examples for basically any and every API interaction with a simple Ctrl+Shift+F, even those for which there is no documentation at all.

Honestly, on a semi-open source project, dedicated example code is a bit of a time waste. The best examples are found in real code that is clean and concise (and ideally unit tested, but that's a whole other can of worms).

[deer_buster]

I only check for changes when notified that there is an issue with a mod. It generally takes a bit before I find the notification in the forums about changes that affected my particular mods. I like the idea of storing a copy of the CoreRPG and base rulesets in a repository for each mod, so that I can quickly find the changes that might affect my mods (thanks for the idea Valyar) My only complaint with the current system is that it takes relatively quite a bit of time for the forge to update when we upload a change. Is there any way to speed this up, or automate it?

[Kelrugem]

My only complaint with the current system is that it takes relatively quite a bit of time for the forge to update when we upload a change. Is there any way to speed this up, or automate it?

How do you mean? When I upload something, it is immediately available Sometimes I need to refresh the Forge's website in order to see the new build in the list (or quickly exit and enter the build list), but this is quickly done, and once done the new build is there

[bmos]

I only check for changes when notified that there is an issue with a mod. It generally takes a bit before I find the notification in the forums about changes that affected my particular mods.

I used to take this approach, but when you have to override functions you sometimes need to watch for changes to string.match captures and such. If you miss them, users are unlikely to know since you are inadvertently reverting that part to a prior update and they're often quality of life fixes. IMO it's worth creating and reading git diffs for each script you touch when rulesets get updated (at least with some regularity, you can often get away with being a bit behind).

[deer_buster]

I used to take this approach, but when you have to override functions you sometimes need to watch for changes to string.match captures and such. If you miss them, users are unlikely to know since you are inadvertently reverting that part to a prior update and they're often quality of life fixes. IMO it's worth creating and reading git diffs for each script you touch when rulesets get updated (at least with some regularity, you can often get away with being a bit behind).

That's great and all, but I do that **** for real at my paid job...maybe sometime someone will invent a ruleset scanner that we can just put watches on and get notified of changes that we care about...