Do I understand correctly that there is no automatic buffer authoring?
I’m pretty sure that yes, there is no automatic IBufferElementData authoring yet.
Luckily, it isn’t too hard (maybe a little bit tedious) to handle the authoring yourself. I personally don’t think automatic authoring is all that useful. There are a lot of situations where building your own authoring component is the better way to go as it allows you to add a ton more functionality and removes some component clutter in the Inspector. (Although, let me tell you, after you have twenty authoring components on a GameObject things get really hard to find). 
Sometimes you can group components into one atomic authoring if they are always used together in a system or group of systems. This would reduce the inspector clutter a lot. Establish dependencies between atomic authorings with RequireComponent
1 Like
Yeah, I’m not at a point yet where I use many components, but I refactor a lot, and with custom authoring there is extra 2 steps to refactoring potentially: rename class, rename file. I find automatic authoring perfectly fine so far and I absolutely don’t mind many components per entity, which is why I really hated that they scrapped all the tooling on project tiny and switched to “entity conversion”…
1 Like
I second that.
Kinda like the “PhysicsBody” component which wraps the complexity of up to 3 different components into one single authoring component. It’s often really useful to have an authoring component that intelligently sets up the real components and doesn’t just do a direct conversion
1 Like
Whoa, I had no idea you could group components into a single atomic authoring like that with the attribute. (Although, I suppose I never tried…). That’s really cool. I’m going to need to remember that. 
EDIT: You can’t actually do what I responded to. 
Yeah, I completely understand the pain of having to do a lot of renaming. I, myself, am not completely against a ton of components on an Authoring GameObject or Entity (It’s just how things work, unfortunately). But what I would like would be something of an advanced drawer / file system, kinda like in Blender 2.8 where there’s different subsections for certain kinds of data (Material, Object Info, Particles, etc). 
In Unity, we could have the same thing, just with a different set of drawers. We could have drawers for things like Rendering, Physics, Colliders, etc. And whenever you added a component to an Authoring GameObject or Entity, they would automatically be added to the appropriate drawer. Also, we could make custom drawers too, and specify which of our own components would go in what drawer! Lastly, certain drawers would be persistent (Rendering, Physics, that kinda stuff), but others would be dynamically added when a component required to be within that kind of drawer. 
I dunno, it sounds cool. Personally, I’m not custom Inspector savvy, but I feel like unity really needs organizational stuff like this, and I would be really happy if they did something like I proposed in the future! Especially if they did something similar for the Hiearchy… Which is a pain. Just imagine being able to select scripts only relating to physics in the hiearchy? Or scripts that had collider stuff? That’d be great! 
Since I don’t have designers using my components, I’ll without hesitation take the transparency and much greater ease of coding and refactoring of automatic authoring components over custom authoring scripts.
Sorry I miscommunicated, you need to write a Monobehavior with IConvertGameObjectToEntity and inside of the Convert method add all required components and buffers to the entity
1 Like
Asynchronous operations are started by calling a free function or member function known as an asynchronous initiating function TellSubway. This function accepts parameters specific to the operation as well as a CompletionToken. The token is either a completion handler, or a type defining how the caller is informed of the asynchronous operation result.