Having custom presentation rules applied to an entity will affect the entire child entities tree that is attached to the entity with the presentation rules. This is expected, but the lack of control down the scene tree makes it inflexible, and can cause lots of confusion on different scenarios, source of bugs and hard to debug possible user-errors during development.
- Currently, if we set a new presentation rule on a child entity, we can’t “revert” the decision of the parent on that specific subtree part. To allow more use cases and flexibility, this feature idea proposes changing how the component works by the following:
- An Entity that has presentation_component, it will propagate its rules to all child entities that has no presentation_component on it
- Child Entities without presentation_component will inherit the presentation rules from the parent entity (like described above).
- Adding a presentation_component to any child entity on the hierarchy will make it override the previous inherited presentation_component rules (and also propagating this overriden rules down to their childs)
- Other behaviors keep the same as it currently is:
-presentable tofalse(empty optional) = everyone can see it
-presentable toarray{}(empty array) = nobody can see it
-presentable toarray{PlayerA, PlayerB}(custom list) = only specific players can see it
EXTRA:
The current way how presentation works are only with extension methods on entities, and they are not fully exposed as their actual components for us…
I would love to have both alternatives, specially to make easier to check the components list to being able to find/cast them, and using the way we think fits better for us on our projects.
For comparison, the transform_component also has the entity extension methods, but this does not prevent us from accessing the component directly for more specific and/or different usages of it.