Today I fix a bug which is caused by this 0.2.0 update. After this update, conversion system runs after OnStartRunning() of systems which update in [InitializationSystemGroup].
I think DOTS code is clean and easy to play with, however, what I found out is, most bugs are related to system sequences. Therefore, I think add some little features like simple timeline, or an option to log callback of every system might be helpful for debug purpose. Also I was wondering how other developers handle these sequencing problems?
I’ve often found the absence of a very clear and explicit sequence to be a big source of bugs and headaches in monobehaviour, so I’m pretty happy that execution order is now very important.
It requires a bit more thought to be put in what you’re doing, but in the end I think it results into much more robust code
Yes you are right… I guess the biggest sequencing problem I meet is I use the double ecb as signal many places, and this must be updated in [InitializationSystemGroup].
[UpdateInGroup(typeof(InitializationSystemGroup))]
---- system ----
--- Job ---
BeginSimulationEntityCommandBuffer.AddComponent();
EndSimulationEntityCommandBuffer.RemoveComponent();
Unfortunately I can’t find the docs that show what the default PlayerLoop in the PlayerLoop API is, but I do know that Initialization (of type PlayerLoopSystem) one of the first things that runs in a frame and it runs before a lot of caches from the previous frame get wiped. InitializationSystemGroup gets placed at the end of the Initialization subSystemList so it gets updated after the Time update. Similarly, SimulationSystemGroup gets updated at the end of the Update PlayerLoopSystem, which means it happens after all MonoBehaviours finish their Update call. Since ConvertToEntity is a MonoBehaviour, the order of execution seen makes sense.
My point here is that none of this is a black box anymore, and you can modify quite a bit if you care/dare.
Although custom Convert is mono behavior, it’s called from the ConverToEntitySystem, I’m not sure where is it before, but now this system is in InitializationSystemGroup. You see? If you don’t look at how it implement, you would fall into pitfall and wondering what’s wrong.
Sure you are right, it’s not black box, everyone can check the code, but it’s just not that obvious.
Nice catch! I hadn’t dug into that codepath much in Entities 0.2.0 yet since that was one of the few parts that didn’t break my code. I do believe this stuff should be documented once Entities leaves preview, but I don’t blame Unity for not doing that yet since they haven’t figured out FixedUpdate yet.
1 Like
where can i find more details about “double ecb” ? i did put my system in [InitializationSystemGroup], but i don’t know why i can’t put them in else where
I think he meant : If you want to defer some structural changes, and have that changes be able to take effect in the same frame on some later system, without adding any of your own custom ECBS, then the only choice is that the first command enqueue must be in init group, so you get 2 possible playback target of endinit or beginsimulation. Then your simulation system can rely on changed entities, and enqueue the 2nd set to endsimulation.
1 Like
thx, but still feel un-intutive about “physics system update in [InitGroup] rather than [PhycisGroup]” such thing, maybe a OneFrameComponent (like Event) should be a more common pattern, i’ll check https://forum.unity.com/threads/event-system.779711 for more thoughts
It’s for making and deleting an event component at one place. In this way it’s life time is exactly from beginSimulationEcbSystem to endSimulationEcbSystem. It’s introduced here.
https://www.youtube.com/watch?v=KuGRkC6wzMY
But now I found it’s not very ideal in some cases for dod paradigm.