[Questions] ECS/Burst and custom assembly plugins.

I have been struggling to find time to test out 2018.XX features.

In particular, I have been interested in the ECS but an existing 2017.x project has been taking up my time, day an night spent trying to finish an existing project. However I have been trying to read up wherever I can to get some understanding of the ECS/Job System and something else now is already starting to worry me.

As I still haven't found enough the time to play with it, I haven't really been able to verify this myself... there seems to be no projects whatsoever demonstrating the use of the Job System or ECS from within a custom plugin assembly dll in any shape or form whatsoever. I have made one attempt so far to utilize the job system in a custom assembly and with little understanding of it, it didn't do anything (at all) (lack of documentation at the time didn't help much either).

In all my projects I use and develop/update and maintain a common shared library. In almost ALL of my projects, I almost always build my code into a seperate (or many) assemblies, mainly to avoid the messy clutter of scripts floating about all over the assets folder. There are several new attributes which appear with the jobs system, but with all this talk about new compiler things... and nothing really been said about plugins as far as I can see.

Now knowing some of Unity's habits... (for example: UNET).... I am suspecting that anything related to burst, attributes, and the ECS, will be potentially (completely) unusable in custom plugin assemblies? When unity do custom compiler things, I worry that the design of such features would target only asset folder drop in scripts exclusively, as is the case with the UNET multiplayer hlapi.... is basically completely unusable from any and all plugin assemblies "unless" we manually force feed our assemblies to UnetWeaver (which in turn breaks alignment with our PDBs/MDBs, so they become pretty much not-debuggable anyhow).
Teams wanting to build multiplayer games, while maintaining their code base in separate plugin assemblies, are forced to either create their own from the ground up, or rely on a 3rd party solution (luckily AppWarp and Forge Networking supply their APIs in assembly form, while photon is pretty much unusable to us).

There is no information which appears easy to locate on this subject, as I would think new features would be designed to cater to the majority of development workflows (though not the case with UNET, and possibly others...).


The short version(s) of my questions are:
- Will the entire job system/ECS api set be usable from a plugin assembly (at the minimum), including all attributes (none of that unetweaver like stuff).

- Will the burst compiler be able to process custom assembly dlls, or will there be a possibility of providing a Burst compiler extension for Visual Studio, what are we actually doing to accommodate for custom assemblies? How do we assembly guys make use of the burst compiler in any way, or will custom assemblies be left out entirely (zero optimizations)?

...or will we be forced to rely on a 3rd party solution, or build our own?

 

I am also very interested

 

I was thinking about it, how to reuse systems that we made, because just copying files isn't good. So I think they will open Package Manager to users also, so we can keep our code organized into packages and don't need to keep everything as DLL, so burst compiler can optimize it.

 

I wish we could use reflection to load some plugins while the application is running. If we could connect and disconnect the systems via reflection, we could achieve everything!