Module share state not being maintained between sessions

[Mike Serfass]

[MODERATOR: copied from a thread in the Laboratory forum - as this issue has been a long-term problem for the OP, it's not limited to the current test version]

Modules don't maintain permissions between game loads.

When the GM sets a module to be allowed to players, the next time the session loads, those permissions are set back to "disallow'.
So the GM must reset those permissions EVERY GAME and the players must reload the modules EVERY GAME.

This has always been a problem, but I had code to work around this bug.
The current changes now make this impossible to work around.

This happens in all rulesets and happens only with some modules.
The GM loading the module seems to affect this default setting.

[Zacchaeus]

Modules don't maintain permissions between game loads.

When the GM sets a module to be allowed to players, the next time the session loads, those permissions are set back to "disallow'.
So the GM must reset those permissions EVERY GAME and the players must reload the modules EVERY GAME.

This has always been a problem, but I had code to work around this bug.
The current changes now make this impossible to work around.

This happens in all rulesets and happens only with some modules.
The GM loading the module seems to affect this default setting.

Can you specify which modules and for which ruleset(s). I've never seen this issue.

It sounds like something is changing the modulestate.xml file inside the campaign folder.

[Trenloe]

Modules don't maintain permissions between game loads.

When the GM sets a module to be allowed to players, the next time the session loads, those permissions are set back to "disallow'.
So the GM must reset those permissions EVERY GAME and the players must reload the modules EVERY GAME.

This has always been a problem, but I had code to work around this bug.
I, also, have never had an issue with this. The per campaign settings are stored in each campaign directory in a "modulestate.xml" file. If your settings aren't being maintained between games then that file isn't being written when FG exits (file permissions?), something is overwriting it or you're using an extension that may be changing the standard behavior.

[Mike Serfass]

There are no extensions loaded, not even a theme.
This has happened to me the entire time I've used FGU.
It happens in every ruleset I tried and in every campaign.
modulestate.xml is written to after I toggle the player load, and the <disallow /> flag is removed. However, when the game loads, it ignores those tags and sets them to disallow.

I included a screenshot from the D&D 5E tutorial campaign. 66275
I can reproduce this consistently, and I can make a video if that helps.

[Zacchaeus]

Do you have any unpacked rulesets in your rulesets folder? If there are any folders inside the rulesets folder delete those and see if that helps. It might also not be a bad idea to delete the CoreRPG.pak file and then do an update.

[Mike Serfass]

Thanks, but I already did that.
Others are experiencing this now in test.

[Moon Wizard]

I've never seen this issue either. All module states that vary from the defaults (loaded; allowed for GM modules; disallowed for player modules) are stored in the modulestate.xml file.

The only reason I can think that this would fail is if the modulestate.xml is not able to be written by FG when it closes; or it is replaced between sessions by a synch application.

You should be able to test in a brand new campaign by loading a single module; exiting; checking the modulestate.xml to make sure it's correct; and then reloading the campaign to verify.

Regards,
JPG

[Mike Serfass]

I verified that modulestate.xml is being written to correctly. It seems to not read modulestate.xml.
I have no apps that synch the FGU folders.
I have no extensions loaded, not even themes.

The sequence of events seems to be:
1) FGU opens, sets module states to values it determines rather than what modulestate.xml stores (fails to read modulestate.xml)
2) User sets module states manually
3) FGU closes, writes correct module states to modulestate.xml
4) Repeat step 1...

I've gone through the steps of creating a new campaign. I did that with three different rulesets and loaded one module to test.
I've gone through the CoreRPG code and didn't find I/O functions for modulestate.xml, so it's in the app.
This is a consistent bug which I can easily recreate.

Edit: I have exceptions for the FG folders and FantasyGrounds.exe in my anti-virus software.

[Moon Wizard]

Have no idea; since I haven't seen anything like this. As @Zacchaeus and @Trenloe mentioned; they're not seeing this issue either.

* Is anything being reported in the console.log file on startup or exit that might indicate anything?
* Is there a possibility that it's related to the ruleset you are running? Can you try in 5E ruleset?
* There is some Test channel specific auto-load code that was added; but the ruleset has to first register auto-load rules, and then those results are stored in modulestate and CampaignRegistry. (Only D&D and PF/SF have those rules.) Also, you said this happens in Live as well.

Regards,
JPG

[Mike Serfass]

It's an odd one.

1) Unfortunately, no. I even added numerous debug statements. Nothing reported the state being set.

2) As stated earlier, this happens with every ruleset.

3) This has been happening for a long time, well before the latest updates. I reported it some time ago and it went nowhere. Probably because nobody else sees it.
This has gotten much worse with the latest updates. I think something about the auto-load stirred it up.

I'll keep poking at it and report anything I find. Thanks all.

[Trenloe]

So that we can try to recreate - can you give an example of one module that is normally not allowed in the FG interface, the GM changes to allowed (<allowed /> should be written to the modulestate.xml file when FG exits), but when the next session starts it is showing not allowed in the FG interface? This will help us to try to recreate the issue.

Also, you mentioned earlier that you could create a video - would that be possible?

This is so we can be all on exactly the same page.

[Mike Serfass]

Yes, the one in my screenshot.
5E SRD 5.1.0 Player Data (Legacy)
This is in the 5e tutorial campaign.

Also, in all of my Savage Worlds campaigns:
Savage Worlds Adventure Edition (SWADE) - Player
Fantasy Companion Action Deck
SWADE Adventure Deck
Science Fiction Companion (SWADE)

[Mike Serfass]

Interestingly, if I set the modules to auto-load, they load for the players.

[Moon Wizard]

Found a situation where the share state could be lost if module was loaded by GM (depended on default share state, etc.). Can you run a new Check for Updates, and see if it's still happening?

Regards,
JPG

[Stryfe484]

All of my Pathfinder for Savage Worlds modules have gone to GM only except the Companion and the Inner Sea World Map. This is the first time I've experienced this issue. I was able to set the needed modules to Auto Load, which seems to have nullified the issue for now.

[Mike Serfass]

Thank you Moon Wizard! That fixed it for me.
This bug been a thorn in my side for a very long time. It's great to see the corpse of this thorn bug squashed under your boot.

[Moon Wizard]

@Stryfe484,

The sharing state for players may have been lost if you opened the campaign with FG between Tues afternoon and late last night for any modules you had loaded as a GM. That should be fixed as of the version I pushed last night; but you'll need to re-specify the player share state for those modules again.

Regards,
JPG

[tahl_liadon]

.

i think this is the right thread for this issue...

after fgu update to 5.1.0

module activation state (activated or not) and access permission (gm only or players) settings were reset to not activated and gm only at each start-up.

i tried resetting and deleted modulestate.xml file. this worked as usual: it kept my last settings for all modules, except all the core orc modules -- with repeated tries, these continued to revert back to not activated and gm only.

[Moon Wizard]

Can you try a new campaign, and give me the exact steps you are following where you see it not working as you expect?
I'm not sure I'm following what the issue is, so specific steps will help alleviate any confusion.

Regards,
JPG

[Navigat0r]

Just going to add my voice here. I have also experienced this issue with modules deactivating occasionally over the years in a number of systems on FGU as both player and GM. It happened again today in my fallout game (which had no extensions or themes active). As a player the quick start module was deactivated and I could no longer reactivate it. It had to be re-enabled by our GM which is a bit odd as to my knowledge the quickstart rules should be set to "player loadable" by default.

[Zacchaeus]

Just going to add my voice here. I have also experienced this issue with modules deactivating occasionally over the years in a number of systems on FGU as both player and GM. It happened again today in my fallout game (which had no extensions or themes active). As a player the quick start module was deactivated and I could no longer reactivate it. It had to be re-enabled by our GM which is a bit odd as to my knowledge the quickstart rules should be set to "player loadable" by default.

This issue should now be fixed as noted above. If, before the fix, the campaign was opened then in some cases modules which were shared and also where the DM had that module open the status of the module could revert to not shared. The solution, as you have discovered, is for the DM to make the module shareable again or to enable force loading.

[Navigat0r]

This issue should now be fixed as noted above. If, before the fix, the campaign was opened then in some cases modules which were shared and also where the DM had that module open the status of the module could revert to not shared. The solution, as you have discovered, is for the DM to make the module shareable again or to enable force loading.

The issue happened a few hours ago in a campaign with no extensions or themes with everyone having updated immediately before the game. As I made the post as the issue was happening, I suspect that unless some new update has happened in the few hours since I made my post there is still something going on.

The solution may be relatively straightforward for experienced FG users (just have players reload/have GM re-share) but this isn't something that should be happening at all. It has caused me (and likely other GMs as well) quite a few issues in the past with new users who are less savvy with the program

[Zacchaeus]

The issue happened a few hours ago in a campaign with no extensions or themes with everyone having updated immediately before the game. As I made the post as the issue was happening, I suspect that unless some new update has happened in the few hours since I made my post there is still something going on.

The solution may be relatively straightforward for experienced FG users (just have players reload/have GM re-share) but this isn't something that should be happening at all. It has caused me (and likely other GMs as well) quite a few issues in the past with new users who are less savvy with the program

It should be easier with new users now since the DM has the option to set modules to automatically open for players; thus players don't need to use module activation and load modules. When they join they'll have all of the information to create characters etc readily available.

It's only in the last few days that anyone has reported an issue with books which were previously shared reverting to not shared (the first post in this thread being the first time anyone has reported it); this wasn't a known issue at all until then. The update probably exacerbated the issue for some users, but it doesn't appear that the update was the root of the problem it was something else which lay dormant for some time. The issue has now been fixed, but for probably a very small number of users the DM may have to refresh the sharing or set the module to autoload.

[tahl_liadon]

.

Can you try a new campaign, and give me the exact steps you are following where you see it not working as you expect?


1) started a virgin testing campaign, no extensions or any theme. results shown in pics below:



"orc" modules settings in virgin campaign:

https://www.fantasygrounds.com/forums/attachment.php?attachmentid=66392


"orc" (and only "orc") modules reverted to these settings after shutdown and reopened same campaign --
consistent behavior with other existing campaigns as i explained in my previous message:

https://www.fantasygrounds.com/forums/attachment.php?attachmentid=66393


2) in last live session (01/24, 20:00 gmt -7) with players, i turned sharing back on for players. all player clients crashed when attempted to reactivate "orc" modules.

[Moon Wizard]

Thanks for the additional information; I'm going to investigate specifically with ORC modules since it appears to be fine with the paid Core modules.

Regards,
JPG

[Moon Wizard]

Just pushed an update that should prevent the free modules from unloading on subsequent sessions. I wasn't able to reproduce the crash at this time.

Can you run a new Check for Updates and try again?

Thanks,
JPG

[tahl_liadon]

.


Can you run a new Check for Updates and try again?

your update seemed to have fixed it; it's retaining preferences after reboot for testing as well as existing campaigns. thx much!



I wasn't able to reproduce the crash at this time.

we will have to see if it repeats on the next session lol