Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modules with new system restrictions cannot be deactivated in worlds for other systems that previously had them active #5458

Closed
aaclayton opened this issue Jun 18, 2021 · 5 comments
Assignees
Labels
bug Functionality which is not working as intended nonrepro Bugs which are not yet able to be reproduced. packages Issues related to add-on packages, systems, modules, and worlds
Milestone

Comments

@aaclayton
Copy link
Contributor

Originally in GitLab by @joseph.spandrusyszyn

In order to submit an effective bug report, please include the following information along with your issue description.

Environment Details

  • Foundry VTT Version: 0.8.7
  • Operating System: Ubuntu
  • How Are You Using Foundry: Native Application (Electron)
  • Which Game System: pf2e
  • Modules Enabled?: Noticed with illandril-sheet5e-lockdown, but can reproduce with a single barebones module

Issue Description

If you activate a module that doesn't have a system restriction in a world, and then later that module gets a system restriction, you cannot deactivate that module.

  1. Create a module that doesn't have a "system" restriction in the module.json, with a single script that just has a console.error('Module active'); line in it
  2. Activate it for a Pathfinder 2 world
  3. Update the module's module.json to include a "system": "dnd5e" entry
  4. Restart the Pathfinder 2 world
  5. See that there is still 1 Active Module, and the Module active error still appears in the console.
  6. Open Manage Modules, and see that no the module is not included in the list anywhere, and there is no way to deactivate it.
@aaclayton
Copy link
Contributor Author

Changes to a manifest file system.json, module.json, or world.json generally require Foundry VTT to be restarted in order for them to be acknowledged by the software. Do you confirm this behavior if Foundry VTT is restarted after the module.json file is edited?

@aaclayton
Copy link
Contributor Author

Originally in GitLab by @joseph.spandrusyszyn

Yes, this behavior is the same regardless of if Foundry VTT is restarted or not after changing module.json

@aaclayton
Copy link
Contributor Author

Originally in GitLab by @anathemamask

Confirmed- though I feel this would only occur in cases where someone is trying to accomplish this exact thing. I struggle to imagine a situation where this would occur in normal usage.

@aaclayton
Copy link
Contributor Author

Originally in GitLab by @joseph.spandrusyszyn

Here's how it can happen under normal usage:
I initially released illandril-sheet5e-lockdown without a hard restriction on system. Several people have activated it on non-5e worlds and then told me it didn't work, despite the module clearly saying it was for 5e. I've since added the restriction, so anyone who did this now cannot deactivate the module for those worlds if they hadn't already deactivated it before.

This could easily happen with any number of other modules. In my experience, Foundry users seem to love turning on every module they can find that has even the slightest hint of helping them, and fail to turn off the ones they don't actually use until and unless it starts causing a problem.

@aaclayton
Copy link
Contributor Author

Originally in GitLab by @Fyorl

It's possible that this has already been fixed, I was not able to reproduce it on our current v8 dev branch.

@Fyorl Fyorl self-assigned this Jun 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Functionality which is not working as intended nonrepro Bugs which are not yet able to be reproduced. packages Issues related to add-on packages, systems, modules, and worlds
Projects
No open projects
Status: No status
Development

No branches or pull requests

2 participants