So, apparently one should avoid using a Canvas as a prefab root

I got that issue as well with having a Ghost “Canvas (Environment)” as the prefab’s root, and Unity being stubborn about showing the DamageText text field’s content.

So eventually I created a new Prefab with an Empty GameObject as its root, dragged my existing prefab into it and dissolved it.

Prefab Hierarchy:

GameObject - (Empty root)
    Canvas
        Text

Now the issue was that the DamageText tag was placed on the Canvas and not the top which made the DamageTextSpawner reject it, so I added the script to the prefab’s root as well.

Which leads to the issue that the Animation being on the Canvas, we need to have two copies of the DamageText component, one on the Root as a tag for the whole prefab, to make the Spawner happy, and one on the Canvas in order to fire the DestroyText() as a callback for the animation event…

Now I’m thinking, since the animation combines properties from the Canvas(group) for the fading, and the Text for the floating and upscaling anyway, wouldn’t it be much more sensible to put it on the prefab’s root to start with, and being able to get rid of the double DamageText script instances and the roundabout way to drag the prefab root on the ‘Canvas`’ instance of it?

I can see already that there will be more logic on the DamageText component to handle the damageAmount, and it can only get more complicated and confusing to have two instances of it one of which only serves as a marker for the prefab so it can be placed on the spawner…

Or be in the open with it and split the component into just the DamageText tag and a DamageTextLogic that would sit on the canvas. (In this case the DestroyText() could easily anf safely reach out to GetComponentInParent<DamageText>() if one wanted to put that bit into script logic instead of assigning it via the inspector, too…

Privacy & Terms