Deprecate get_or_spawn

[Trashtalk217]

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_spawn is no longer necessary for that function. Entity should be opaque as the warning above get_or_spawn says. This is also part of #15459.

I'm deprecating get_or_spawn_batch in a different PR in order to keep the PR small in size.

Solution

Deprecate get_or_spawn and replace it with get_entity in most contexts. If it's possible to query &RenderEntity, then the entity is synced and render_entity.id() is initialized in the render world.

Migration Guide

If you are given an Entity and you want to do something with it, use Commands.entity(...) or World.entity(...). If instead you want to spawn something use Commands.spawn(...) or World.spawn(...). If you are not sure if an entity exists, you can always use get_entity and match on the Option<...> that is returned.

[MrGVSV]

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 get_or_spawn. Or do they typically just use a map to correlate entities (e.g. EntityMapper)?

[alice-i-cecile]

Or do they typically just use a map to correlate entities (e.g. EntityMapper)?

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]

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.

[Trashtalk217]

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.

[Shatur]

Or do they typically just use a map to correlate entities (e.g. EntityMapper)

That's what we do in bevy_replicon, so we won't be affected.

[bushrat011899]

Or do they typically just use a map to correlate entities (e.g. EntityMapper)

That's what we do in bevy_replicon, so we won't be affected.

Can also confirm that's how bevy_ggrs works!