Deprecate get_or_spawn#15652
Conversation
|
I have no clue how networking code works, so ignore this comment if it's completely irrelevant. Does removing this affect networking crates at all? My assumption would be that they might desire to pass entities over the wire and sync them one-to-one using something like |
This is the recommended pattern. Per @maniwani, since we don't have entity ID range reservation, relying on specific entity IDs is very fragile and ill-advised, because things like UI spawning will generating new entity IDs and clash with the networked entities. |
NiseVoid
left a comment
There was a problem hiding this comment.
Changes look fine to me, a bit odd that the transform hierarchy and prepare_cluster ones don't have expect and all the other ones do, but not really blocking imo.
Those, I believe, don't use any of the sync machinery so I don't know what I would write in the expect clause. |
That's what we do in bevy_replicon, so we won't be affected. |
Can also confirm that's how |
Objective
After merging retained rendering world #15320, we now have a good way of creating a link between worlds (HIYAA intensifies). This means that
get_or_spawnis no longer necessary for that function. Entity should be opaque as the warning aboveget_or_spawnsays. This is also part of #15459.I'm deprecating
get_or_spawn_batchin a different PR in order to keep the PR small in size.Solution
Deprecate
get_or_spawnand replace it withget_entityin most contexts. If it's possible to query&RenderEntity, then the entity is synced andrender_entity.id()is initialized in the render world.Migration Guide
If you are given an
Entityand you want to do something with it, useCommands.entity(...)orWorld.entity(...). If instead you want to spawn something useCommands.spawn(...)orWorld.spawn(...). If you are not sure if an entity exists, you can always useget_entityand match on theOption<...>that is returned.