Developer Notes - 2021-02 Ruleset Updates

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.

Quote:

---

Originally Posted by Moon Wizard

@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 :D

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.
https://i.imgur.com/Mcgmkmb.gif

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.

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.

Quote:

---

Originally Posted by 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.

---

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

Quote:

---

Originally Posted by deer_buster

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.

Quote:

---

Originally Posted by MeAndUnique

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

Quote:

---

Originally Posted by deer_buster

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.

Quote:

---

Originally Posted by Moon Wizard

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

---

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

Quote:

---

Originally Posted by MeAndUnique

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).

---

Serious question - where would you want integration points within the current code?

As an example, the CoreRPG code has various points where custom functions can be inserted. Which points would you see as being useful to add integration points for extension developers? And which ruleset/s are you referring to?

If people are expecting pristine code in a project that has been written by so many people (plus the ruleset authors and the extension authors) - with the resources involved here - dream on. This will always be a work in progress IMHO. I'm sure others disagree but that is my opinion on having worked on "many hands stirring" type of projects with 3rd party libraries tossed in for chuckles ;) Getting it working > making it look pretty.

Quote:

---

Originally Posted by Trenloe

Serious question - where would you want integration points within the current code?

As an example, the CoreRPG code has various points where custom functions can be inserted. Which points would you see as being useful to add integration points for extension developers? And which ruleset/s are you referring to?

---

I was going to sit down and type out the various hooks I'd find useful but the more I thought about it the more I determined I needed to override the entire thing to do what I'd need.

I think there could be some work to consolidate (even move to API) Effects tho. Getting it out of the LUA environment might help improve it's performance. I'd really like to see something done to improve performance on large chunks of data (iterating over large number of tokens, effects or npc is ponderous. How that can be improved, I dunno.

Quote:

---

Originally Posted by celestian

... I determined I needed to override the entire thing to do what I'd need.

---

SO hate when that happens. Why I call templates evil when trying to override their .lua especially.

Quote:

---

Originally Posted by MeAndUnique

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.

---

Sounds like you just volunteered. Good luck breaking it down to useful sections that can have good integration hooks with each other and extension writers. I'd be very interested in finding out how long it takes to get just one ruleset's applyDamage code fully optimized.

Quote:

---

Originally Posted by celestian

I was going to sit down and type out the various hooks I'd find useful but the more I thought about it the more I determined I needed to override the entire thing to do what I'd need.

I think there could be some work to consolidate (even move to API) Effects tho. Getting it out of the LUA environment might help improve it's performance. I'd really like to see something done to improve performance on large chunks of data (iterating over large number of tokens, effects or npc is ponderous. How that can be improved, I dunno.

---

I thought someone had mentioned that an effects engine overhaul was in the cards...maybe dreaming that though...

Quote:

---

Originally Posted by Trenloe

Serious question - where would you want integration points within the current code?

As an example, the CoreRPG code has various points where custom functions can be inserted. Which points would you see as being useful to add integration points for extension developers? And which ruleset/s are you referring to?

---

I think he was specifically referring to 5e...

@bmos,
You're correct on ActorManager.isPC(). I fixed in the notes.

Thanks,
JPG

Quote:

---

Originally Posted by SilentRuin

SO hate when that happens. Why I call templates evil when trying to override their .lua especially.

---

I've got so much "extra" maint work during updates like this because of 1 thing I need to tweak and it's not a "global" script I can just override a function for ;(

Not being able to merge/replace when using versioning on controls (version=">=4") makes me cry a little also.

Quote:

---

Originally Posted by deer_buster

Sounds like you just volunteered. Good luck breaking it down to useful sections that can have good integration hooks with each other and extension writers. I'd be very interested in finding out how long it takes to get just one ruleset's applyDamage code fully optimized.

---

That's a reasonable interpretation; I would happily make a merge request if there were a mechanism to do so. Roughly 2 hours of work between last night and this morning to accomplish a reasonable first pass.

Quote:

---

Originally Posted by Trenloe

Serious question - where would you want integration points within the current code?

As an example, the CoreRPG code has various points where custom functions can be inserted. Which points would you see as being useful to add integration points for extension developers? And which ruleset/s are you referring to?

---

The 5E ruleset is my primary interest, though I'm sure the concept would translate to others. I'm less interested in explicit integration points, though having one at the end would be useful, and more interested in more fine-grained definition of the functionality. There's a rather tight relationship between the Single Responsibility Principle and the Open and Closed Principle. In other words, if the code is broken down so that each function is responsible for doing one thing well, being able to extend any one thing becomes a very straight-forward process.

See here.

Quote:

---

Originally Posted by MeAndUnique

That's a reasonable interpretation; I would happily make a merge request if there were a mechanism to do so. Roughly 2 hours of work between last night and this morning to accomplish a reasonable first pass.



The 5E ruleset is my primary interest, though I'm sure the concept would translate to others. I'm less interested in explicit integration points, though having one at the end would be useful, and more interested in more fine-grained definition of the functionality. There's a rather tight relationship between the Single Responsibility Principle and the Open and Closed Principle. In other words, if the code is broken down so that each function is responsible for doing one thing well, being able to extend any one thing becomes a very straight-forward process.

See here.

---

Ugh - applyDamage? I already had to copy that stupid thing in an extension simply because it was missing one line for exceeded damage message for instant death buried in the dead center of the code that I intercept for polymorph transitions where damage is carried over. Extensions (sigh). Never ending keeping your eye out for surprise changes in the core code :(

Quote:

---

Originally Posted by SilentRuin

Ugh - applyDamage? I already had to copy that stupid thing in an extension simply because it was missing one line for exceeded damage message for instant death buried in the dead center of the code that I intercept for polymorph transitions where damage is carried over. Extensions (sigh). Never ending keeping your eye out for surprise changes in the core code :(

---

The changes in the link would make that no longer necessary; you could extend handleRemainderDamage() in the "safe" way.

Quote:

---

Originally Posted by MeAndUnique

The changes in the link would make that no longer necessary; you could extend handleRemainderDamage() in the "safe" way.

---

Exactly how would that replace every applyDamage logic for everything in the game again? Are you saying I'd only have to replace "less" things as opposed to the whole thing?

Quote:

---

Originally Posted by SilentRuin

Exactly how would that replace every applyDamage logic for everything in the game again? Are you saying I'd only have to replace "less" things as opposed to the whole thing?

---

Assuming that the linked changes were the way the ruleset handles it. For your case you could use the "safe" approach of doing something like this in your extension:

Code:

---

local originalHandleRemainderDamage;
onInit()
    originalHandleRemainderDamage = ActionDamage.handleRemainderDamage;
    ActionDamage.handleRemainderDamage = handleRemainderDamage;
end
function handleRemainderDamage(rTarget, nRemainder, nPrevWounds, rDamageValues, aNotifications, rDamageOutput)
    -- Your logic here
    return originalHandleRemainderDamage(rTarget, nRemainder, nPrevWounds, rDamageValues, aNotifications, rDamageOutput);
end

---

Quote:

---

Originally Posted by MeAndUnique

Assuming that the linked changes were the way the ruleset handles it. For your case you could use the "safe" approach of doing something like this in your extension:

Code:

---

local originalHandleRemainderDamage;
onInit()
    originalHandleRemainderDamage = ActionDamage.handleRemainderDamage;
    ActionDamage.handleRemainderDamage = handleRemainderDamage;
end
function handleRemainderDamage(rTarget, nRemainder, nPrevWounds, rDamageValues, aNotifications, rDamageOutput)
    -- Your logic here
    return originalHandleRemainderDamage(rTarget, nRemainder, nPrevWounds, rDamageValues, aNotifications, rDamageOutput);
end

---

---

How I would normally do it then when something is not buried in a template .lua or in the middle of some block of code. Your just breaking up the code into handlers then. Wanted to make sure it was not like some handlers where your extension is doing its own thing in a list of handlers. For global operations I'd want to make sure any handler was global - not stacked in a list being executed. So assuming that - it would be fine.

Quote:

---

Originally Posted by Moon Wizard

Yes, when weighing the pros and cons, the removal of the iconography of the sidebar was a big negative for me. However, the sheer weight of the maintenance and ability to make new rulesets/themes was severely hampered by the requirement. You'll notice that several of the changes over the last year were to reduce the overhead of setting up new rulesets/themes.

Regards,
JPG

---

I'm not a DEV guy but I like the ability to customize the user interface. Having text vs icons makes things easy but also 'boring' and remove some of the immersive experience. FGU is not a word processor. Why not offer both and default to text when no iconography is present but have an option to skin the UI for those who want to?

Getting all sidebar buttons to be shown is a lot of steps after this recent update.
Any chance of simplifying this to show all?

Quote:

---

Originally Posted by MeAndUnique

That's a reasonable interpretation; I would happily make a merge request if there were a mechanism to do so. Roughly 2 hours of work between last night and this morning to accomplish a reasonable first pass.



The 5E ruleset is my primary interest, though I'm sure the concept would translate to others. I'm less interested in explicit integration points, though having one at the end would be useful, and more interested in more fine-grained definition of the functionality. There's a rather tight relationship between the Single Responsibility Principle and the Open and Closed Principle. In other words, if the code is broken down so that each function is responsible for doing one thing well, being able to extend any one thing becomes a very straight-forward process.

See here.

---

I love your code, all neatly commented as well in case someone else is reading it (or in case you forget, I know I always did), good practice. Reminds me of when I used to do it, in 68000 Assembly.

Quote:

---

Originally Posted by bmos

Getting all sidebar buttons to be shown is a lot of steps after this recent update.
Any chance of simplifying this to show all?

---

What do you mean?

The visibility is controlled as usual, but now in the settings and not in the library :) There is a show "All" button, the other buttons, too :) So, very similar as before, just different place :)

Quote:

---

Originally Posted by Jiminimonka

I love your code, all neatly commented as well in case someone else is reading it (or in case you forget, I know I always did), good practice. Reminds me of when I used to do it, in 68000 Assembly.

---

Thanks! Who knows, if this one goes anywhere, maybe I'll take a stab at some others.

Quote:

---

Originally Posted by Arghun

I'm not a DEV guy but I like the ability to customize the user interface. Having text vs icons makes things easy but also 'boring' and remove some of the immersive experience. FGU is not a word processor. Why not offer both and default to text when no iconography is present but have an option to skin the UI for those who want to?

---

Theme developers could still change it back to using iconography if they desire, after all there are some themes that made the move to all text when the default was to use icons. Though it does take a bit more elbow grease when a theme wants to do more than swap out.

Quote:

---

Originally Posted by MeAndUnique

Theme developers could still change it back to using iconography if they desire, after all there are some themes that made the move to all text when the default was to use icons. Though it does take a bit more elbow grease when a theme wants to do more than swap out.

---

I am not sure whether it is really possible to change it back if needed, see here: https://www.fantasygrounds.com/forum...l=1#post576820 (the second part) :) But may depend a bit on how one reads the answer, may just be about the themes of SmiteWorks themselves and their maintenance (so, no separate theme with icons).

@bmos,
The buttons on the sidebar can be controlled via the Sidebar dialog off of the Options window now. Also, each of the sidebar "state" buttons can be dragged onto hot key bar for easier activation.

Regards,
JPG

@Arghun/@MeAndUnique,
I've laid this out in the post Kelrugem cited.

You can override to do whatever you like in an extension; but all the rulesets we sell will be following this model, and any changes will need to be owned by the extension developer. Believe me, once you have to support 20 different systems and 15 different themes, you'll see that model is not sustainable. In fact, we had about a third of the rulesets that had already gone in this direction for exactly that reason.

Regards,
JPG

Quote:

---

Originally Posted by Moon Wizard

each of the sidebar "state" buttons can be dragged onto hot key bar for easier activation

---

I noticed that about the options themselves, too. Awesome touch! This will save a lot of time for me (since some players like to roll death saves themselves and others like the auto-roll).

Quote:

---

Originally Posted by Moon Wizard

@Arghun/@MeAndUnique,
I've laid this out in the post Kelrugem cited.

You can override to do whatever you like in an extension; but all the rulesets we sell will be following this model, and any changes will need to be owned by the extension developer. Believe me, once you have to support 20 different systems and 15 different themes, you'll see that model is not sustainable. In fact, we had about a third of the rulesets that had already gone in this direction for exactly that reason.

Regards,
JPG

---

Thanks! I had made my own overrides with an extension to change the look and feel. I hope it won't be a lot more difficult that it is now. If it's just overrides like it is now I'm more than happy to give a look at the builtin extensions you provide.

I understand the rationale behind the change, I thought it would be impossible to switch back from text to graphical icons.

Are these being released today ?

Yes, we are having a meeting today where we will discuss the release and other project updates, then I usually release in PST afternoon. I will post a note to the City Hall forum when it goes Live.

Regards,
JPG

Quote:

---

Originally Posted by damned

I get the arguments for each and while there are some gorgeous sidebar icons I have used the Text versions for as long as its been available for the reasons Moon Wizard mentions - ease of creation and maintenance.

---

I’ll miss the beautiful Savage World themed buttons I REALLY think they add a lot to playing SW. As well as make FG look pleasing to the eye and “sexy” for those comparing VTTs esp for SW.

That said, for my Ruleset... I NEVER considered graphical buttons as I suck with graphics and I thought Celestian’s AD&D text buttons looked great and I yanked that style when I started working on it :)

So I HATE they are going but I’d be a hypocrite if I complained about it ;)

Thank you for this! It helped me fix an extesion I bought.