Developer Notes - 2021-02 Ruleset Updates

[Moon Wizard]

NOTE: These changes will be released on Feb. 16.

I have been working on a large set of updates for rulesets in an ongoing fashion, in addition to the work we're doing on FGU. Once FGU was released, we decided to divorce the client releases (FGC/FGU) from the ruleset releases.

Since this is the first big push of updates since FGU launched, I still wanted to give a test period where ruleset and extension developers can adapt their code to work with the latest underlying ruleset changes. Additionally, there are a few rulesets which have errors, since they have overwritten low-level CoreRPG functions that have been replaced, so I will be reaching out to those developers directly.

The included FG themes (Simple Brown, Simple Gray, FG Light, FG Dark) have already been updated; but other art pack themes will be updated as we move forward.

This update is currently in the Dev channel only.

Regards,
JPG

[Moon Wizard]

Updates

[CoreRPG+] Sidebar buttons migrated to smaller text-based buttons.
[CoreRPG+] List add buttons made to be always visible.
[CoreRPG+] Tooltips added to campaign list groups
[CoreRPG+] Character desktop list can be unlocked and moved.
[CoreRPG+] Image toolbar toggle tracks separately for GMs and players.
[CoreRPG+] Image toolbar always available when sent to background.
[CoreRPG+] Image toolbar moved to right side.
[CoreRPG+] Current option values can be dragged to hot keys, and activated there.
[CoreRPG+] Add paging to Module Activation window to improve speed.
[CoreRPG+] Add Ruleset/Generic, Loaded, and Shared filter toggles to Module Activation window.
[CoreRPG+] Add Message of the Day campaign option
[CoreRPG+][FGU] New image record initial window size increased.
[CoreRPG+][FGU] Token lock toggle button added to the GM image toolbar.
[CoreRPG+][FGU] Any image asset can be set as a background tabletop decal.
[CoreRPG+][FGU] Limit asset search to 3 or more letters.
[CoreRPG+][FGU] Last asset type filter in Assets window is remembered.
[CoreRPG+][FGU] Add Ruleset/Generic filter toggle to Module Activation window.
[CoreRPG+][FGU] NPC import file button added to NPC campaign list.
[5E] Off-hand PC weapon damage would be converted to untyped. Fixed.
[5E] Extra space in NPC size/type/alignment summary when record locked. Fixed.
[5E] Racial language traits containing punctation were not handling correctly on drag and drop. Fixed.
[PFRPG] Advanced Class Guide did not load when using Setup window to load All Rules. Fixed.
[DEV] Actor resolution helper scripts updated to support additional record types.
[DEV] Actor health helper script added.
[DEV] Global scripts changed to use indirect referencing of contained functions.

[Moon Wizard]

For developers, the changes to the following rulesets are significant enough that I will not be outlining each file/asset changed.

Rulesets Affected
CoreRPG
3.5E
4E
5E
Cypher/Numenera/The Strange
Fate Core
PFRPG
SFRPG
13th_Age
Castles and Crusades
CallOfCthulhu
d20 Modern

Any specific updates for these rulesets will be gated until all the changes are released.

[Moon Wizard]

In order to support ruleset and extension developers, I have made a number of notes regarding changes that should be made to bring rulesets and extensions in-line with the changes to the others.

EXTENSION DEVELOPER SPECIAL NOTE: Make sure to pay close attention to last section of Required Changes. Also, some rulesets may have already have the ActorManager2 -> ActorManager<System> change applied. (Such as 5E, 4E, 3.5E, etc.)

Ruleset/Extensions - Required Changes

Add tags to support right click export
* <export>character</export> -> windowclass charsheet
* <gmexport>npc</gmexport> -> windowclass npc

Support updated chat window
* Remove unnecessary non-local chat window overrides; or adapt to identity list embedded
* Remove idactivefont/idinactivefont assets
* Remove identitylist panel, window, and script
* Remove identitylist_entry window and script
* Remove GMIdentityManager overrides (or fix to work with newest)

Support updated sidebar
* Remove DesktopManager overrides (or fix to work with newest)
* Add frames (if needed)
** button_sidebar_dockitem/button_sidebar_dockitem_down
* Add font (if needed)
** button_sidebar_dockitem

ActorManager and ActorManager<System> rewrites
* Review 5E ruleset to see ActorManager5E changes/calls for examples
* Rewrite deprecated actor manager calls
** ActorManager.getActor(_, x) -> ActorManager.resolveActor(x)
** ActorManager.getActorFromCT(x) -> ActorManager.resolveActor(x)
** ActorManager.getType(x) -> ActorManager.isPC(x) / (Cleanup)
* Remove other old actor manager variables not needed
** Any "pc" references with regards to actor manager (all references should be by record type)
** msgOOB.sSourceType/sTargetType are no longer needed with resolveActor changes
** Similarly, <actortype> tag no longer needed with resolveActor changes


Ruleset - Suggested Maintenance Updates

Make all add buttons visible by default
* Search for any template/control using button_iadd template/graphic; and make sure it does not have invisible tag
* Search for "iadd.setVisible" and remove when needed. (Make sure NOT to remove from ct_entry.lua.)
* Then, search for "iedit.setVisible", and add matching ...iadd.setVisible where needed.

Remove redundant action icons
* Remove action_* icons already in CoreRPG unless replacing all of them
** action_attack, action_damage, action_effect, action_heal, action_option, action_roll

Convert variables for efficiency
* User.isHost() -> Session.IsHost
* User.isLocal() -> Session.IsLocal

Support updated sidebar
* Remove .aDisplayIcon from record type registration
* Remove icons
** Example - CoreRPG: button_book, button_characters, button_encounters, button_items, button_maps, button_notes, button_parcels, button_people, button_quests, button_tables, button_vehicles, button_library, button_tokencase, button_assets,

ActorManager<System> rewrites
* Rewrite deprecated actor manager calls
** ActorManager2.getPercentWounded -> ActorManager2.getWoundPercent / ActorManager2.getHealthStatus
** ActorManager2.getWoundColor -> ActorManager2.getHealthColor
** ActorManager2.getWoundBarColor -> ActorManager2.getHealthBarColor
* Optionally rename "ActorManager2" to "ActorManager<System>"

[damned]

For developers, the changes to the following rulesets are significant enough that I will not be outlining each file/asset changed.

Rulesets Affected
CoreRPG
3.5E
4E
5E
Cypher/Numenera/The Strange
Fate Core
PFRPG
SFRPG
13th_Age
Castles and Crusades
CallOfCthulhu
d20 Modern

Any specific updates for these rulesets will be gated until all the changes are released.

CallOfCthulhu or CallOfCthulhu7E?

[Simpe]

How do I test this for my own ruleset? Is there a way I can get hold of a beta-branch of the client or something?

/S

[damned]

Its not in Test...

[tahl_liadon]

.
quick and perhaps silly question: if i decided to freeze and not update fg classic -- say for 6 months -- will i be able to continue using current version for that long with no further updates whatsoever?

more importantly, if i asked my players to freeze as well, what would be issues for them within that period?

this sounds like a huge update and i imagine it would take a few months afterward to continually iron out bugs. i just want to stick with a stable version until then.

thx

[RobboNJ69]

Same question as tahl. Thanks!

[Ulric]

These changes look great! I see several improvements that users have been asking to be added. If you're running FG locally or with port forwarding I think you would be fine to not upgrade. As long as nothing changes with the cloud connections then you could stop updating. The problem I see with not updating will mean the GM and Players can't purchase anything from SW and add it to their copy FG as that is done using the update feature. You would also need to make backups of the GM and Players installation folders and the campaign folders, so you could revert back if someone accidentally presses the upgrade button. Sounds like too much work to me, but maybe not for you.

[mattekure]

Its not in Test...

It is in the Dev Channel for now.

[Moon Wizard]

@damned,
CallofCthulhu (6E) has already been updated in the Test channel. As outlined in the separate e-mail, I have reached out about CoC 7E.

@Simpe,
It is currently in the Dev channel only. I have updated the first post; and you are also copied on the separate e-mail.

@tahl_liadon, @RobboNJ69,
You could potentially not have anyone update, if that's what you want. However, these changes will either create an instant issue in a ruleset, or none. They will get addressed pretty quickly; even if I have to push the changes myself. I've already reached out to all the ruleset developers to make the necessary changes.

Regards,
JPG

[Valyar]

I moved to the DEV branch on a reference virtual machine and did some runs on several rulesets. Two things strike immediately:

1. Problem with the reference manuals. Upon opening we have Console errors and warning. Navigation buttons are no longer there. Is this something that we have to sort on our end?

[1/30/2021 1:20:06 AM] [WARNING] window: Anchored static height ignored for control (page_prev) in windowclass (reference_manual)
[1/30/2021 1:20:06 AM] [ERROR] window: Control (page_prev) anchoring to an undefined control (page_info) in windowclass (reference_manual)
[1/30/2021 1:20:06 AM] [ERROR] window: Control (page_prev) anchoring to an undefined control (page_info) in windowclass (reference_manual)

2. The change Make all add buttons visible by default is something I hope you will reconsider rolling back. Character sheets have ruined aesthetics now and even in CoreRPG it looks out of place. I don't get the reason for this change, the functionality gain is close to none and reduce the experience from using the sheet.

I love the filtering of modules per ruleset and moving the sidebar toggle to Options rather than library. It is spot on. Text-based sidebar is also great

[Moon Wizard]

For #1, this is most likely caused by overrides to CoreRPG reference manual templates or window classes. In general, you should avoid overriding the templates, and use merges on window classes to make spot adjustments.

For #2, this came by request from ddavison. We have been slowly moving towards using buttons to allow user interactions, so that not as many features are "hidden" behind context menus and edit buttons. This is similar to most UI systems used for web/mobile applications. We plan to continue moving in this direction. If you want to override for specific sheets, then you should do so; but we want the campaign lists and other common elements to contain the buttons.

Regards,
JPG

[Valyar]

This is similar to most UI systems used for web/mobile applications.
I wouldn't say that this is good example to follow :) Probably it will take some time to get used to and all rulesets adjust their interfaces accordingly.

[Moon Wizard]

I updated post #4 to clarify between required and suggested maintenance updates. As noted in the emails to each developer, I am offering to do the initial and maintenance migrations; just need your assistance with testing after.

https://www.fantasygrounds.com/forums/showthread.php?65561-2020-02-Ruleset-Updates&p=574220&viewfull=1#post574220

Regards,
JPG

[Varsuuk]

I'm sorry if this is a stupid question, but what does:

"Remove unnecessary non-local chat window overrides; or adapt to identity list embedded"

refer to so I can look at this and see if it appears anywhere.

[Moon Wizard]

It's available in the Dev channel now. Just switch to Dev in your Settings, run an Update, then create a CoreRPG campaign.

Basically, I moved the list of names that used to appear under the chat window into a combo box that is part of the chat window. One less dangling piece of the UI, and can be moved with the chat window.

Regards,
JPG

[Varsuuk]

Oooo now I know what “identity” meant, thanks ;)

[Kelrugem]

2. The change Make all add buttons visible by default is something I hope you will reconsider rolling back. Character sheets have ruined aesthetics now and even in CoreRPG it looks out of place. I don't get the reason for this change, the functionality gain is close to none and reduce the experience from using the sheet.

I concur with Valyar on that, but I understand the reasons behind this :) I think there might be a possible compromise: Maybe changing the icon for the add button a bit? For most themes the white plus on green ground does not really fit, I think changing the icon that it fits to the style of the theme solves the problem :) But all the official themes would need to be changed in order to take this into account (or one finds one good icon for all rulesets)

(I personally also prefer buttons for the sidebar than text based things, but that change I can completely understand, probably way easier to adjust and maintain with that new approach)

[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

[RobboNJ69]

Ulric, Moon Wizard; Thank you for the information & updates!

[deer_buster]

Just checked Dev path, looking at 5e campaign. I like that the sidebar buttons are simple now, but kind of looks "plain" and "uninteresting" now.

[deer_buster]

For 5e specifically, ordering of the sidebar could be better. Races should be closer to Backgrounds and Classes, since those are the first 3 options you choose when building a character.

[lostsanityreturned]

For 5e specifically, ordering of the sidebar could be better. Races should be closer to Backgrounds and Classes, since those are the first 3 options you choose when building a character.

Aren't 5e character mainly using the wizard when building characters now though?

[deer_buster]

Aren't 5e character mainly using the wizard when building characters now though?

I don't, but that's not to say that it isn't used mainly by many.

[damned]

Has anyone tried DEV with a Player Client?
On a player connection I am unable to create Charcaters.

[deer_buster]

Has anyone tried DEV with a Player Client?
On a player connection I am unable to create Charcaters.

I just connected. It didn't give the "plus" to add a new character, but the Character Wizard was there (for 5e) and it let me successfully create a character. I definitely don't approve of "forcing" players to use the wizard in the slightest.

[Kelrugem]

I just connected. It didn't give the "plus" to add a new character, but the Character Wizard was there (for 5e) and it let me successfully create a character. I definitely don't approve of "forcing" players to use the wizard in the slightest.

As far as I can see that is also the case for other rulesets, that is, a missing plus button for players even though there is no character wizard :) So, no worries, that is certainly a bug, and no way of "forcing"; I doubt that the typical character creation gets abandoned, there is not really a reason for that :)

[superteddy57]

I just connected. It didn't give the "plus" to add a new character, but the Character Wizard was there (for 5e) and it let me successfully create a character. I definitely don't approve of "forcing" players to use the wizard in the slightest.

Your DM can setup a blank character sheet and you can take ownership of that sheet to create a character the old fashion way. You are not forced to use the wizard. You are still able to create characters outside of the session as well.

[damned]

Nope. CoreRPG has no ability for players to create charcaters.

[deer_buster]

Your DM can setup a blank character sheet and you can take ownership of that sheet to create a character the old fashion way. You are not forced to use the wizard. You are still able to create characters outside of the session as well.

I hope that you are just giving a temporary workaround, and that isn't the "solution", because it isn't one. Imagine all of the reasons why you have to start a new character over from scratch, not only while you are building it (changed your mind on Race or Class, for example), but also for existing characters (changed your mind on which class you wanted to add at level up, etc.), and then requiring the GM to add blank character sheets for the player each time. I'm sorry but having to micro-manage players isn't what a GM should be doing...maybe for new players that have never played the ruleset or FG....but for veteran players, never.

[damned]

Im sure its a bug...

[Moon Wizard]

It was a bug. Pushed a new update to Dev channel that fixes.

Regards,
JPG

[Moon Wizard]

OK, I just pushed a fresh batch of updates to the Dev channel of both FGC and FGU. I plan to push all of these to the Test channel on Thursday, with the plan to release on Feb. 16.

In addition to a few minor CoreRPG fixes, the developer and/or myself have updated and confirmed all the official rulesets with the required updates, except the following:

2E
MGT1
MGT2

Those developers are already aware of the upcoming changes; and will be looking at them soon.

As mentioned before on this thread and via email, I'm available to help keep these updates moving as fast as possible. Some of the upcoming lighting/vision changes will need CoreRPG ruleset updates soon after; so I'm pushing hard to make these in-process changes happen before the bigger release.

Regards,
JPG

[deer_buster]

Not sure what is going on, but yesterday and today when I try to open the reference manual in 5e, I get a crapload of error messages.


Ruleset Error: window: Control(page_prev) anchoring to an undefined control (page_info) in windowclass (reference_manual)
Ruleset Error: window: Control(page_prev) anchoring to an undefined control (page_info) in windowclass (reference_manual)
Ruleset Warning: window: Anchored static height ignored for control (page_next) in windowclass (reference_manual)
Ruleset Error: window: Control(page_next) anchoring to an undefined control (page_info) in windowclass (reference_manual)
Ruleset Error: window: Control(page_next) anchoring to an undefined control (page_info) in windowclass (reference_manual)
Ruleset Warning: window: Anchored static height ignored for control (page_prev) in windowclass (reference_manual)
Ruleset Error: window: Control(page_prev) anchoring to an undefined control (page_info) in windowclass (reference_manual)
Ruleset Error: window: Control(page_prev) anchoring to an undefined control (page_info) in windowclass (reference_manual)
Ruleset Warning: window: Anchored static height ignored for control (page_next) in windowclass (reference_manual)
Ruleset Error: window: Control(page_next) anchoring to an undefined control (page_info) in windowclass (reference_manual)
Ruleset Error: window: Control(page_next) anchoring to an undefined control (page_info) in windowclass (reference_manual)

[Moon Wizard]

Just pushed fix for reference manual layout errors.

Regards,
JPG

[MadNomadGM]

Ok, stupid question, but what is the "dev channel"?
Wondering how to get this stuff to test my extensions ahead of time. Are we talking discord channels? I see 3 different dev channels there, but those don't seem like the right place...

[Weltenbrand]

Is there a way to get on this mailing list.
I discovered this thread only by accident.

[damned]

Is there a way to get on this mailing list.
I discovered this thread only by accident.

At the top of each page under Thread Tools you can subscribe to a thread.
This thread is really aimed at devs who are owners of rulesets and need to make changes ready for an upcoming change to CoreRPG.


Ok, stupid question, but what is the "dev channel"?
Wondering how to get this stuff to test my extensions ahead of time. Are we talking discord channels? I see 3 different dev channels there, but those don't seem like the right place...

In your FG settings go to Advanced and you can change between Live, Test, Prev and Dev.
Very rarely should anyone be in Dev - only when instructed.
Test is a good place for ruleset and extension developers who want to test their stuff against upcoming releases - kinda like Dev but used all the time.
Prev is for when a new build screws you up and you dont have time to troubleshoot, again, generally not recommended to use.

[Weltenbrand]

I know how to subscribe to a thread, thank you.
My question is if there is a ruleset upgrade 2021-XX, how do I get notified.
I am a ruleset owner, therefore this is highly relevant for me.
Maybe the labratory should not the place to announce this? I develeop against the stable version, therefore I normally dont look in here.

[damned]

Most updates go into the test channel for 3-14days and then get moved to Live (typically on a Tues or Thurs).
So unless an update is buggy it will make its way into Live.

Dev is very occasionally used. I dont think there is any way to subscribe to new Dev threads automatically - just keeping an eye on the forums.

[Kelrugem]

You can also subscribe to the whole part of the laboratory, not just to threads :)

[damned]

You can also subscribe to the whole part of the laboratory, not just to threads :)

What? Where? How?

EDIT: Can too! Well done Kel.

[Kelrugem]

What? Where? How?

EDIT: Can too! Well done Kel.

Hehe, yeah, I looked once a little bit more into the settings of this subscription stuff after I had over 2400 unread emails due to the subscriptions in the FG forum :D

[Zacchaeus]

I like these (apart from the buttons - not a fan of word buttons but hey ho) including the ones not mentioned like the colour picker for the dice (invisible dice anyone?) and the DM speaker list. I'm also really liking the fact that any image can be set as the desktop decal and the message of the day.

But one thing I haven't been able to figure out is what is the Character desktop list that can now be moved?

[Kelrugem]

I like these (apart from the buttons - not a fan of word buttons but hey ho) including the ones not mentioned like the colour picker for the dice (invisible dice anyone?) and the DM speaker list. I'm also really liking the fact that any image can be set as the desktop decal and the message of the day.

But one thing I haven't been able to figure out is what is the Character desktop list that can now be moved?

Uuuh, the colour picker is nice :D The transparency is funny, thought the fading of rolled dice leads to that they are suddenly not transparent anymore while fading, looks a bit glitchy then :D

With the character desktop list Moon Wizard means the portraits of clients over the chat I believe :) The reset and unlock button also appear on the left while hovering over the portraits

EDIT: Some bug, the reset portrait position button next to the portraits has the tooltip of the "unlocked" button accidentally :)

[Zacchaeus]

Uuuh, the colour picker is nice :D The transparency is funny, thought the fading of rolled dice leads to that they are suddenly not transparent anymore while fading, looks a bit glitchy then :D

With the character desktop list Moon Wizard means the portraits of clients over the chat I believe :) The reset and unlock button also appear on the left while hovering over the portraits

EDIT: Some bug, the reset portrait position button next to the portraits has the tooltip of the "unlocked" button accidentally :)

Aha! The only bit of the interface that I hadn't looked at because I wasn't using a second instance with a player in it. You are correct as always young man :)

[SilentRuin]

I keep seeing ruleset this - ruleset that.

Doesn't this also effect extensions?

I suspect this will be a VERY interesting time when this goes live. Personally, I did a keyword search on some of these things and several lit up tons of code (isHost, actor calls, etc.). I assume the day this drops I'll have to set aside a few days for rewrites - unless they have dummy calls inserted to handle the deprecated use of these things.

[damned]

It certainly will affect some extensions. After Dev and the rulesets are fixed it will go into test which is when extension devs will definitely want to look at it.

[Moon Wizard]

My plan is to move all of these changes into the Test channel tonight; with the plan to release on Feb. 16.

Community ruleset and extension developers should start looking sooner than later, as this is a faster cycle than usual. I'm working to clear this set of changes out before any ruleset vision/lighting changes we may need to make.

Regards,
JPG

[SilentRuin]

My plan is to move all of these changes into the Test channel tonight; with the plan to release on Feb. 16.

Community ruleset and extension developers should start looking sooner than later, as this is a faster cycle than usual. I'm working to clear this set of changes out before any ruleset vision/lighting changes we may need to make.

Regards,
JPG

I assume that I can't make the changes and have them work with the current FGU version correct? And just to point out the obvious, as I track the forums pretty good and missed this because of the title not interesting me, you best be ready for a lot of false claims that it busted people. Because it will really be the extensions busting the game - not the update. And then... wowsers. Just be ready.

[Moon Wizard]

It's true for every release; and that's why the first thing when errors happen is that we tell people to turn off extensions.

Regards,
JPG

[SilentRuin]

It's true for every release; and that's why the first thing when errors happen is that we tell people to turn off extensions.

Regards,
JPG

Preaching to the choir. 100% agree. EXTENSION = RISK is my motto. Posting in a few discord chats as I know people don't track the forums that well. And this update will be different than normal releases which have never impacted me. I think this one will with some of the changes. But I'll find out tomorrow or the weekend when i try to figure out how to work on test version but still somehow flip back to the normal version for my Monday night game.

[lule]

Is Session a new API-class? Is it a replacement for User-class? Could you please post the functions and properties of Seesion?

Thank you.

Regards,

Lule

[deer_buster]

It's true for every release; and that's why the first thing when errors happen is that we tell people to turn off extensions.

Regards,
JPG

Just tossing an idea out here, but this would be an awesome time to think about extension self-validation vs a given ruleset version, and if it doesn't meet that validation criteria, it doesn't load and displays an error for the user. For a semantic versioning scheme (I assume this is the versioning scheme you are using?), you'd only require it if the major version number changed. Perhaps a warning if the minor version wasn't validated too, but that's only for backwards compatible changes anyway.

[SilentRuin]

Just tossing an idea out here, but this would be an awesome time to think about extension self-validation vs a given ruleset version, and if it doesn't meet that validation criteria, it doesn't load and displays an error for the user. For a semantic versioning scheme (I assume this is the versioning scheme you are using?), you'd only require it if the major version number changed. Perhaps a warning if the minor version wasn't validated too, but that's only for backwards compatible changes anyway.

You must be living under a rock the last month or so. The whole DMsG dumping extensions and SW coming up with FG Forge (extension delivery system) is already been beaten to death in the forums - now its just a waiting game. Rock removed, daylight exposed - don't blink! :)

[deer_buster]

You must be living under a rock the last month or so. The whole DMsG dumping extensions and SW coming up with FG Forge (extension delivery system) is already been beaten to death in the forums - now its just a waiting game. Rock removed, daylight exposed - don't blink! :)

No rock living, thanks for the concern. Having the Forge doesn't imply validation against ruleset changes...

[SilentRuin]

No rock living, thanks for the concern. Having the Forge doesn't imply validation against ruleset changes...

True - but that thread is more likely to be relevant on that concern - figured you just did not know it was out there. Plus validating against a ruleset is near impossible for anyone but the developer of the extension. To many variables - to much nuance and inter compatibility issues with other extensions. Just because an extension works with a ruleset does not mean they did not write it irresponsibility and have it stomp over lots of code and other extensions. Not something I can envision being done without quadrupling the size of their testing teams. And why should they be testing other peoples code anyway? That is a sure ticket to endless headaches. EXTENSIONS = RISK - you accept that - or should stay far far away from them. And no I'm not trying to give you a hard time - just my opinion on this matter. Don't mean to say you should not have your say on it.

[deer_buster]

True - but that thread is more likely to be relevant on that concern - figured you just did not know it was out there. Plus validating against a ruleset is near impossible for anyone but the developer of the extension. To many variables - to much nuance and inter compatibility issues with other extensions. Just because an extension works with a ruleset does not mean they did not write it irresponsibility and have it stomp over lots of code and other extensions. Not something I can envision being done without quadrupling the size of their testing teams. And why should they be testing other peoples code anyway? That is a sure ticket to endless headaches. EXTENSIONS = RISK - you accept that - or should stay far far away from them. And no I'm not trying to give you a hard time - just my opinion on this matter. Don't mean to say you should not have your say on it.

You didn't understand the concept then. The author of the extension would certify that they have checked the code against a specific major version, and when the client loads the extension, it would compare that ruleset's version against the certified version of the extension, and provide an error or warning depending upon whether it is a major or minor version violation. If it is an error, provide the option to skip loading that extension into memory at that point. At no point should any expectation be that FG, or any other program, would look at the code itself and try to validate it. As you said, too much variability.

[SilentRuin]

You didn't understand the concept then. The author of the extension would certify that they have checked the code against a specific major version, and when the client loads the extension, it would compare that ruleset's version against the certified version of the extension, and provide an error or warning depending upon whether it is a major or minor version violation. If it is an error, provide the option to skip loading that extension into memory at that point. At no point should any expectation be that FG, or any other program, would look at the code itself and try to validate it. As you said, too much variability.

Apologies, I now see what you meant - my bad. But asking me to update some flag every time an update pops up is likely not going to happen as they update one or thrice a week. And while I tend to be proactive on making sure my extensions are running - I know others are not. Having a bunch of false warnings come up is not something I'd look forward to. Extension problems usually get identified by users, because they are too complex and interwoven to be validated against a build unless a very simple extension with low impact on the code architecture.

[deer_buster]

Apologies, I now see what you meant - my bad. But asking me to update some flag every time an update pops up is likely not going to happen as they update one or thrice a week. And while I tend to be proactive on making sure my extensions are running - I know others are not. Having a bunch of false warnings come up is not something I'd look forward to. Extension problems usually get identified by users, because they are too complex and interwoven to be validated against a build unless a very simple extension with low impact on the code architecture.

Only time this would be "required" would be when a major version of the ruleset is released. Minor versions and patches would not require re-certification (see https://semver.org/ for what would qualify as a major, minor, and patch change...assuming every ruleset uses semantic versioning, which I would highly recommend changing to if it isn't).

[SilentRuin]

Only time this would be "required" would be when a major version of the ruleset is released. Minor versions and patches would not require re-certification (see https://semver.org/ for what would qualify as a major, minor, and patch change...assuming every ruleset uses semantic versioning, which I would highly recommend changing to if it isn't).

The only version I have is for my extension. And SW does not like anything more than Major.Minor - just FYI.

[deer_buster]

The only version I have is for my extension. And SW does not like anything more than Major.Minor - just FYI.

Hmm, looking at SFRPG ruleset version is 2.1.18 (major.minor.patch)...so it's being used at least in one or more rulesets. SEMVER is very clear and useful at showing any technical user who looks at it about the level of change, and if it isn't being used, it should be.

[SilentRuin]

Hmm, looking at SFRPG ruleset version is 2.1.18 (major.minor.patch)...so it's being used at least in one or more rulesets. SEMVER is very clear and useful at showing any technical user who looks at it about the level of change, and if it isn't being used, it should be.

Didn't say people didn't use the triple numbers - I did at first - until someone informed me that it was not looked at or caused an issue. Think it was Mad Nomad but not sure. Then I removed them all to 2 digit only in my extension.xml files.

[deer_buster]

Didn't say people didn't use the triple numbers - I did at first - until someone informed me that it was not looked at or caused an issue. Think it was Mad Nomad but not sure. Then I removed them all to 2 digit only in my extension.xml files.

To be fair, you said

And SW does not like anything more than Major.Minor - just FYI.

Looking at the FGU version....4.0.10 (https://www.fantasygrounds.com/forums/showthread.php?65769-FG-Unity-Release-v4-0-10) so I'm not sure that is a true statement.

Regardless, certification of an extension whenever a major ruleset release happens should be done by the extension author...my suggestion was merely for the client to provide some kind of notification and/or exclusionary feature for extensions that haven't been certified. If there isn't the mechanism in place to even allow that, then it seems to me, imho, that it should be there, especially since extensions being out of date cause many problems.

[Trenloe]

OK guys, you've derailed this important information thread enough. Please take this discussion to another thread so that people wanting to know about the upcoming ruleset changes can get info quickly without having to wade through a lot of unrelated posts. Thanks.

[Valarian]

In order to support ruleset developers, I have made a number of notes regarding changes that should be made to bring rulesets in-line with the changes to the others.

Are the changes likely to affect backward compatibility with FG Classic?

[Weltenbrand]

Is there a simple way to go back to icon sidebars?

[SilentRuin]

Are the changes likely to affect backward compatibility with FG Classic?

I'm pretty sure what I'm seeing in TEST will ABSOLUTELY prevent my stuff from working in Classic as it will likely not have these changes. Moon Wizard would have to address it specifically though. As I've told everyone who could listen in all my literature on my extensions that I only support them in FGU, it has not stopped people from claiming some do work in Classic. I've told them I will never say that as I never plan to support it, and that they better always save their working versions someplace safe as I can't guarantee they will continue to work there.

Barring Moon Wizard saying differently, I'm pretty sure the changes I've had to make in TEST server to prevent them from going BOOM with the ActorManager2 changes I described in my "Issues" thread related to this will make it incompatible with any previous version of FGU and for sure FGC. IMHO.

[This would mean if you wanted to support one extension for FGU and FGC you would have to add in specific IF logic to handle each case separately - as I only support unity I won't be doing this ]

[Kelrugem]

In that case the FGC code also changed, so, the relabelling also is going to happen there :) The ruleset code is mostly similar for both versions, you can see the exceptions in the code when there is for example an if-clause checking whether it is FGU, something like if UtilityManager.isClientFGU() then :)

[SilentRuin]

In that case the FGC code also changed, so, the relabelling also is going to happen there :) The ruleset code is mostly similar for both versions, you can see the exceptions in the code when there is for example an if-clause checking whether it is FGU, something like if UtilityManager.isClientFGU() then :)

Not sure what that has to do with Extensions no longer being compatible because they have to change - but sure - I suppose old FGC extensions will be fine (shocked if that is not true). But that's not what I'm talking about. If you don't change your FGU extension it will explode (if you use the changed functions in it). And if you do change it then it won't work in FGC unless you make it work. And for me as my extensions are only supported in Unity per what I've told people - that will mean keep your old extensions if they worked in FGC as I never supported that.

Application still working in FGC - and old extensions still working in FGC - has nothing to do with changes to make them work in this new version FGU - just FYI. Or so I understand it from having to actually make those changes for TEST already. Maybe Moon Wizard can clarify - that would be good.

[Kelrugem]

Not sure what that has to do with Extensions no longer being compatible because they have to change - but sure - I suppose old FGC extensions will be fine. But that's not what I'm talking about. If you don't change your FGU extension it will explode (if you use the changed functions in it). And if you do change it then it won't work in FGC unless you make it work. And for me as my extensions are only supported in Unity per what I've told people - that will mean keep your old extensions if they worked in FGC as I never supported that.

Application still working in FGC - and old extensions still working in FGC - has nothing to do with changes to make them work in FGU - just FYI. Or so I understand it from having to actually make those changes for TEST already. Maybe Moon Wizard can clarify - that would be good.

With that I wanted to say that the changes you were speaking about need to be done for things in FGC and FGU; so, of course one needs to update FGC extensions, too :) In your answer to Valarian you wrote "[...] as it will likely not have these changes", and I just answered to that, because that is not completely true, certain changes are also done in FGC :) Only purely FGU related things like the new asset window etc. (which changes in the next patch) are of course not for FGC, but that is also not part of the code accessible for us. Whether or not extensions etc. work in both, FGC and FGU, is still determined by the same things, roughly :) (For example my extensions work for both, I only needed a different code for the blood overlays etc. because image stuff is of course different in both version)

But I may have misinterpreted your answer to Valarian in that part, maybe you just meant your extension and not the overall patch of SmiteWorks. (I read the "it" as referring to FGC and its code changes)

[SilentRuin]

With that I wanted to say that the changes you were speaking about need to be done for things in FGC and FGU; so, of course one needs to update FGC extensions, too :) In your answer to Valarian you wrote "[...] as it will likely not have these changes", and I just answered to that, because that is not completely true, certain changes are also done in FGC :) Only purely FGU related things like the new asset window etc. (which changes in the next patch) are of course not for FGC, but that is also not part of the code accessible for us. Whether or not extensions etc. work in both, FGC and FGU, is still determined by the same things, roughly :) (For example my extensions work for both, I only needed a different code for the blood overlays etc. because image stuff is of course different in both version)

But I may have misinterpreted your answer to Valarian in that part, maybe you just meant your extension and not the overall patch of SmiteWorks. (I read the "it" as referring to FGC and its code changes)

Oh I misinterpreted your answer also I think. No, I'm pretty sure these particular changes were only for FGU - but I could be wrong in that. I find it hard to believe they would disrupt the old product is why. And both deliveries (updates) are separate code deliveries even though they do share some of the same code. Otherwise, they would disrupt the old product and all its extensions. Which I don't think is something they would do. I do know that this will disrupt extensions in FGU - but assumed FGC stuff would be fine. EXCEPT where the same extension code is used for both.

Again - speculation on my part about FGC remaining unaffected. Will have to get SW person to state clearly what is what on that subject.

[Valyar]

After I spent some time on the DEV branch, I think that the move to completely disable the icon-based sidebar is wrong. VtM 5e, Symbaroum, Savage Worlds don't feel the same during play and prep. Call of Cthulhu has custom theme that also will be severely impacted.

I appeal to at least reconsider and allow for ruleset authors and maintainers to have a "switch" to use one or the other.

[superteddy57]

Oh I misinterpreted your answer also I think. No, I'm pretty sure these particular changes were only for FGU - but I could be wrong in that. I find it hard to believe they would disrupt the old product is why. And both deliveries (updates) are separate code deliveries even though they do share some of the same code. Otherwise, they would disrupt the old product and all its extensions. Which I don't think is something they would do. I do know that this will disrupt extensions in FGU - but assumed FGC stuff would be fine. EXCEPT where the same extension code is used for both.

Again - speculation on my part about FGC remaining unaffected. Will have to get SW person to state clearly what is what on that subject.

As this has to do with ruleset code and not the engine itself, both FGC and FGU extensions would have to be looked at for compatibility with the new code being introduced. The Desktop and Actor Manager code is shared between the two versions of FG.

[SilentRuin]

As this has to do with ruleset code and not the engine itself, both FGC and FGU extensions would have to be looked at for compatibility with the new code being introduced. The Desktop and Actor Manager code is shared between the two versions of FG.

Then based on what I've seen in FGU Test Server - anything using ActorManger2 calls will go BOOM until fixed.

[superteddy57]

Then based on what I've seen in FGU Test Server - anything using ActorManger2 calls will go BOOM until fixed.

Correct as the base ruleset code changed it to something else. The version of FG being used doesn't detract from that as both use the changes being implemented.

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

@Valyar,
As I mentioned in my e-mail, there are no plans to support a bifurcated graphical/non-graphical menu system; and this change was one that was heavily debated. Also, as mentioned, with the advent of these changes, this cuts down drastically on graphics needed to implement rulesets, themes and new record types. The latter is more important than the former. It can already be seen that almost half our rulesets were already moved or moving to textual button labels for these exact reasons. This isn't something that's going to be changed through debate; because it impacts efficiency, maintainability, and time-to-market for DLC and themes.

Regards,
JPG

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

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

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

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

[Trenloe]

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?

[SilentRuin]

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.

[celestian]

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.

[SilentRuin]

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

[deer_buster]

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.

[deer_buster]

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

[deer_buster]

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

[Moon Wizard]

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

Thanks,
JPG

[celestian]

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="&gt;=4") makes me cry a little also.

[MeAndUnique]

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.


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 (https://github.com/MeAndUnique/Breakdown/blob/main/manager_action_damage.lua).

[SilentRuin]

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 (https://github.com/MeAndUnique/Breakdown/blob/main/manager_action_damage.lua).

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 :(

[MeAndUnique]

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.

[SilentRuin]

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?

[MeAndUnique]

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:


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

[SilentRuin]

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:


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.

[Arghun]

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?

[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?

[Jiminimonka]

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 (https://github.com/MeAndUnique/Breakdown/blob/main/manager_action_damage.lua).

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.

[Kelrugem]

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

[MeAndUnique]

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.

[MeAndUnique]

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.

[Kelrugem]

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/forums/showthread.php?65561-Developer-Notes-2021-02-Ruleset-Updates&p=576820&viewfull=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).

[Moon Wizard]

@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

[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

[bmos]

each of the sidebar "state" buttons can be dragged onto hot key bar for easier activationI 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).

[Arghun]

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

[EllivasKram]

Are these being released today ?

[Moon Wizard]

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

[Varsuuk]

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

[AngelM]

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