Difference between BakingType and TemporaryBakingType: When you make a change to a subscene and save, unity performs an incremental bake (aka, not a full bake) to save time. BakingType are like normal components, but they are excluded from runtime. TemporaryBakingType are like BakingType, but they get removed after your incremental bake is finished. They are not saved in the subscene. That means if you make another change, the "TagComponent" from the previous bake will not be there.
Thank you for your interest in my work. I would love to make videos about the mgm-ability but as you might expect I have a lot of stuff to update to 1.0 first. And the tutorial series take a lot of time to make. I'll do my best ☺️
Hello, Thanks for the suggestion ☺️. I'll consider it for the futur videos, but it won't be soon :/. In the mean time what I can say is that UI is not DOTS specific. For HUD I would personally use UI Toolkit for the UI Builder. For world UI (e.g. health bar above unit) I would use Ugui since UITK don't support world space UI. Either way I think the best thing to do is to use a Model View Presenter pattern. Where the model can be a class component the view the UGui or UITk and a system that updates the model.
@@mrbinggrae5954 trying new production workflow for the videos to improve productivity. Not a great success 😵💫. Few more hours and it should be good. 🤞
Hello, thank you for the comment and the question. It all depends on the use case. ISystem is the recommended way to go from 1.0 has they will allow to burst most of the game loop, including main thread. SystemBase on the other hand won't allow you to burst the job scheduling happening on the main thread but since it's a class it can allow inheritance and some cool pattern with generic systems. SystemBase also support Entities.Foreach syntax which allow to switch from mainthread to multi thread with a single line of code. ISystem don't and won't support Entities.Foreach syntax and use the idiomatic syntax. That syntax only allow main thread code execution. If you want multi threaded code you will have to use a job. Jobs are supported in both ISystem and SystemBase. I'll let you decide which you prefer after I explain the ISystem and idiomatic foreacg in the next video. TLDR; use whichever you are more confortable with, if you look for extra performance and/or have a lot of systems, use ISysytem.
@@WAYNGames Awesome, thanks for such a heartfelt response, I've totally figured out how to choose between them! Looking forward to your next video, it's been a very good help in my studies, thanks for all you do!
I wonder if there is a way to control in what World the baked entities will end up, in my setup I have a client and a server world, both should have their own version of the same scenes (the server one won't have presentation related stuff) but I don't get where in that work flow we are supposed to direct the entities into custom worlds.
I had a similar issue. In previous net code version the authoring component allowed you to specify if the subscene was client only or server only or both. It is not the case anymore. Now it seems you need to handle that through scene management. You create your client only subscene and load it manually at runtime if you are on the client. Basically you can have a subscene for shared data (client and server) and in that subscene you have an entity that tracks the reference to a client only subscene. When the shared scene is loaded you have a reactive system that load the client only subscene and destroy the referencing entity. Same for the server only subscene. This is probably a simplistic approach and may have many flaws but that the simplest thing I could come up with to have client only entity.
EDIT The world provided to the SceneSystem static methods need to have some internal systems to load the scenes, it doesn't use the default world ones unless it's the one you use as parameter, some of this systems are internal which forces to use the default initialization or dirty reflection tricks, in my case it's a problem but I m leaving the info here in case it helps someone. --- @@WAYNGames I was about to reply to my own comment to say that I figured out that my issue was in fact part of the scene streaming logic, I was creating my own worlds and just recently reactivated the default world part, and I realized (if i'm correct) that the SceneSystem is meant to live in one of the worlds (typically the default one) and that system has public static methods that take an UnmanagedWorld as parameter (ie. client or server world for me), the system do the loading in yet another separate world(s) dedicated to loading scenes and then transfer all the entities into the world that was originally provided. My understanding is that at runtime this does not involve baking because that happened in the editor once (upon modification) and the result (the cake) is then serialized and stored. I really appreciate you taking the time to answer a random question like this, I found the video specifically helpful in the sense that you detail the underlying processes as opposed to "you do this and it will do that" kind of explanation, very refreshing I ll keep watching.
I must note that what you just mentioned is also good to know, I focused on my findings because they fit my use case, I especially want to avoid mixing references in a common scene because, if I understand correctly, Unity will determine the strong and weak references by itself and build a resource file that is yet again a brand new way of handling resources (RIP Addressables) but the problem with unity doing everything by itself is that I assume that the server build would contain that common/shared scene and if it contains weak references to client scenes that will automatically be part of the final bundle as well and increase dramatically the server footprint. I assume it would do that but I don't know for sure.
For anyone coming at this now, the syntax and methods for the baker have slightly changed. Some of the older methods have become obsolete. They still work, but the compiler warns you. public override void Bake(EnemyAuthoring authoring) { //must explicitly grab the entity and pass to all AddComponents. TransformUsageFlags transformUsageFlags = new TransformUsageFlags(); Entity entity = this.GetEntity(TransformUsageFlags.Dynamic); Speed speed = default; speed.Value = authoring.Speed; AddComponent(entity, speed); if (authoring.Waypoints == null) { return; } AddComponent(entity); DynamicBuffer path = AddBuffer(entity); foreach (var authorPoint in authoring.Waypoints) { Waypoint waypoint = default; waypoint.Value = authorPoint.position; path.Add(waypoint); } }
