Change SpawnAtPoisition EntityCoordinates overload to use the rotation of the attached entity, and to allow a rotation override. #6527
Conversation
|
Don't SpawnAttachedTo and PredictedSpawnAttachedTo work for this? |
No because it'll spawn the entity attached to the entitycoordinates passed (which isn't always the grid) where as this will always spawn the entity attached to the grid, relative to the entity coordinates passed. |
|
Coming back to this after a bit but I also wanted to ask if a sort of modified SpawnNextToOrDrop that allows an offset would work for this |
Posts that tell you nearly exactly what bug they're working on. |
The thing is it takes a TransformComponent instead of EntityCoordinates or MapCoordinates, and I feel like offsetting the target while spawning could cause other issues, so I don't really see how you'd achieve an offset with the method itself right now, even though you could probably offset the spawns after the fact |
Entity coordinates are a struct so really the only difference between content and engine doing this is if you're defining the variable in the engine or in content. |
Title.
I looked through content and every usecase of this spawning method except one either spawns an entity that does not rotate, hence is unaffected by receiving world rotation, or spawns at coordinates, the tries to insert into a container (should be using another API method).
The one exception is stack system, where the item spawns rotated incorrectly.
However, I suspect other systems may want to use this override, I plan to make it so ConditionalSpawningSystem uses this override as spawning attached to the current entity seems unintentional when every usecase I could find seemed to desire it being spawned attached to the grid.