This will take a dependency on the children

[torn river]

       /// <summary>
        /// Returns the children of the GameObject
        /// </summary>
        /// <param name="includeChildrenRecursively">Whether all children in the hierarchy should be added recursively</param>
        /// <returns>The children of the GameObject</returns>
        /// <remarks>This will take a dependency on the children</remarks>
        public GameObject[] GetChildren(bool includeChildrenRecursively = false)
        {
            return GetChildren(_State.AuthoringObject, includeChildrenRecursively);
        }

This is a function in Baker<...>. What does "This will take a dependency on the children" mean? Is that a Job system thing? If yes, when is that dependency completed? Can I combine it with other dependencies?

What is a correct use case for this - is it all right to call GetEntity(childen[index]), with intent to call AddComponent?
(instead of having to have a different type of Baker on all the child objects, which talks to the parent?)

[rose saddle]

that means if children change - this exact baker will rerun

during live baking

[torn river]

Seems like I cannot use it to access these entities, what gives?

var children = GetChildren(authoring);
foreach (var child in children)
{
  var child_entity = GetEntity(child, TransformUsageFlags.Renderable);
  AddComponent(child_entity, bootstrap);
}

Ok, so... I literally have to place a specific authoring component on every entity (e.g. buildings in a city..., and every door, window, and whatnot), if I want to place a component on all of them during baking?

Where am I mistaken here? This new baking flow is way more confusing than I thought.

[harsh mica]

Bakers work on a single gameobject, that's it

[torn river]

What is the purpose of the GetChildren method, then?

[harsh mica]

If you want to do more complex multi entity work you can use a baking system

[harsh mica]

So that you can add a reference

But you can not add a component to anything except the gameobject you're baking (or any additional entities you create)

[torn river]

Wow.

I have a couple of baking systems but these were for the old flow, gotta see how the new ones work.

Can I access MonoBehaviours and other Mono-Land stuff in that system?

[harsh mica]

If you want to manipulate them you could dump them in a baking only buffer and do it in a baking system

[harsh mica]

You only have access to the entity data at that point

[torn river]

haha

wow that's insane.

I'd really like to see some real world use cases at this point, and the examples are really scant.

Especially for baking.

There's some sort of disconnect how I see the Unity/Entities world, and how others seem to see it.

I found the older Conversion Behaviour on GameObject flow much more intuitive and flexible.

Why even have Mono-Land authoring components when they can do practically nothing in reference to other objects in the scene.

I'd much rather have a text description language to assemble my entities from assets.

Markup 😛

(at that point)

It is completely insane.

[harsh mica]

Baking, you put your gameobject in the oven, you get an entity back. But it's 1:1. It's not called food preparation 😄

[torn river]

Well if it's a pie, it has some layers.

Unless we're baking only slices of cheese, one at a time.

Apt analogy, really.

Thanks, tertle.

(I wonder what a baking system is good for if that can't get access to the "ingredients", either)

[harsh mica]

you can get the ingredients in the baker

and pass them to the system

this is how physics and compounds and all that stuff works

[haughty wraith]

I find the restrictions annoying too and I think you should be able to make dependencies between bakers and use the results of one in another... Just a lot more flexibility generally.
But I completely agree with tertle that the less you fight it the better you will be.
This might mean you bake components that spawn other entities at runtime, this might mean you lean heavily on the additional entities that bakers can make and own.
Sadly I don't think the restrictions are intuitive either, but trying to limit complex hacks will serve you better in the end