Is there any documentation on

[blazing bronze]

no, i think it's in progress right now. that said, what's the most mysterious thing about it?

[somber heart]

I think just clarifying exactly which parts need to be marked with [BurstCompile], that's about it. I wasn't sure if the struct itself needs to be marked or not 🤷

[blazing bronze]

yeah, the struct and the callbacks both

i'll add that to my new pinned post

[somber heart]

By the way, something I was wondering, is there a reason unity doesn't supply a function to get a reference to the actual typed system state instance? To avoid bad design? or is there another reason

[blazing bronze]

do you mean system instance or system state instance

because system state instance i believe we have

system instance, yes intentional, because we decided it was Bad Mkay(tm) to pass data around in system instances

[somber heart]

Alright, that was my thought. I'm doing some non-standard dependency injection stuff and wanted to know if there was another reason or not

[zenith mantle]

Basicly it's to 1. avoid bad design and 2. to ensure you don't call public functions (they can cause bad bad errors)

[somber heart]

What happens if you call a public function?

[blazing bronze]

i'm always a bit skeptical of dependency injection, but maybe it can be useful; i feel like it usually ends up with death of a thousand callbacks

[somber heart]

It's only for a single thing in my game that I use a lot. It's probably not needed, but it saves a few lines

[zenith mantle]

Bad errors as in, e.g. calling this:

public void MyMethod(){
    foreach (var comp in SystemAPI.Query) {
      throw new Exception();
    }
}

Will cause all subsequent calls to a structural change (EntityManager, and EntityComandBuffer) will cause errors to be thrown saying you can't do structural changes inside a foreach!
Now the problem stems from the fundamental fact that there is no clean way we can insert ourself in the callstack to do proper state cleaning (from version flag, to safety system etc.)

[somber heart]

Isn't that only an issue though if the method uses code generation?

Or is it due to how the callbacks on ISystem are called?

I think with what I'm doing I should be fine though

I just have another callback for a second initialization step I need

[zenith mantle]

Isn't that only an issue though if the method uses code generation?
It's due to us needing to clean stuff between states so nothing SourceGen related here

[rigid geode]

From wat I know, u can't put dynamic buffer into SystemAPI.Query at idiomatic foreach. Will this limitation be improved soon? I guess call SystemAPI.GetBuffer<xxxBufer>(entity) will break high performance cache line right since not all data pull from foreach in one shot?

[zenith mantle]

Query<DynamicBuffer<Element>> is totally a thing!

[rigid geode]

👀 Coming in next dots version release?

[zenith mantle]

Already works

[rigid geode]

Oh let me check

[zenith mantle]

If it doesn't pls do tell, cause that would be a bug!

[rigid geode]

Erm. Seems like DynamicBuffer can't put RefRW/RefRO

[zenith mantle]

Correct, cause it's not a ComponentData, RefX is only for Components

[rigid geode]

One more question. For Query<DynamicBuffer<Element>> at foreach, let's say dynamic has 10 elements, will all the data of 10 elements directly pull into cache line or it just only pull the tat dynamic buffer itself without any data and it will only start pulling data when u for loop dynamic buffer?

[zenith mantle]

at the moment you index into the buffer for the first time, that's when you retrieve a cache line

[rigid geode]

Ok. So it's only retrieving a cache line when u enter dynamic buffer for loop . Then I no need to purposely use Component anymore. 😂

[rigid geode]

At foreach loop, why need ValueRO and ValueRW typing just to declare read/ read & write data access? Is that possible to further improve it to make it less typing? 👀

[zenith mantle]

We have had thoughts, but no, the truth is we currently need it for two things!.. One, Compile time to know which access right to cache for you inside OnCreate. and two to throw properly if you don't have the access. Imagine an aspect like TransformAspect, where Position is a property, this means it can throw if you try to set it and you only had a ReadOnly accessed RefRW.

[rigid geode]

Want to confirm this with u. If I accidentally use ValueRW just for read data will I get any issue? I guess should be just only missing a bit of optimization opportunity?

[zenith mantle]

You will just get errors in case you happen to access it from a readonly refrw :3

[rigid geode]

I see but wat I mean is use RefRW<SomeComponent> at foreach then inside I accidentally use ValueRW just to read data. It will not throw any compile error. Is tat ok to do tat?

[zenith mantle]

It's ok to use that 😆

[rigid geode]

👀 Just curious. Will it lost a little bit performance or just no difference?

[zenith mantle]

No diff between valuero and valuerw only safety diff

Like just read the code, pretty easy to see why that is the case 😛

[rigid geode]

Btw is that possible to extend parameter count limit for idiomatic foreach just like Entities.ForEach?

[somber heart]

I feel like something that is missing from the Query api is the ability to somehow easily delete something that was iterated over, or to cache the entity query (so you can call delete on that instead), similar to how you could do it with Entities.ForEach