I have to duplicate your authoring component logic in my conversion? This is a fragile pattern, no?

Im setting up two objects which are attached to each other via a fixed joint, and I want to specify, in my authoring component, the combined mass of both of objects and a ratio of mass between them (among other things), and have the conversion script work out the inputs to the physicsbody components of it and its parent and set it all up for me.

Can I just use the PhysicsBodyAuthoring components in code in my conversion script, or do I have to just duplicate all the logic defined in the PhysicsBodyConversionSystem in my convert function?

If I duplicate that logic in my conversion scripts and in the future I upgrade to Unity Physics 0.4.1+, I have a problem. They may change the conversion system such that it now also adds, e.g. a PhysicsInertialTensor component, and all my convert scripts will have fallen out of sync and the entities will have undefined behavior.

authoring components are essentially a simplified wrapper around creating sub entities and adding more granular components. It's weird to me that ECS isn't set up to expose that wrapper to code easily, and that you typically just have to duplicate whatever the wrapper is doing and hope that it never changes

like, yes, authors could explicitly make that code separate, but the way GameObjectConversionSystem's are typically written -- with a lambda just embedded into an entities.foreach - and the way IConvertGameObjectToEntity 's are written -- with a convert override accessed during conversion -- means that in 99% of cases, that wrapper logic will never be exposed

its like the expected pattern is fragility by design

Alpha software and all that, but is this even on the radar to improve?

 

Is there some way to do that in code in my own authoring component?

As I said in the OP, the point is that I add an authoring component to a child object and specify the combined mass of that child and its parent and the ratio of mass between them, and then I want the code to programatically set up the appropriate inputs to the parent and child entity physicsbody authoring components.

so, and again this simplified,
my authoring component expresses this:
objects A and B are a single object attached by a fixed joint with a combined weight of X and a mass distribution Parent:Child of YY% favoring the parent.

If I want to tweak the way the movement looks by changing the combined mass and the distribution, I have to go into each authoring component on each one and work out the math by hand each time and set each one up accordingly. If I put all the mass in only one object, they wouldn't rotate correctly. If I make both objects have the total mass and set one to be unaffected by gravity, then the one with no gravity prevents the whole thing from falling at the correct speed because its inertia works against gravity.

and if I was only working this out with one pair of object one one set of dependent vairables that might be fine, but thats just not the case.


so again, the point is: I want to add PhysicsBody s in code in my authoring script, because a single set of inputs controls the configuration of the PhysicsBodys on multiple entities

 

@HeliosJack wouldn't a GameObjectConversionSystem with

[UpdateInGroup(typeof(GameObjectAfterConversionGroup))]

attribute work for you? Then you can do any post-conversion logic for the authored physics bodies.

 

Well, I mean I wouldn't think so? Changing the authoring components after the conversion has happened would be like dodging after the arrow hit you: there's not much point. The authoring component's values no longer affect the runtime components at that point

Again, the combined mass and mass distribution are inputs to my authoring component, and those dictate the inputs to the individual physics bodies of the two entities which they govern

 

And I mean in general, I feel like adding physicsbodies in code, perhaps creating entities with physics at runtime, would be a common enough thing that it should be obvious that any complex internally organized wrapper that expands into near a dozen individual runtime components from a simple set of inputs needs to be exposed to code -- its just basic library authoring. without that, I have to duplicate the current implementation of the wrapper logic in my code and hope that it never changes

 

I'm not sure I understand your setup 100% but how about something like this...

Add the PhysicsAuthoringComponent to those objects that need it. You have your own HeliosAuthoringComponent monobehaviour that is what you as a frontend designer would interact with. That HeliosAuthoringComponent can execute in editor mode and hold/grab references to its particular PhysicsAuthroingComponents and do the math required to maintain the relationship you are looking for between these objects.

 

I think you have roughly the idea. And yeah, it seems like an editor script may be the only way to accomplish this.

Lol, or I could write an autohotkey script that would just click into the required places on the UI and manage the components that way! #programming

but really though, an editor script is probably the workaround I'll use. Are there any examples of this someone can point to?

 

Actually I just realized that an editor script is unsuitable for my actual use case, even though it would be suitable for the simplified version I presented as a problem here. Because in my authoring script, the second object needs to rotate freely around its own centerpoint _and_ be attached to the first object on a fixed angle spring joint. So the only way to do that is have a middle object.

In other words:
A and C are the 2 objects I create in my editor. I attach HeliosAuthoringComponent to object C. C needs to be attached to A via a spring so that it has a bouncy elastic connection, and C needs to be able to spin around freely.

so, I create an intermediate entity B. A --spring-> B --freerotation->C

so, since this object B is never in the editor, an Editor script wont cut it. and since entities have to have physicsbodies to be used with joints, I'm back to having no choice but add a physicsbody in code.

I mean I guess I could just create the third object in the editor too.

 

This answer with a slight modification actually does satisfice, and perhaps this was what you were getting at @brunocoimbra . I instead tag my conversion system with

[UpdateBefore(typeof(PhysicsBodyConversionSystem))]

, which allows me to access and set the values of the

PhysicsBodyAuthoring

component before they get passed into conversion. then its just a matter of setting up the parenting relationship ahead of time, and everything becomes doable.

 

Yeah, I first thought that it wasn't necessary to actually modify the Authoring component before the conversion, but yes, to execute something before is just a matter of switching the attribute there, so you totally got my point.