so, the only 2 ways to influence what’s happening in my events from the engine, right?
change a parameter
send a cue / keyoff
And every event can only have 1 cue, correct? (Because it says “A” on the button, i thought maybe there’s a way to get a “B” and a “C”)
Also, is there no way to tell the play cursor to go to a specific marker on my timeline (i mean directly from the game, not from inside Fmod Editor)?
What i want to do:
have the play cursor rest at a sustain point
when my character bites, i want the play cursor to jump to the part in the timeline where i placed the bite sound
when my character gets hit, i want the play cursor to jump to the part in the timeline where i placed the aaargh!-sound
right now, i’m doing it by having a parameter called “bites” and another one called “hit”.
when my character bites, i set the parameter from 0 to 1 (that triggers a transition condition), and as soon as possible back to 0.
i find that not so elegant… or is that how everybody does it?
Before answering your question, I need to clarify a couple of things:
It might not seem like it, but the timeline is just another parameter. It’s a parameter with some special behaviour and extra options, but you can set it to a new value in code just like you would with any other parameter. Hardly anyone does, since there’s usually a more useful or convenient alternative way to achieve the same effect, but it’s always an option.
Second, a cue is an event, not a state. If you cue off an event, the timeline cursor will go past the next (or current) sustain point it encounters, but stop as soon as it hits another one, even if it’s the same one it just left. (We do have a plan to let you add ‘B,’ ‘C’ and even ‘Z’ cues to an event, but we ended up delaying it in order to work on other features.)
With that out of the way, the most common way to make an event jump to specific timeline values is to use the logic track: By assigning parameter conditions to transition markers and loop regions, you can use them in pace of sustain points or cause them to act in response to specific game events.
I’m not sure whether this is the best method for you, as it sounds like you’re trying to achieve something unusual. Most users put their ‘bite’ and ‘gets hit’ sounds in separate events rather than putting them both in one - and if they do put them in one event, they usually put them on game parameters rather than on the timeline. Presumably your project has some special requirements that make those methods undesirable, but without knowing those requirements I can’t judge whether an approach is better or worse than any other.
Here’s why i didn’t put my sounds in seperate events:
At the sustain point i mentioned, i have a continuously gargling sound. This is what my zombie sounds like while he isn’t doing anything else (like biting).
When the zombie bites, i want the gargling sound to stop, and continue as soon as the bite sound has come to an end (it is not a continuous series of bites on a loop, but a single bite that should get called once everytime the zombie bites). At the moment, i’m getting the gargling to ‘stop’ by pushing the volume of the gargling down with a sidechain. I see no other way, because my bite sounds are audio files of varying length contained in a multisound, so there’s no knowing how long the gargling should be silent for. (I wish there was a logic condition “when sound x has ended”)
Unfortunately, we don’t currently have a “key off on silence” option for sustain points and loop regions, so while I could suggest a number of alternatives, I can’t really say that any of them are objectively better than your current solution. (That said, my personal choice would be to create a transition region to a logic point, and to place multiple transition markers back to the gargling at that point - then create a transition timeline for each marker, and place a different bite variant in each. By assigning probability-based conditions to each of the transitions, I could then tweak the probability of any particular bit variant playing.) Incidentally, we don’t get notified when you post an answer to an existing question, but we do when you post a comment on an answer we wrote, so comments are generally a better way to ask follow-up questions.