Search Issue Tracker
Won't Fix
Votes
0
Found in [Package]
0.17.0-preview.42
Issue ID
1378359
Regression
No
Entity LocalToWorld position is overwritten by Prefab position when namespace is 17 characters long or shorter
Reproduction steps:
1. Open the user's attached project
2. Enter Play mode
3. Exit Play mode
4. Open SpawnEntitiesSystem.cs
5. Add a character to the namespace so it's 18 characters long
6. Enter Play mode
Expected result: 64 cubes are visible in the Game view both times
Actual result: The cubes are overlayed so it looks like one cube when the namespace is 17 chars long, 64 cubes are visible when it's 18 chars long
Reproducible with: 0.16.0-preview.21, 0.17.0-preview.42 (2020.3.25f1)
Notes:
1. Additional info: https://stackoverflow.com/q/69842958/1092820
2. SetComponentData correctly sets the LocalToWorld position
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Mono Windows Builds don't produce full log callstacks when generating logs
- AssetBundles fail to load when running in Built Players for Mobile Devices
- UI elements with text gets bigger and grey when Player window is moved to another screen with different resolution
- System name accepts multiline text but crops it on confirmation, duplicates input, and shrinks the field when empty
- UI element scale and position are wrong in project build when DRS is changed with HDR and Software Dynamic Resolution enabled
Resolution Note:
This is intended behavior and will therefore be set to "won't fix".
The reasons are this:
- Changing the name (and namespace) of a system changes its default position in the frame, this is expected behavior.
- The SpawnEntitiesSystem from the provided repro project is not using any explicit system ordering attribute like
UpdateAfter/UpdateBefore/UpdateInGroup, so it follows the default.
- Because it is expected behavior but nonetheless surprising, we have a task in the backlog about making the default order not
depend on the name in the future.
- The prefab being instantiated has a Translation component and a Rotation component in addition to the LocalToWorld component.
- The transform system from entities updates LocalToWorld based on the values of Translation and Rotation.
- A direct modification of LocalToWorld conflicts with the transform system, and that modification will be overwritten.
- Because Translation and Rotation are still at their default values, the expected outcome is that the transform system will
compute an identity LocalToWorld and put the instances back to the origin.
- Unfortunately there is a bug in that particular setup (where the system doing the modification does it in OnStartRunning and
executes immediately after the transform system, if the namespace is long enough to put it after the transform system) that causes the newly spawned instances to never be noticed by the transform
system. And it is because of that bug that the cubes would show in the intended grid layout by accident.