#so if system level data is stored on

1 messages · Page 1 of 1 (latest)

balmy notch
# 
partial struct SomeSystem : ISystem {
    ... OnCreate(ref SystemState state) {
        state.EntityManager.AddComponent(state.SystemHandle, new MyComponent{arr = new NativeArray(42, Allocator.Persistent)});
    }
    
    OnUpdate(ref SystemState state) {
       var arr = SystemAPI.GetComponent<MyComponent>(state.SystemHandle).arr;
       arr[23] = 101;
    }
    OnDestroy(ref SystemState state){
       SystemAPI.GetComponent<MyComponent>().arr.Dispose();
    }
}
runic veldt
#

Hold on

#

Native collections can be stored on comps now?

ivory carbon
#

yes, they are not managed anymore

runic veldt
#

Holy

#

Welp

quasi token
#

i think i'll have to digest this, but yeah i think all these changes are for the better

runic veldt
#

We're guchi now

dark rain
#

I've been curious about this. Conceptually I like the idea of storing all data on components including system data
Practically, what's the benefit and is there not (tiny) overhead in retrieving this from a component instead of just direct referencing it in the system?

ivory carbon
#

yep, i don't get this either

runic veldt
dark rain
#

what do you mean?

runic veldt
#

Can be accessed from any execution lath

quasi token
#

faster although it does seem a touch cumbersome

ivory carbon
#

you can get unmanaged isystem data (stored locally in the struct) with a ref

runic veldt
#

Can be accessed in a very fast fashion through pointer reference to comp data

dark rain
#

my favourite part of 1.0 is the removal of physics requiring a system reference

runic veldt
#

You access data

dark rain
#

yes i get i can do that now

#

but that's not what i'm talking about

#

i'm talking about system state that is only relevant to the system itself

runic veldt
#

Oh, Thay

hallow forge
#

Wouldn't you just make the state component internal?

ivory carbon
#

yeah if you just need data locally it's a very roundabout way. i don't see the benefit

runic veldt
#

Aka SystemState

balmy notch
#

There's actually a few things to unfold here!
@balmy anchor is likely the best person to ask here. But I'll try.

It comes down to cross system references. scalability and restoring state.

  1. It means you can later decide on where the data should actually live.
  2. You're not directly dependent on a Systems implementation so you can switch things as you go - Your system doesn't need it anymore but another one does? awesome, now just flip where you got the data, no need to do a massive rewrite.
  3. Calling public methods can cause baddddness to incur. For instance throwing inside will not properly restore state, as we can't do cleaning in the upper part of the call stack.
    example here:
MySystem : ISystem {
    public void SomeFuncionThatThrows(){
        foreach (var q in SystemAPI.Query<SomeComponent>()){
            throw new Exception();
        }
    }
}

causes all subsequent systems to throw an exception stating structural changes == badness cause you're inside an entity iteration (even tho you indeed aren't)

pallid raven
#

Isn't one the main benefits of using components the automatic dependency management?

dark rain
#
  1. totally agree with

i'm more thinking about the state of simply caching a persistent allocated native container that a system job re-uses (but doesn't re-use data between frames, it's just junk)

#

it just doesn't seem beneficial to store it on a component

pallid raven
#

Yeah, for state that only a single system needs, storing it directly on the system seems like a simpler way to go. I assumed this new pattern was designed specifically for the system sharing use case

balmy anchor