Developer Notes - 2021-02 Ruleset Updates

[Valyar]

I tried! Now I get back to my corner to code

PS: I fully understand and agree with the arguments, just I am gonna miss the above-mentioned sidebars.

[Kelrugem]

@SilentRuin, @Kelrugem,
As superteddy57 mentioned, the ruleset code changes are exactly the same for both FGC and FGU. If an extension is updated to work with the changes, it should work in both.

Thanks Superteddy and Moon Wizard Then I was gladly not wrong in what I wrote

[celestian]

Updating the 2E ruleset and I noticed something that... I didn't see any updates for?

Previously this "target" indicator (as seen on the left side, DM) would appear on both host and client side. Now, just host. I reverted back to "Live" and checked previous code and indeed both client and host see it there... but not on Test channel rev.

Here is what I see when using Test channel.

[celestian]

Is there any chance we could get a "share image" option from the radial when using the "desktop image" view? Currently you have to revert back to the standard image in a window view to do so.

[MeAndUnique]

Any chance of some of the massive functions getting broken up a bit in the near-ish future? In particular ActionDamage.applyDamage() is a real challenge to interact with.

[deer_buster]

Any chance of some of the massive functions getting broken up a bit in the near-ish future? In particular ActionDamage.applyDamage() is a real challenge to interact with.

I think that is just the nature of the beast...the more complex the ruleset, the more complex the applyDamage...

[MeAndUnique]

I think that is just the nature of the beast...the more complex the ruleset, the more complex the applyDamage...

Sort of. I agree the overall complexity of the implementation will be related to the complexity of the system. However, it is certainly possible to break down any implementation, regardless of complexity, to simple building blocks. In fact doing just that is widely recognized as a critical aspect of writing clean code.

[deer_buster]

However, it is certainly possible to break down any implementation, regardless of complexity, to simple building blocks. In fact doing just that is widely recognized as a critical aspect of writing clean code.

I agree, in concept. However, simply breaking down code for the sake of breaking it down once you've taken it to the level of separation of concerns is a somewhat pointless effort in efficiency that has lower returns on investment....imho. In other words, I would rather the developer time be spent on adding features

[MeAndUnique]

I agree, in concept. However, simply breaking down code for the sake of breaking it down once you've taken it to the level of separation of concerns is a somewhat pointless effort in efficiency that has lower returns on investment....imho. In other words, I would rather the developer time be spent on adding features

On a technical aside, when 360+ lines of code are involved, concerns are not separated. Certainly each case is something that SW would have to evaluate priorities for. As the code is currently set up, it is extremely difficult for an extension developer to make improvements without overriding the method entirely (e.g. to support lifestealing attacks in 5e). In that regard, the code cleanup itself does basically nothing from a feature perspective, rather it is a force multiplier empowering the community to make optional enhancements more efficiently and with more stability. This in turn can actually accelerate feature development, as it is not terribly uncommon for reliable extensions to be integrated into the rulesets. Even if community contributions aren't considered, in my experience code cleanup on an active codebase has paid for itself within 6 months 100% of the time, so then its mostly a matter of which 6 month window makes sense for the roadmap if one is to consider the damage management portion of the ruleset an active codebase.

[bmos]

ActorManager.getType(x) -> ActorManager2.isPC(x) / (Cleanup)

Is this a typo? isPC seems to be in ActorManager.