Steps:
Expected result:
The whole player appears/disappears
Unexpected result:
If a player has multiple SkinnedMeshRenderers, only the first one gets affected (the pants on my female char in this case, lol). (I know using a model with separated parts is bad practice, but it's not unusual).
Also, if the player has any attachments, they won't disappear.
If it doesn't have any SkinnedMeshRenderer, it won't do anything at all.
Suggested workaround:
When creating the player with the wizard (or by pressing a nearby button), the Player component exposes a full list of the found renderers in the player hierarchy, for further refinement (some props could be there, but hidden).
Player Show/Hide could affect that list only, giving the user full control and customization without much refactoring.
Alternative solution:
A single popup labelled "Aspect" field appears in the Player component.
It lets the user choose from "Single Skinned Mesh", "Single Mesh", Custom
Choosing custom, a second line appears, and it's a list of Renderer, as suggested above.
This would also allow an action to be created, to be used in ActionLists (instead of using workarounds).
Quick ugly&dirty fix:
public void Hide () { foreach (var r in GetComponentsInChildren<Renderer>(true)) r.enabled = false; }
Alternative solution:
Make Hide and Show method as public virtual void, and let the user use inheritance to override them and customise the behaviour.
It looks like you're new here. If you want to get involved, click one of these buttons!
Comments
Or,
AC "design friendly" solution (so that is in line to other similar scenarios):
Player has a "Appearance" field with 2 popup options:
This time, setting it to custom, the inspector exposes 2 more fields
When a Show() method is called, if the Appearance is set to Custom that message gets sent with a parameter as true
On Hide(), the same message gets sent, with a value of false.
The user will have to implement his way to show and hide the player, giving him maximum customisation.
Nothing should break this way, and, I guess it's the fastest way to make it possible without refactoring.
I agree that the default Hide/Show functions should affect all found SMRs in the Hierarchy.
However, since these functions are the only reference the script makes to any SMR - and since they're called via custom script - having user-set options to control what happens is too much, I feel. I shall, however, virtualise them so that you can implement whatever custom method suits you.
Thanks!
I'd really appreciate that