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

Mark system documents with system name and version #6553

Closed
aaclayton opened this issue Jan 17, 2022 · 5 comments
Closed

Mark system documents with system name and version #6553

aaclayton opened this issue Jan 17, 2022 · 5 comments
Assignees
Labels
api Issues related to the API used by Mod Devs

Comments

@aaclayton
Copy link
Contributor

Originally in GitLab by @Spice_King

Feature Summary

Add markers of game system of origin to all relevant Documents with system owned schema (Items, Actors, Tokens, Active Effects). Modules tend to bleed stuff by mistake and can cause issues when documents load into the wrong system, or cause debugging nightmares.

Dev Experience

I'm advocating for a system property to be added to the top level of relevant documents. This property should be read only from the client side, and should be set to the current system name on the server's side when created. If more detail is desired, the property could be expanded to be a mostly read only object, with name of the system, the version of the system it was created with, and spot for system's data model migration version (which would be read/write, meaning left to the system).

Example system object

{
  "name": "dnd5e",
  "created_in": "1.2.4",
  "migrated_to": "1.5.7"
}

If you place restrictions on the migration version so that it can only be bumped to the current system version, then Foundry can warn that a Document was loaded from a newer version of the system in a install with an older version, providing a chance avoid some support issues for system devs and alerting users to issues before the Document is put to use.

Priority/Importance

¯\_(ツ)_/¯

People forget that DnD5E is not the only system in town when making content modules, and thus may cause issues when incorrectly marked in the manifest for generic system compatibility due to pulling in Documents a system owns.

Some systems do have their own markers for migrations, and thus might not feel the need for that, but a universal way is probably better for all.

@aaclayton
Copy link
Contributor Author

Originally in GitLab by @Fyorl

It would probably be easy enough to tag a Document with the package name of the system it was created in. We currently add some additional data on export though and I wonder if it's not sufficient to do it there? How might a user load a Document created in one system into a different system except via export?

@aaclayton
Copy link
Contributor Author

Originally in GitLab by @ghost91-

Compendium packs from modules.

@aaclayton
Copy link
Contributor Author

Originally in GitLab by @Fyorl

But modules already have a mechanism to specify the systems they're compatible with, no?

Edit: I see that @Spice_King already articulated the exact issue in the penultimate paragraph which I guess I'd skipped over.

@aaclayton
Copy link
Contributor Author

Originally in GitLab by @Spice_King

Yea, this stemmed from FloRad trying to debug a user's issue in SWADE that was ultimately caused by a content pack (which was not marked for system compatibility) with scenes that had tokens/actors with DnD 5e data and types, not SWADE's data and types.

People largely expect scenes to be system agnostic, so even if marked with the system it has data from, people would ignore that, because it's just scenes. Even I would ignore any warning thrown in my face to load a content module that was just scenes.

Atropos thought the base line idea of hard marking system owned documents with the system it came from was good enough to be written up. Adding system versions to help with debugging old documents or warn about a document from a newer system version was just the natural extension of that.

@aaclayton
Copy link
Contributor Author

Originally in GitLab by @Fyorl

marked this issue as related to #3653

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api Issues related to the API used by Mod Devs
Projects
No open projects
Status: No status
Development

No branches or pull requests

2 participants