koobas.hobune.stream
(Unity 4.6) Using Buttons with both Sprite Swap and Animation transition
Is there a way for Buttons in uGUI (Unity 4.6) to have a transition that uses both Sprite Swap and Animation?
We have a generic animator for all buttons in our game, which scales and tints them all in the same way, depending on state (pressed, highlighted, etc). We use the "Animation" transition (and this animator) in all of them.
However, we also want buttons to have a different Sprite for the pressed/disabled/highlighted states, but if we set the transition to "Sprite Swap" we lose the ability to use our animator.
Creating a new animator for each button is out of the question. Is there a native way to do this? We could create a script that detects OnPointerDown/OnPointerUp for the pressed state, but that would leave out the disabled and highlighted states (the latter of which is used both via hovering and keyboard-selecting, I believe).
We are using Unity 4.6.0b21.
Update: I proposed the feature in Unity Feedback, here. For anybody reading this, vote if you're interested. Thanks.
Update 2: I added code for a custom class to do this in my related Unity forum post. It's far from perfect, so I'm waiting for someone else to come up with a better solution. That is the reason I have not accepted any answer yet, or posted my solution as one.
So if I understand you correctly then you have generic buttons but each button has unique sprites you want to swap to?
Every button in the game must scale and tint in the same way on press, hover, etc, which is why we have only one generic animator and use the "Animation" transition. However, despite having the same animation, each button has potentially different sprites in each state (which is exactly what the Sprite Swap transition allows). The buttons themselves are not generic, but their animated transitions are.
Random thought: Can you add another button component and have one using spriteswap and the other animation? I'm not sure if this is allowed and can't check right now.
How about writing your own button class? You could derive it from selectable or button. This shouldn't be much work.
If there is no other simple solution to this you should propose this feature for a future update. Other people might also want this.
Add another script to your button prefab to change the sprite for you. Then have your generic animation use animationevents to tell this script when to update the sprite. This is why I love the component model -- you can usually get around a problem by adding a small script.
I confess that I didn't think of using AnimationEvents for this, and it's a nice idea :) The problem with this is that if I add AnimationEvents to my generic animations (to call methods OnHighlighted, OnPressed, etc, on a custom script named ImageSpriteSwapper), I'm REQUIRED to have ImageSpriteSwapper on every button that has the generic animations, or else my console is filled with errors because the events have no receiver. This creates an undesired dependency, as we have buttons where we want the generic animations to play, but no sprite swaps to happen. Currently, I think this can only be achieved with a custom button component, as suggested before, but I might be wrong. Sure, we can add ImageSpriteSwapper to every button and define the sprites as null where needed, but that would be an ugly solution, I think... It should be modular :)
By the way, I noticed you gave the answer 3 days ago, but Unity Answers did not notify me in any way (I have the relevant notifications on, though), so I'm sorry for the delay. I noticed the answer almost by accident, and it's not the first time.
I figured that since the button was a prefab then adding a script to the prefab would be no trouble.
No, the button is not a prefab. Actually, the only thing they all have in common is their animator. Then they can have sprite swaps if needed (most of them do). We could add a script to every one of them by hand; the problem is just that if no sprite swaps are needed, the script wouldn't be used, which adds unnecessary components. Until we have the time to create and test a custom button component, your answer is still a good (the best?) approach, hence why I gave you a +1.
