Often when generating/setting up elements in a game you will only need to do it once using GOs you can do this in the Start() or Awake() functions is there something similar in Systems?
At the moment I’m using an OnUpdate() that ends with Enable = false;
Why put it into the system if you want to run in only once? Why don’t use a simple job? I’m using a system with a component. Like i.e. for map builder. I could be an empty component.
Well I’m thinking that we want flexible systems not just always OnUpdate(). Then we can ensure that unused systems are not consuming resources when they are idle.
Also it would more align systems with what people are used to from GameObjects making it easier to move between both API’s.
I think systems don’t run at all if there is no data they want to operate on.
What about generating/setting up entities on startup?
You would need to add a consumable tag to an entity in the scene to trigger the system then destroy it. And some system within Unity would be monitoring for new entities of that type.
As far as I understand how it works, a system looks for the change in archetype chunk it works on. So or it’s just a check if chunk exists/is empty, or there is some sort of event-like behavior that turns the system off while a new change in entities creates/fills up a chunk that is defined by the system. In both ways, it seems that it’s negligible.
In my project, I have a tilemap and to make one I made a system that needs a component with size and stuff. It runs only when I want to load another map so quite rarely.
But as I asked before: Why do you need the whole system for a one-time thing? Just use a job in i.e. monobehaviour class or OnCreate() in one of your systems.
If you really only want to run the logic once on startup and never again, that logic should be invoked from an ICustomBootstrap. Otherwise, reacting to any entities with a particular component that you then remove after completion is the ECS way of going about things.