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
The backing pointer for an ObjectLink can be made to deviate from the actual Object during later runtime; the Entity will then still be in the same archetype (which is either in one or two ways not what the user would expect).
How to Fix
Object Links need to be either Devoid (and have objects in a separate storage), or need to be treated per-archetype or cross-archetype in a 1-slot storage type.
The component type then needs to be migrated to reflect the new hash code.
Alternative: Disallow reseating Object refs in runners or otherwise. This can be done through postprocessing and raising an error most easily, but it would be preferable if the shared object wasn't provided as a ref in the first place. This, however, likely adds unnecessary complexity to the runner declarations.
The text was updated successfully, but these errors were encountered:
What
The backing pointer for an ObjectLink can be made to deviate from the actual Object during later runtime; the Entity will then still be in the same archetype (which is either in one or two ways not what the user would expect).
How to Fix
Object Links need to be either Devoid (and have objects in a separate storage), or need to be treated per-archetype or cross-archetype in a 1-slot storage type.
The component type then needs to be migrated to reflect the new hash code.
Alternative: Disallow reseating Object refs in runners or otherwise. This can be done through postprocessing and raising an error most easily, but it would be preferable if the shared object wasn't provided as a ref in the first place. This, however, likely adds unnecessary complexity to the runner declarations.
The text was updated successfully, but these errors were encountered: