You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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.
The text was updated successfully, but these errors were encountered:
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?
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.
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
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.
The text was updated successfully, but these errors were encountered: