Search Unity

Resolved Companion Gameobjects, What's Next?

Discussion in 'DOTS Dev Blitz Day 2022 - Q&A' started by Kmsxkuse, Dec 8, 2022.

  1. Kmsxkuse

    Kmsxkuse

    Joined:
    Feb 15, 2019
    Posts:
    306
    Companion GOs at its present state is incredibly limited, only officially supporting a select amount of monobehaviors as hard-coded in a static class list. An internal method normally used for testing can be accessed to expand the list dynamically but is clearly not intended.

    What is the future of hybrid workflow and companion GameObjects? Why is CompanionLink even internal in the first place? Deleting the link from server worlds requires internal access which is very annoying.

    Edit: I just realized I asked this question twice. Well, this is more on the companion GO and my earlier question was on hybrid components...
     
  2. topher_r

    topher_r

    Unity Technologies

    Joined:
    Jun 14, 2019
    Posts:
    36
    There are no further plans with Companion Components. They just about work in a very narrow set of ways, and even those have a lot of special exceptions we had to write into the code to allow this. For server worlds, it's probably better to not have those Bakers run at all, which can be done with Baker assembly filtering with NetCode. This would stop your server version even getting them in the first place.
     
    Kmsxkuse likes this.
  3. Kmsxkuse

    Kmsxkuse

    Joined:
    Feb 15, 2019
    Posts:
    306
    If there's no plans moving forward with Companion GOs, what's going to happen to features that only exist in MB land and not yet replicated in DOTS (which was the second question that I duplicated).
     
  4. TheOtherMonarch

    TheOtherMonarch

    Joined:
    Jul 28, 2012
    Posts:
    866
    Honestly, just get rid of Companion Components.
     
  5. topher_r

    topher_r

    Unity Technologies

    Joined:
    Jun 14, 2019
    Posts:
    36
    I guess what you're specifically asking is- how do you use these GO-only features in DOTS?

    It's important to remember that the GameObject Scenes are still there, so things placed in them can be accessed at runtime. You can't easily drag and drop a binding to them due to current limitations, but it is straightforward to have them in a static class you can look up and reference things how you like at runtime.

    Another path is to use Prefabs, as Entity Scenes support Unity Assets. In this case you can keep a reference to a Prefab asset and at runtime spawn the game object, then do whatever you like with it from your Entities code.

    In the long run we don't want it to be this involved to work with both, but this is how it will work for 1.0.
     
    JohngUK and Kmsxkuse like this.
  6. Kmsxkuse

    Kmsxkuse

    Joined:
    Feb 15, 2019
    Posts:
    306
    Huh, interesting idea. I was hoping for a deeper integration of existing GO features, particularly sprite renderer, without the need for a IJobParallelTransform intermediary. If I could just feed the local to world 4x4 and call the Render() using direct data.