Should SW look into adding key extension features?

[ddavison]

There are 435 extensions in the Forge and there are new ones added and changed regularly. This is in addition to the large # of different rulesets and extensions across official products. There is no way we would be able to test across all of them in any meaningful way and still get anything done.

Moon Wizard is out of the office at the moment, but we will evaluate to see what sort of steps we can take to minimize the impact on community devs in the future. I used to work in the corporate development world as a consultant and programmer for several decades, so I can share with him some things we used to do back then that helped. We have some constraints that are unique to our situation and some that are similar.

Regarding Extension handling if the community dev leaves or becomes unavailable:
Rob2E also planned the passing of his code to others because he knew his health was declining. This is an important step for devs to make, but it is a personal matter. There are also financial implications. Our main focus is to continue building the core experience to support people. When certain features rank high on the feature request list, and/or free extension list, then we look at building that sort of feature into our system. If that functionality is part of an extension on the Forge, we may reach out to the original dev to see if we can simply incorporate their code -- but often we just write our own version. There have been a couple cases where devs offered code for us to use. Sometimes we use their stuff as a base and sometimes we do a different approach. We also try not to actively compete with our community devs if this is something they are known for. That may happen at times, but we take that into consideration as well.

[SilentRuin]

There are 435 extensions in the Forge and there are new ones added and changed regularly. This is in addition to the large # of different rulesets and extensions across official products. There is no way we would be able to test across all of them in any meaningful way and still get anything done.

Moon Wizard is out of the office at the moment, but we will evaluate to see what sort of steps we can take to minimize the impact on community devs in the future. I used to work in the corporate development world as a consultant and programmer for several decades, so I can share with him some things we used to do back then that helped. We have some constraints that are unique to our situation and some that are similar.

Regarding Extension handling if the community dev leaves or becomes unavailable:
Rob2E also planned the passing of his code to others because he knew his health was declining. This is an important step for devs to make, but it is a personal matter. There are also financial implications. Our main focus is to continue building the core experience to support people. When certain features rank high on the feature request list, and/or free extension list, then we look at building that sort of feature into our system. If that functionality is part of an extension on the Forge, we may reach out to the original dev to see if we can simply incorporate their code -- but often we just write our own version. There have been a couple cases where devs offered code for us to use. Sometimes we use their stuff as a base and sometimes we do a different approach. We also try not to actively compete with our community devs if this is something they are known for. That may happen at times, but we take that into consideration as well.

Doing a search on keywords for the bulk of 435 text data when about to change names or remove things is not a huge expense to do. Not once did I mention testing. I mentioned searching existing 3rd party code you claim to allow and gauging the impact on changing keyword/names/anchors/args simply by seeing who currently uses them and coming up with a document (or not doing them) to show what has to be done to replace that functionality.

This is very doable. And simple.

[ddavison]

This is very doable. And simple.

No, it is not simple at all. It would mean you would have to constantly keep a current copy of every extension and ruleset on your system and then search it for any change you wanted to make. You could use the same names for things and use them in completely different ways. You would have to investigate every match and rule out any false positives, etc. What if you do find matches? Do you then contact each person, not make a change, or just note it on a changelog? None of those options are good or sufficient to alleviate the issue for devs.

[SilentRuin]

No, it is not simple at all. It would mean you would have to constantly keep a current copy of every extension and ruleset on your system and then search it for any change you wanted to make. You could use the same names for things and use them in completely different ways. You would have to investigate every match and rule out any false positives, etc. What if you do find matches? Do you then contact each person, not make a change, or just note it on a changelog? None of those options are good or sufficient to alleviate the issue for devs.

It is simple. You are removing or changing a named piece of code (IU or function matters not). A simple text search for all hits of that name will give you an IDEA of how much impact that change is about to have on the code base. Scripts can keep things from Forge up to date and unzipped on whatever search directory you wish to have them reside unzipped in. I do this now. It is simple if to a much lesser degree of 435 extensions. Mine is more along the lines of all your current rulesets and about 10 extensions.

Matters not what matches you get - you are doing and EXACT match search and you WILL get a scale of the impact you are about to make on the extensions. And trust me, names CAN be preserved. Legacy functions CAN be done.

You can say its not simple at all. But its not convincing me as I HAVE to do this now on a smaller scale already. What you really mean is its an extra task you do not wish to be burdened with as Extensions are largely on their own to deal with changes. And SW is not responsible for gauging any impacts a change will have on extensions.

For instance, I'm going to change "PowerManager.parsePower" argument list - how much of an impact will that be? (not a great example as usually there will be a raft of other rulesets impacted also)

C:\Old Machine\Dungeon and Dragon World\Fantasy Grounds Extensions\5E\scripts\manager_power.lua (2 hits)
	Line 2099: 	local tActions = PowerManager.parsePower(tData);
	Line 2326: 		local aActions = PowerManager.parsePower(tData);
  C:\Old Machine\Dungeon and Dragon World\Fantasy Grounds Extensions\FantasyGroundsExtensions\Equipped Effects Extention\Data\extensions\Unpacked\EquippedEffects\scripts\manager_equipped_effects.lua (1 hit)
	Line  519: 				sortedpowerdata = PowerManager.parsePower(tData);

Looks like the only people who directly call these functions are in 5E and Equipped Effects (though I fixed BCEG in my search directory also - it was also impacted - both of which will be busted). Thus there is a documented need to have a work around.

Its really that simple. Just building the directory of text to search is only task and that can be done by scripting.

[Morenu]

Smiteworks are very well aware of what extensions are out there and what they do. Many extensions have been included in the code in the past, usually those that do something fairly simple. They aren't going to add something like the behemoths that SilentRuin develops. Also you can't expect the code to stand still. If it did then there wouldn't be any new things in any ruleset ever again. And yes, SW do help extension authors - as do many people on the forums here.

Thx.

I hope that SW staff knows that we love the platform and have made an informed choice about it. I am glad that maintaining the Forge seems to have been a boon for everyone involved. As a user, i try to be respectful of all the hard work that is put into essentially my play time. So understanding some of that helps me and my expectations.

[ddavison]

The search thing is a non-starter. We simply disagree on the feasibility of that.

The example of the change to parsePower is something that could be managed differently to still allow for refactoring while not breaking a public interface. This is something we have spoken about internally in the past. The argument for building a new function called from the old function would improve backward compatibility and minimize the impact on community devs who may be using the old function definition. The argument against that approach is that the code gets bloated. I lean towards the first option, but we will review again with this clear example.

[SilentRuin]

The search thing is a non-starter. We simply disagree on the feasibility of that.

The example of the change to parsePower is something that could be managed differently to still allow for refactoring while not breaking a public interface. This is something we have spoken about internally in the past. The argument for building a new function called from the old function would improve backward compatibility and minimize the impact on community devs who may be using the old function definition. The argument against that approach is that the code gets bloated. I lean towards the first option, but we will review again with this clear example.

The ONLY thing I'm looking for is stability. I don't care what you do to achieve it - I DO NOT want to waste tons of hours every single TEST drop where stuff is no longer working. And spending time to get to where you WERE or ARE in LIVE again?

That is the worst. And it seems to be a regular pattern where things we were told to use or reference are changed without warning other than clicking a button and seeing a raft of Errors in the console.log.

I don't care how you solve it in the end, if I'm not adding new functionality I don't want my old functionality busted every 3 months.

And users don't want to have extensions that stop working not because something is no longer possible - but simple because the cards (code) has been shuffled in a way that kills the extension.

[LordEntrails]

I think a few things are "true" that are key to keep in mind:

1. Enhancing the capabilities of FG requires code changes
2. FG needs to continue to enhance capabilities to remain competitive in the market and for SmiteWorks to remain financially viable
3. SmiteWorks has limited resources
4. Community Devs generally do what they do for self-fulfillment (own use, love of the ruleset, love of community, etc) and not as a job or for money
5. Community Devs through at least their extensions and products add value to the FG community & the FG product.
6. FG code needs to be kept "reasonable" i.e. some level of manageable and supportable. Bloat is bad. More features mean more testing and complexity.
7. "We", the community, don't have our lively hoods tied to these decisions (maybe a few community devs actually do?), SmiteWork does. And the decisions are SmiteWorks to make.

I think there are two real/root cause issues here;

A) Keeping especially #2, 4 & 6 in mind, how can SmiteWorks reduce the impact of code changes? Not just but for community devs, but for themselves as well. (And while keeping the overhead impact to new development "reasonable"?)
B) How should the work that results from code changes be distributed between SW and Community Devs? There will always be a split, IMO it's not ideal for either side to bear the full "cost" of such changes.

[damned]

Not a response to you but to the post above mine. In your response you said SW had no idea what extensions are out there and what they do. I said they do know what extensions are out there and what they do. That does not equate with them not changing code in case it breaks extensions. Changing the code is, as I said, necessary.

From my perspective 5E already works.
Make 5E24 a new ruleset.
Stop continuously reworking stuff that works - many, many changes do not add functionality to the user - they are supposedly adding a benefit to the developers.
The challenge it creates for every other developer suggests that this benefit may be exaggerated.

There are so many game systems begging to be developed.
Divert your talented team to creating rulesets and widening your potential user base.

[Kelrugem]

@SilentRuin, I cannot evaluate your suggestion with the search stuff or whether or not a code change was really necessary, but in my case SW was certainly always eager to answer my questions regarding coding, and if a bigger patch was happening then I even got contacted privately on Discord to make me aware of certain things and to offer help. Thus, I would certainly not say that SW is not aware of the extensions and the devs out there, quite the opposite if even I (a smaller dev) gets contacted on Discord for such things

I totally understand that it is frustrating to update extensions, but with competition like Foundry there is certainly now even more a need to keep FG up to date with certain things, especially also regarding UI which is one of the most criticised aspects of FG so that we can expect changes in that regard. Though, as I said, I cannot evaluate explicit code changes in that regard, simply due to lack of experience.