PDA

View Full Version : Guidance on module sharing in Fantasy Grounds Unity when a player owns modules that t



FlyboySapp
May 3rd, 2026, 15:07
I’m looking for some guidance on module sharing in Fantasy Grounds Unity when a player owns modules that the GM does not.

I’m currently a player in a friend’s campaign and have purchased several modules that my GM doesn’t own. The issue we’re encountering is that, at the start of every session, he has to reload and re-approve those modules, even though they were previously set to auto-load.

We’re aware of the past modulestate issue and attempted the commonly suggested fix of deleting the modulestate.xml file and reloading everything. Unfortunately, the problem persists. Notably, this only affects modules that I own. Modules owned by the GM load and persist normally.

When it didn't load when I could still load my local modules as player. I just loaded the ones I was needing while everyone else was joining and/or during previous sessions recap at the beginning. Our current work around has been to just to have the GM re-approve / reloaded at the beginning of every session since for the last few months as we tried figuring out what could be causing it and that this point we are both kind of stumped.

From the GM’s side, after closing Fantasy Grounds, he said the affected modules appear to be removed from the modulestate.xml file when I exit the game. When the next session starts, they are missing again, and the process has to be repeated.

Has anyone encountered this behavior or found a reliable fix? Are we possibly missing a setting or step?

Moon Wizard
May 3rd, 2026, 17:32
It's a limitation of the client; because the it is only aware of the GM owned data for persistence between sessions. It's been that way for many years, as far as I'm aware.

I think that the past modulestate suggestion was an incorrect diagnosis, based on misunderstanding the issue.

This would actually be a feature request to change the client to be somehow track that data between sessions, but also be aware of how that impacts the system overall for module management, networking, etc.

Regards,
JPG

Speculi
May 4th, 2026, 10:02
Coming at this from a naive point of view: Why can't the GM machine store a list of products/modules it allowed others to load and check that when a new client joins? Even if it doesn't really know what the module is, it has some kind of identifier, which could be remembered.
Maybe I'm thinking to simple here.

RESmeCUE
May 4th, 2026, 16:19
Probably due to $$$$$$$.

That would allow you to purchase an adventure, and I log into your campaign and download a copy of it, now I use it and haven't paid for it.

Follow the money.....

LordEntrails
May 4th, 2026, 16:47
Coming at this from a naive point of view: Why can't the GM machine store a list of products/modules it allowed others to load and check that when a new client joins? Even if it doesn't really know what the module is, it has some kind of identifier, which could be remembered.
Maybe I'm thinking to simple here.
It could, but FG is not currently architected to do this. It would require SmiteWorks change how the modulestate.xml is handled. It can be done, it just hasn't been prioritized yet. Hence why it could be listed on the Feature Request page to drive prioritization.

Speculi
May 4th, 2026, 20:06
It could, but FG is not currently architected to do this. It would require SmiteWorks change how the modulestate.xml is handled. It can be done, it just hasn't been prioritized yet. Hence why it could be listed on the Feature Request page to drive prioritization.

Sure, it will need some changes, but my point was more towards Moon Wizards reply, which made it sound like it would need big/fundamental changes, while to me it sounds like it should be "just" storing the allowed modules identifiers and some code to load it and check against the list when a client connects. There must already be code in place to transfer which player modules a connected client hast available. Also maybe it would also need a new button to reset the client allowed list, because no module meta data would be available while the other client is not connected.

But as a developer myself, I also know that sometimes the stuff that sounds easy is actually more work than expected. Hence the naive point of view...

LordEntrails
May 4th, 2026, 22:02
I've always assumed the modulestate file gets written when the host exits, and it's written with the current state. Which is no players connected so the state of the shared players modules is unknown. So I assume they would have to change that behavior so it stored the shared state for each user as of the last time they were connected.

But I'm with you, a similar naive point of view :)