And i also can't have the same character "voicing" two things at the same time. It happens a lot, and it's random or based on gameplay triggers.Īnd i want to make sure they are not constantly canceling their randomly triggered dialogue for a new one cause it sounds unnatural. Ok so for example lets say i have a game where characters talk a lot, maybe grunt or do other things. And you can add as many of that component as you like if you need more.īut also keep in mind that your Code-Triggered Event can fire a Custom Event (EventSounds can do this), which can be listened to from same/other Event Sounds and do tons of other things as well. There's only 2 of them *per Event Sounds component*. But you could always use the ActivateCodeTriggeredEvent directly anyway. It requires a very precise trigger to be defined if you don't have one already (you said you don't). Users have used the Footstep scripts fine without any of this. #2, I'm really not sure what you're trying to do here. Then have an Event Sounds in a central location that listens to the custom event(s) and plays the sound(s). Attach Event Sounds instead of Footstep Sounds to each foot and fire a custom event from the Trigger. If you want a receiver, use Custom Events. Will add that so you can just click the magnifying glass next to the Sound Group to find all instances of it in the Scene, and can click on it to go directly to the game object, even if deep inside a 3d model. We're using for our character controller, so it massively simplifies our needs.Ĭlick to expand.#1, it appears that we neglected to include Footstep Sounds from the RelationsInspector Sound Group search functionality. So, our player object has a single collider - It's the capsule collider that you can see in the video, and it encompasses the entire model.
I ended up editing FootstepSounds.cs in order to add a very basic version of this functionality - it doesn't currently handle tag filtering for separate feet, but it fires the same "PlaySoundsIfMatch()" function used by OnCollisionEnter() and OnTriggerEnter(). Making the Footstep event publicly accessible means that it can be tightly connected to an animation, like in the image below:
The "Delay Sounds" slider can offset this to an extent, but a collision event isn't always predictable, so adjustments like this can only go so far.Īn "OnFootstepEvent()" function would go a long way in alleviating this issue. By relying on a collision event to trigger sounds, an element of control is removed from the ability to precisely time sounds. The Receiver could then have a list in the inspector that the user adds Broadcasters to, allowing all the important details to be controlled at the top-level of the gameobject.Ģ. One way this could be addressed: Give the current "Footstep Sounds" script the ability to become a "Receiver" that can sit at the root of a gameobject, and introduce a "Footstep Sounds Broadcaster" script that can sit on the required parts of the rig instead. You also have to make sure that your alterations are copied across each instance of the script. Two scripts for humanoid characters, four for some animals, even more if you're making a weird creature or machine. Attaching Footstep Sounds directly to a model's rig means that, if you need to add new sounds or tweak options, you have to dig around in the object's hierarchy to find all instances of the script. I have a couple issues with the intended setup, so I have some feedback:ġ.
We're using for our character controller, so it massively simplifies our needs. Click to expand.So, our player object has a single collider - It's the capsule collider that you can see in the video, and it encompasses the entire model.
0 kommentar(er)
