I̶t̶ ̶s̶e̶e̶m̶s̶ ̶t̶o̶ ̶b̶e̶ ̶p̶o̶s̶s̶i̶b̶l̶e̶ ̶t̶o̶ ̶a̶c̶c̶e̶s̶s̶ ̶s̶t̶a̶t̶i̶c̶ ̶c̶o̶n̶t̶e̶n̶t̶,̶ ̶e̶v̶e̶n̶ ̶m̶a̶n̶a̶g̶e̶d̶ ̶o̶b̶j̶e̶c̶t̶s̶ ̶i̶n̶s̶i̶d̶e̶ ̶a̶ ̶b̶u̶r̶s̶t̶ ̶c̶o̶m̶p̶i̶l̶e̶d̶ ̶j̶o̶b̶. I’ve assumed I would get some error
What exactly you can and cannot do in burst compiled jobs? I want to know exactly my limitations before I end up figuring it’s impossible in the middle of development
The idea of this is to use a dictionary (uint, MyClassThatHandlesThisNetworkMessage) to be able to easily create classes that handle and send network messages back and forth while using the jobfied client/server from the transport(GitHub - Unity-Technologies/multiplayer: Unity multiplayer packages and samples) example
I am aware that I might end up having to make a handler for “jobfiable” handlers and “non-jobfiable” handlers, like when I need to create an Entity or GameObject as a consequence of a message. I am still thinking how I will “extract” the message data to later consume it in a “non-job environment”
For instance, when testing the limitations, I could “count to 10” (for int i < 10 (…) Debug.log(i)) but I couldn’t create a new GameObject. Also, what exactly is a “burst compiled” piece of code, and how it handles static access to code it does not even know what will be at compile time.
I am also aware that I am somewhat giving up performance for convenience, and if you guys think that doing this will completely remove the whole point of this mean a job to begin with, please tell me