Closed james7132 closed 2 years ago
Related to #1515.
Closing this as there are workarounds that don't require archetypal Clone-safety. For rollback netcode, generic systems seem to work fine given a guaranteed Clone bound on the components or resources.
What problem does this solve or what need does it fill?
To allow easier duplication of entities (spawning copies of a template) and copying of entire Worlds for subapps/worlds and rollback networking, having a dedicated storage for clone-able components is likely required.
What solution would you like?
Either an API that conditionally allows cloning a Table or SparseSet (iff all contained components are Clone), or a separate storage format that keeps only the Clone-able components of entities that are implement Clone and Send, and supports trivially moving/cloning/replacing this storage from World to World while maintaining entity identity.
What alternative(s) have you considered?
Manually copying individual components from World to World. May cause entity identity instability.
Additional context
The main need for something like this is to allow for creating World snapshots at a given moment in time for rollback networking, and support restoring it at a later time.
For this to be correct, entity IDs must be stable across saving and loading these snapshots, or any entity references in components recorded in each snapshot may become invalid.