Ever since layer metadata has been accessible for tile-based layer entities via a component, it has become a pain point that entity layers do not have a layer entity associated with them. This PR makes it so they do. Now, LdtkEntity/EntityInstances spawned by the plugin will be children of a layer entity w/ a LayerMetadata component, which in turn is a child of the level entity. The behavior of the Worldly component has been adjusted accordingly.
The scheduling of worldly_adoption has also changed. In the most recent iteration of the schedule, the main constraint for scheduling this system was that it should be after Update to have minimal frame delay in the odd case that a user adds it to entities manually in Update. Putting it in PostUpdate still satisfies this constraint, and also allows us to schedule it after transform propagation. The purpose of this system is for worldly entities to maintain their global transform after they are re-homed, so I think it's important for the global transform to be calculated before trying to give them a new parent. It shouldn't affect physics since they wouldn't have a global transform until PostUpdate anyway.
Closes #224
Ever since layer metadata has been accessible for tile-based layer entities via a component, it has become a pain point that entity layers do not have a layer entity associated with them. This PR makes it so they do. Now,
LdtkEntity
/EntityInstance
s spawned by the plugin will be children of a layer entity w/ aLayerMetadata
component, which in turn is a child of the level entity. The behavior of theWorldly
component has been adjusted accordingly.The scheduling of
worldly_adoption
has also changed. In the most recent iteration of the schedule, the main constraint for scheduling this system was that it should be afterUpdate
to have minimal frame delay in the odd case that a user adds it to entities manually inUpdate
. Putting it inPostUpdate
still satisfies this constraint, and also allows us to schedule it after transform propagation. The purpose of this system is for worldly entities to maintain their global transform after they are re-homed, so I think it's important for the global transform to be calculated before trying to give them a new parent. It shouldn't affect physics since they wouldn't have a global transform untilPostUpdate
anyway.