Fast firing weapon problems

Variable rate can also be achieved on the timeline. If you raise the event master pitch (from the event macros), the timeline runs faster. If you then pitch down the multi-sounds in the timeline by the same amount (ie, you have a linear pitch-up envelope in master pitch, and a linear pitch-down envelope of the same amount in the multi-sounds) you have variable trigger rate. This can be helpful sometimes if you want to sequence multiple layers of sounds (like gun shots, slaps and mechanics) on a timeline.

2 Likes

Another thread on variable / dynamic fire rate:

1 Like

Ok, still having problems. I updated FMOD and the scatterer instrument works now. If I create a sustain point and press “KeyOff”, everything stops as intended.

The problem is how to implement this in game. What code should you write to call the key off?
Currently we are doing this:

EventInstance.triggerCue();

But this results in the weapon only playing the firing sound every 3rd time or so, when I actually press the fire button. The audio only plays now and then when pressing the fire button.

Thanks

I don’t know how to correctly implement the keyoff in Unity or with the API. However, there’s a nice workaround: condition the trigger point to “event stopped” (I will assume you have a recent enough FMOD version). That way, you’ll only need to stop the event to have the sustain point triggered.

Ah, like this?
image

If I make the event stat “Stopping”, then it doesn scatter correctly. It only plays the sound once and does not scatter.

But the above picture setting, seems to work, at least in fmod. Will have to ask programmer to revert to stopping the old way before i can test

Thanks man!:slight_smile:

Yes, “not stopping”, that’s what I meant :slight_smile:

Cool. Will test:)

Ok, seems to work. I do get some delay sometimes though, when i press down the firing button for a long time, and release the button, the firing sound stays on for maybe 0.5 sec or so. But this might be a programming thing and not something with fmod.
But thanks:)

1 Like

I remember some delay issues have been reported when using the event stopping state. It was advised to change a setting in fmod initialization. It this persists, it may be preferable to implement the keyoff.

Ok, could anyone tell me how to do proper key off in code? Need to pass that info on to the programmer.
thanks:)

Information on how to key off a sustain point from code can be found in our documentation.

1 Like

Usually I put a jump marker after every bullet and it works great

If you can find and match the exact BPM of the firing loop, you can use a transition region with the “transition on beat” option. Though … if it’s a very fast firing gun, the BPM setting may not accommodate that. Anyway, that’s one way to avoid having to add a transition marker to every shot in the loop.

Great solutions Bubbleboi and Skaven. Thanks

1 Like

@Alcibiade @trjaudio

(edit: solved those issues, solution in post under this one)

Hello guys!
I’m using this scatterer approach in the event.
The weapon can receive a power up, and I’m having “boosted layer” with scatterer for that.
I am using a Parameter and trigger conditions, so the boosted layer scatterer plays when the parameter is telling it “hey, the weapon is boosted, play that scatterer!”

1. The problem is, when the playhead is already on the sustain point, instrument Triggering Conditions don’t react to this (so when a person is shooting and during that shooting receives a boost, or the boost wears out while shooting).

So when the parameter goes up to 1(boosted) from 0(non-boosted), Scatterer doesn’t play.
When the parameter goes to 0 (non-boosted) from 1(boosted), Scatterer keeps on playing.

Do you have any ideas on how to make the scatterer react?
I thought it might be a Sustain point stuff. So I created a test event with a loop and it seems Scatterer won’t check the conditions again once it’s running.

2. If it’s impossible to set it up correctly to have it working like described above (scatterer turns on/off on the run, based on parameter conditions), I can only think about running the Scatterer always and automating volume with the parameter, but that will probably be messy with either cutting the tails or tails popping up (when you fired the last shot but the event in those last moments got a parameter update to the boosted state).

I just tried testing a workaround to this tail problem:

  • having transients as scatterer, volume based on parameter
  • having tail as multi instrument, on the right of sustain point

But… the tail multi instrument seems to ignore the changes in the parameter made during sustain!
When I start the event with parameter set to 0 (non boosted), tail doesnt play when releasing the sustain point. :white_check_mark:
When I start the event with parameter set to 1 (boosted), it plays when releasing the sustain point. :white_check_mark:
When I start with 0 and before releasing it changes to 1, tail wont play! :interrobang:
When I start with 1 and before releasing it changes to 0, tail plays! :interrobang:

@joseph If scatterer behavior described in 1. isn’t actually a bug, I think the second thing is. Could you confirm it, or am I getting something wrong?

Maybe I’ll leave the above so the people with similar problem might find the solution.

I just tested automating the volume of scatterer with Parameter. It didnt work and that was too weird.

All issues described by me above were caused by Hold value during playback. in the parameter.
I’ve set it like this to prevent the parameter from stealing the tails in more one-shot weapons, but I think it still doesnt make much sense when the instances are separate. Now I understand it more :slight_smile:

@TomassoAlbinoni, I’m glad to hear you were able to get the behavior you wanted.

When you say “the instances are separate,” what do you mean?

“Hold value during playback” is designed for use with event instruments, as a way of allowing the parameter’s value to be set when a new instance of a referenced event is first spawned, without subsequent changes to the parameter’s value in the parent event instance propagating to the child event instance. It is rarely useful in event instances not spawned by event instruments.

I’m not sure what you mean by “preventing the parameter from stealing the tails in more one-shot weapons.”

For some reason I thought if I play instance A with given parameter value, the next instance B that spawns with it’s own value, is going to override A’s value.

That only happens if it’s a global parameter, since each global preset parameter has one value that’s shared globally by all event instances. If it’s a local parameter, then each event instance can have its own parameter value.