Character Switching and assigning child object via action-lists: Incompatible?
In my (2D) game I have a number of lifts that work by childing the lift graphic to an empty game object on the player and then moving them both a long a path. In order to make this work, the scenes that feature a lift have the player prefab dropped into them, so the actionlist on the lift can get the lift-placement object from them and assign it a child.
Also (not yet) in my game, we'd like the user to be able to choose between two different voice actors for the main character, and I was planning on doing this via character switching (the user chooses their preferred voice at the start of the game, and this is the only switch that takes place) and the "player lines have separate audio for each player" option described in the manual.
It seems though, that one of these solutions precludes the other - the manual suggests that I have to go with using one system or the other:
NOTE: The use of local Players (i.e. those saved in the scene file) are disallowed when player-switching is enabled. If you need to rely on different Player objects throughout your game, use one one method or the other
If this is the case, does anyone have alternative suggestions for either of the functions above?
Thanks all!
-M-
Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Comments
So long as your two different Player prefabs aren't in the scene at the same time, you can still parent the lift via Constant ID reference.
Add the empty GameObject that was on your scene-based Player to both of your Player prefabs, and attach a Constant ID component to it. Check Retain in prefab?, and change the Set field to Automatic, and make sure that this number is shared by both Player prefabs - so that the object you want to parent to always has the same number, no matter which Player is present.
You can then assign this empty (from one of the prefabs) into the Object: Teleport Action. You should find that it displays the Constant ID of it. At runtime, the Action will rely on the local instance of this ID - and so parent it to whichever Player is being controlled.