It says in the title…
Slightly more data tho - The queue contains a list of all entities that the system will be processing, a few per frame, and so the persistence between frames is the most important aspect, if persistence indefinitely can be achieved that is perfect.
I have tried to place in a component data in a single entity made for only this purpose, first by a standard proxy conversion, later by trying to proxy a tag, then replace the tag with the active component, and immediately defining its allocation, but i still get this in the editor…
ArgumentException: AIMonitorData contains a field of Unity.Collections.LowLevel.Unsafe.DisposeSentinel, which is neither primitive nor blittable.
It appears i need a new place to put the data. All i need, is to be able to access it from a ComponentSystem ideally, or any system.
Place it as a field in a system?
i need it to persist between frames, and any attempt to do so results in deallocation errors
Seems i can just use a standard list in a component system anyways, as its running on the main thread…
But if my first system is a component system and this runs on the main thread, then does this not slow down the execution of the jobs on the other threads/processors, as it will need to iterate all my items first, before allowing teh jobs to begin allocating?
I have no idea what that is, i am still becoming accustomed to ecs.
Specifically, i need a store of information which is integral to the behaviour of all the systems, but only accessable by one system, which then modifies empty componentdats as tags to define the other system’s behaviours, it sounds like it could be complex, but im using only two tags, and one is attached to the ship permanently, only one changes.
[edit]
Also, the contents of the queue is obviously entities, as mentioned before.
Does the dynamic buffer still sound appropriate?
goes to read link
Yep I think a Dynamic Buffer would be fine for your case 
You would have an entity containing the buffer, then in a job you can use:
GetBufferFromEntity() and pass that along into your system job.
Cool, they seem to suggest only using uint, int, and float values, but the buffer can contain any variable? It doesnt outright say that there is any limit to the types that i can see tho…
I have buffers with custom structs, it works just fine… but afaik those structs can only have basic/blittable types… similar to what you can store in component data.
Ah, ok, i stored an entity in the component data fine, so it should hopefully work.
Do you think there would be any drawbacks to using a single component system before the jobs run? I expect it to be a very large list, and i think it might work out advantageous to have the additional flexibility of a standard list rather than a native one anyways?
[edit]
I just also thought, if i ran the component system after the jobs are allocated, it would then result in the main thread usage not really being a problem, i guess?
There might be some drawbacks to CPU utilization, but if this system processes a list that’s very large (spans multiple chunks) then it should be spread across multiple cores.
btw you can set systems to run in at a certain phase like Init (before most systems run) with the UpdateInGroup attribute.
More info here: System Update Order | Package Manager UI website