61bd3af7c7
# Objective This is the first step of #19430 and is a follow up for #19132. Now that `ArchetypeRow` has a niche, we can use `Option` instead of needing `INVALID` everywhere. This was especially concerning since `INVALID` *really was valid!* Using options here made the code clearer and more data-driven. ## Solution Replace all uses of `INVALID` entity locations (and archetype/table rows) with `None`. ## Testing CI --------- Co-authored-by: Chris Russell <8494645+chescock@users.noreply.github.com> Co-authored-by: François Mockers <francois.mockers@vleue.com> Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
18 lines
928 B
Markdown
18 lines
928 B
Markdown
---
|
|
title: Entities APIs
|
|
pull_requests: [19350, 19433]
|
|
---
|
|
|
|
`Entities::flush` now also asks for metadata about the flush operation
|
|
that will be stored for the flushed entities. For the source location,
|
|
`MaybeLocation::caller()` can be used; the tick should be retrieved
|
|
from the world.
|
|
|
|
Additionally, flush now gives `&mut EntityIdLocation` instead of `&mut EntityLocation` access.
|
|
`EntityIdLocation` is an alias for `Option<EntityLocation>`.
|
|
This replaces invalid locations with `None`.
|
|
It is possible for an `Entity` id to be allocated/reserved but not yet have a location.
|
|
This is used in commands for example, and this reality is more transparent with an `Option`.
|
|
This extends to other interfaces: `Entities::free` now returns `Option<EntityIdLocation>` instead of `Option<EntityLocation>`.
|
|
`Entities::get` remains unchanged, but you can access an `Entity`'s `EntityIdLocation` through the new `Entities::get_id_location`.
|