[Merged by Bors] - bevy_scene: Stabilize entity order in DynamicSceneBuilder#6382
[Merged by Bors] - bevy_scene: Stabilize entity order in DynamicSceneBuilder#6382MrGVSV wants to merge 2 commits intobevyengine:mainfrom
DynamicSceneBuilder#6382Conversation
alice-i-cecile
left a comment
There was a problem hiding this comment.
This feels like we should be using a BTreeMap (which relies on the ordered nature of the keys) instead of a Vec with a HashSet?
Good point! However, my one question with that is: do we want entities to be ordered by ID or by insertion? I feel like insertion might be nicer since you could give it two entities tied to particular data or relationship, and get the same result— regardless of which one happened to spawn first. Although, for large groups of entities where order doesn't really matter, I suppose ordering by ID makes the output a little more readable (entity 1 always comes after entity 0)? Any thoughts on this? |
|
My feeling is that by ID is simpler and more repeatable. It also serves as a nice little checksum. |
Makes sense. I'll push the Otherwise, this should be good to go! |
aa7ce23 to
b7fb9aa
Compare
# Objective Currently, `DynamicSceneBuilder` keeps track of entities via a `HashMap`. This has an unintended side-effect in that, when building the full `DynamicScene`, we aren't guaranteed any particular order. In other words, inserting Entity A then Entity B can result in either `[A, B]` or `[B, A]`. This can be rather annoying when running tests on scenes generated via the builder as it will work sometimes but not other times. There's also the potential that this might unnecessarily clutter up VCS diffs for scene files (assuming they had an intentional order). ## Solution Store `DynamicSceneBuilder`'s entities in a `Vec` rather than a `HashMap`. --- ## Changelog * Stablized entity order in `DynamicSceneBuilder` (0.9.0-dev)
DynamicSceneBuilderDynamicSceneBuilder
…ne#6382) # Objective Currently, `DynamicSceneBuilder` keeps track of entities via a `HashMap`. This has an unintended side-effect in that, when building the full `DynamicScene`, we aren't guaranteed any particular order. In other words, inserting Entity A then Entity B can result in either `[A, B]` or `[B, A]`. This can be rather annoying when running tests on scenes generated via the builder as it will work sometimes but not other times. There's also the potential that this might unnecessarily clutter up VCS diffs for scene files (assuming they had an intentional order). ## Solution Store `DynamicSceneBuilder`'s entities in a `Vec` rather than a `HashMap`. --- ## Changelog * Stablized entity order in `DynamicSceneBuilder` (0.9.0-dev)
…ne#6382) # Objective Currently, `DynamicSceneBuilder` keeps track of entities via a `HashMap`. This has an unintended side-effect in that, when building the full `DynamicScene`, we aren't guaranteed any particular order. In other words, inserting Entity A then Entity B can result in either `[A, B]` or `[B, A]`. This can be rather annoying when running tests on scenes generated via the builder as it will work sometimes but not other times. There's also the potential that this might unnecessarily clutter up VCS diffs for scene files (assuming they had an intentional order). ## Solution Store `DynamicSceneBuilder`'s entities in a `Vec` rather than a `HashMap`. --- ## Changelog * Stablized entity order in `DynamicSceneBuilder` (0.9.0-dev)
Objective
Currently,
DynamicSceneBuilderkeeps track of entities via aHashMap. This has an unintended side-effect in that, when building the fullDynamicScene, we aren't guaranteed any particular order.In other words, inserting Entity A then Entity B can result in either
[A, B]or[B, A]. This can be rather annoying when running tests on scenes generated via the builder as it will work sometimes but not other times. There's also the potential that this might unnecessarily clutter up VCS diffs for scene files (assuming they had an intentional order).Solution
Store
DynamicSceneBuilder's entities in aVecrather than aHashMap.Changelog
DynamicSceneBuilder(0.9.0-dev)