The manual and the hello world kinds of ECS samples now always use SystemBase and it seems we can simply use Schedule/Run as we see fit and don’t need the older JobComponentSystem/ComponentSystem anymore but some code specially in physics and also other places still use them.
Is there any reason behind this? Is there any difference between them? What is the plan for the future?
Specially I was looking at generating trigger events and its samples use JobComponentSystem instead of SystemBase in many places but some use SystemBase. What am I supposed to do?
JobComponentSystem/ComponentSystem - deprecated and will be removed eventually.
SystemBase - combines better from both + better codegen. Only this recommended for usage.
Thanks but as wrote above, I know the manual recommends that but still physics and other samples use the older ones. want to know if the unity team itself has a reason for using those there or it is just older code which is not updated yet.
Updating package is not always that easy.
Keep in mind that these are preview package depending on preview package…
I don’t expect the update to newer “recommended” implmentation to happen over nigth (it will for us but not for the dev doing the work :p).
Factor in also the new features they are most likely working on and the refactors linked to the packages themselves (not the one the depend on), it’s no suprise that some packages still depend on older versions of the entities package.
@brunocoimbra Thanks I’m curious how do you know this for sure that there is no difference in behavior between JobComponentSystem and SystemBase? Any quotes from unity team/source code place ?
This was already stated many times in the forums that ComponentSystem and JobComponentSystem are going to be deprecated and SystemBase should be used instead. I would guess that the reason why those weren’t “officially deprecated” yet is because there are some official packages that weren’t updated yet.
@brunocoimbra thanks again yes I have the same guess but I was looking for something more official and more detailed but for now let’s assume what you say is true and there is nothing say in physics or other packages depending on you using JobComponentSystem or … and this thread will be responded to if the assumption is not right
JobComponentSystem will be deprecated soon. ComponentSystem will likely stick around for a while longer due to it being used in conversion code. Please do use SystemBase whenever possible. It should be a complete replacement for JobComponentSystem and all work is currently being done to optimize and add features to it (as opposed to other system types).
@joepl Thanks , So the question is what still is in ComponentSystem which is not in SystemBase and for that I have to use ComponentSystem.
We are doing the pre-rpdoctuion of our next game in DOTS and we are very happy so far. I worked with DOTS for a now cancelled project back in last august as well and back then the separations were clear , now I’m a bit confused. But if there is no advantage to using ComponentSystem now then I can go for SystemBase for everything.
This said one of the things which I haven’t done is syncing entity data with unity’s none dots systems like for example when the character wants to interact with an object we show a UI if they press F when in collision with the object. The collision can be handled with ITriggerEvents jobs easily and the input can be sent from OnUpdate to the system which does the detection job but do I have to use the componentSystem for some reason when syncing the data to a MonoBehavior responsible for showing the UI/a system which does that on main thread? any advantages for doing so?
@brunocoimbra Look at the answer above by joepl, I read the docs of course and specified in my question that I know they are being deprecated but it seems based on joepl’s comment above stil they serve a purpose.
I think that the response from @joepl should interpreted more as JobCompoentSystem will soon be deprecated, Component system will be depracated but a bit later.
In any case you should use SystemBase for all your systems, for synching with “legacy” game object you can most likely still do it in a SystemBase with a flavor of Entites.WithoutBurst().ForEach(()=>{}).Run()
@tertle I’m not sure why you are angry but if you read my question, I already specified I know what these people are telling me and re-iterating what I myself have read and specified have read is not helpful to me! I was not looking for any of the people’s guesses and was looking for to see why unity people are doing that, is it just not updated code yet or there is some reason which unity guys or someone with good knowledge of the source pointing out to the file in implementation could answer!
Despite that I tried and try to be civil. This is true in many forum posts, people post their guesses either in the hope that they are useful/can be useful (I do that myself once in a while and specify that this is my guess) or send incorrect answers! That is not helpful but somebody getting angry because you don’t want those guesses/info you specified you know yourself is not good. You seem knowledgable IIRC om other posts but correctly if I am wrong, is it too much to look for the answer to my question ?
@Ashkan_gc : “How are the system types different?”
everyone: “Only use SystemBase.”
They keeps asking, because no one has yet answered their question. And @tertle , there’s no need to make things personal here - that’s a good way to turn people off from trying to learn DOTS. Maybe the tone was mistranslated in the writing.
OPer, I don’t have a good answer for you either, but I think you can probably learn more by comparing the SystemBase and JobComponentSystem sources. Both of these derive from ComponentSystemBase, and aren’t very long. Unity clearly thinks SystemBase represents a better approach, that both optimizes system updates, and makes it unnecessary to have two base types for systems going forward. They’ve also commented, back when it was released, that there were future optimizations planned for SystemBase which aren’t in yet.
The largest difference I know of off the top of my head is the SystemBase has built-in support for Scheduling Entities.ForEach Jobs, in a way that handles the dependency management for you. Entities.ForEach (among other perf initiatives) represented a move to make ECS code easier to write for users used to the simplicity of MonoBehaviours. SystemBase debuted in that timeframe, and the automatic/hidden dependency management seemed like it could be part of that effort.
In general, ComponentSystem was previously reserved for systems that didn’t schedule jobs. It was originally meant as a half measure, so people could learn to use ECS logic (or to prototype) without having to also know jobs and burst too (based on old forum comments by Joachim). So it hasn’t been a good idea to derive from it directly for a long time now - barring special cases.
Just to be clear, this is not a guess, you should not use ComponentSystem and JobComponentSystem as stated in the docs (that I previously linked to you). ComponentSystem is an old API, that is required in some underlying systems for now but will vanish at some point (as stated by both the docs and by joepl).
But, well, you are free to use soon-to-be-deprecated API if you wish, but consider warned about it.
To answer the actual question at hand
SystemBase vs JobComponentSystem
SystemBase contains a new Dependency property instead of inputDeps and the return value for OnUpdate. This allows it to automatically detect synchronous execution cases (no need for [AlwaysSynchronizeSystem]) and fast-path post-OnUpdate operations for entirely single-threaded systems. It also has better codegen support.
SystemBase vs ComponentSystem
ComponentSystem does not have any of the codegen functionality and instead has the old GC-producing Entities.ForEach. It always runs synchronously.