moduledb Files Deleted On Close

[Mike Serfass]

The xml files created in the moduledb folder are being deleted when the application closes.
This bug is easy to recreate.

1) open the skills list
2) add a new group "test"
3) move some skills into it
4) save the campaign
5) see the xml file created in modeuldb (named after the module or ruleset the skill is defined in)
5) exit FGU
6) notice the file disappears
7) open and close FGU a second time if the first restart didn't delete the file; it will the second time

This also happens if you open an editable record from a module or ruleset (NPC, vehicle, any of them) and edit it.
This is very recent. I noticed it yesterday and it was reported here:Sidebar Problem (https://www.fantasygrounds.com/forums/showthread.php?86180-Sidebar-problem-question&p=753768&viewfull=1#post753768).

I noticed this yesterday in Savage Worlds. I was also able to produce this bug in D&D 5E.

[Moon Wizard]

That's correct.
The SWADE rules are exported as a Read Only module; so any changes would be ignored on reload. (i.e. changing skill category is a database change)
The CoreRPG ruleset does not currently block this behavior during play, so it allows the change initially; but resets on reload.

Regards,
JPG

[Mike Serfass]

It didn't think it delete these files previously. However...
Not long ago, various modules were changed to read only. If deleting the moduledb files was how it always worked, then it only appears to have changed when modules were changing to read only, wiping out changes that had been saved before the change.

There is an issue:

My Sci-Fi Companion extension adds new fields to vehicles and adjusts values that it needs for the new rules in the companion.
It updates those vehicles and saves a file to moduledb.
If those files are deleted, the extension has to repeat that work every time a record is opened in subsequent sessions.
While that's ponderous enough, this is worse with ruleset version updates.

The ruleset VersionManager updates modules when opened / loaded. Some of these updates are large, especially for old modules. Since this happens on session load, that makes for slow startups if it has to repeat that work every startup.

Is there some way this can be circumvented in this case? This is likely a can of worms.

There's also the problem of user changes. One example being the post I linked at top.
Modules aren't flagged as being read only. This confuses players as to what they can and can't edit. Deducing that a module is locked by looking at a single record isn't intuitive and users have to be walked through doing that.
Could some kind of indication be added to modules / books to make it clear that they can't be edited? And to records?
I can do that at the ruleset level, but I think this would benefit all rulesets.
That would help the confusion and shouldn't involve worms.

[jharp]

That's correct.
The SWADE rules are exported as a Read Only module; so any changes would be ignored on reload. (i.e. changing skill category is a database change)
The CoreRPG ruleset does not currently block this behavior during play, so it allows the change initially; but resets on reload.

Regards,
JPG

Im missing something here. What is the value in preventing editing?

Jason

[Griogre]

It means the developer knows that the user can't delete something and think it's missing. It avoids the problem with someone editing something and then reverting the module and unwittingly destroying the changes too. It's not necessary bad for the user since they can normally make a copy of the read only item and edit it - that way they have two copies - theirs and the original.

[Lonewolf]

That's correct.
The SWADE rules are exported as a Read Only module; so any changes would be ignored on reload. (i.e. changing skill category is a database change)
The CoreRPG ruleset does not currently block this behavior during play, so it allows the change initially; but resets on reload.

Regards,
JPG


There is still the problem of community developers that break the rules. The policy of locking everything except adventures is not being followed. Creators simply refuse to follow the current policy to lock eveything except adventures. So we end up with setting books that have user edits becuase they do not understand what is going on. Since they don't bother to make new records. Note that simply opening a record flags it as a user edit. The only way to fix that is put it in the policy you want followed in the QA process. Unless of course you changed your mind and there is no longer any rules on locking records.

[Mike Serfass]

There's also the issue of a user updating a record, then the record gets updated in the module, but that update doesn't apply to the edited record.
Not a big deal when the update is a type, but it is a big deal when something important changes. Like spell automation or links.