Delayed blaster blocks

Is it possible to have a random delay between blaster samples and the block animation on the blade? In fact, would it make more sense to have two parts to the blaster deflect, with the actual blaster sound played on event trigger, and the block itself a randomised (but controlled) delay after?

My two cents on this.
Iā€™m not sure random is really what you would want. In theory if it were a real thing happening, you would very much be aware of the time that youā€™re blocking the blast. Like hitting a baseball. Itā€™s not a random event. If it were randomized, you might angle the blade and then be sitting there for a minute waiting for something to happen finally the blast plays. Also, if the same guy was shooting at you the distance between you is likely not changing enough to be a different delay amount. Even if it were a different guy from closer or further away from guy number one, itā€™s a laser and the time again would not be significant noticeable.
A simple delay is pretty easy, just have your audio be a blaster shot followed by a delayed deflection sound, and make your blast animation on the blade with TrDelay.
The delay would need to be consistent across all the blst.wav files.

Yeah, perhaps I could be clearer and say ā€˜random within parametersā€™? So basically, when you ddo one block, it picks a random time within say 100ms and 500ms, then if you continue to block, it sticks to within 50ms of the first delay?

What ā€œsoundā€ are you meaning, the sound of the actual blaster firing or the sound of the bolt impacting the blade? Seeing as the sounds youā€™re referring to are emanating from the saber I always took the sound as the bolt impacting the blade, the blaster should be making itā€™s own sound externally from the blade. You can delay effects as noted with TrDelay but why would a saber make the sound of the shot being fired?

So in pseudo code it would be something like this:

if blaster block,
pick random delay between 100ms and 500ms
[200ms]

Trigger blaster block
play blaster sound
delay 200ms
play deflect sound

trigger blaster block 2
play blaster sound
delay 200ms [+/-50ms]
play deflect sound

etc

Well, lightsabers donā€™t play music or make force sounds either. Having two different blaster sound parts and some delay would mean more immersion?

I mean if youā€™re being ā€œtechnicalā€ Force sounds do emanate from the saber wielder, so source of the sound is accurate by proximity, and in Meta terms your ā€œtheme songā€ would also emanate from your general proximity. Unless the person firing the blaster was right next to you the ā€œsourceā€ of the sound would most certainly be different than the deflection sound. To me it breaks immersion when I hear fonts with both sounds but to each his own.

You wouldnā€™t be able to use Multi-Blast if you built a delay, it would cause your movement and deflections to be out of synch.

Also, technically blaster bolts are light energy and light is faster than sound so the blast effect should technically appear before or at the same time as the sound from the blaster depending on how far the blast came from.

But you could certainly code it if itā€™s what you wanted, thatā€™s the beauty of ProffieOS.

CFX sound boards do this. They have the parameters in their font config file, where you can set the delay of the ā€œvisual sparkā€ on the blade, yet the blaster sound file plays immediately. So when you hit the aux button to do a blaster block effectā€¦the sound is played, but the actual deflect spark on the blade is delayed by a set number of milliseconds of your choice based on what you put in the font config file. Its quite awesome actually and pretty realistic IMO. Mostly because a blaster blocks wav sound consists of 2 sounds layered together, the initial blaster gun sound, followed by the saber deflect soundā€¦and these 2 sounds layered together generally shouldnā€™t happen right on top of each other (unless of course this was a close range shot)ā€¦but there is a slight delay between them depending on how far away back the gunman is whos doing the shooting.

When making blaster block wav sounds and layering, i tend to like to have the deflect sound delayed about 200-250ms after the gun shotā€¦and it works really well for CFX boards because you can then set the visual deflect display on the blade in the font config to delay the visual deflect spark by (200-250ms) to match the wav file correctly.

I agree, i think this would be great to have for proffie boards.

To me, the block is the effect of the blast hitting the blade.
The majority of blst.wavs are one shot sounds, unless itā€™s a LINK font, or, if the sounds are built like you do, then setting a delay on the blade effect is a piece of cake.
Thatā€™s the beauty of open source. Make it yours.
The randomness would need to be coded if someone wants something like that.

Seems like a job for TrConcat<TrDelay<250>, ... > to me.
There are a few different ways to make the 250 random.
Do we need anything more complicated than that?

WAY back In dec 2018, I tried delayed blaster blocks for my multi-blaster code, and decided that rebound kills sound better. So I set up a system where there can be 3 things happening when blaster block. Soon after demoing that, Plecter Labs set up their own alike version based on tables of delays (donā€™t like it).

many things can happen (this is not pseudo-code, this is what transpires as a result of some MUCH simpler code)

  • trooper fires, and you miss due to not swinging so many deg at whatever speed, jedi pain sound
  • trooper fires, you block as quick as you can, and a random delay for rebound is heard
  • trooper fires, you block, random delay for rebound, then maybe another rebound
  • trooper fires, you block, random delays for 1 or 2 rebounds, then trooper death sound
  • trooper fires, you block, instant trooper death sound
  • trooper files, you block, no trooper death sound

Here is a quick demo (that I just filmed quick) of the ancient version of this (prototype 3 font) on my old v1.5 in the VV fury. I think that ProffieOS repo version was 1.315, and ultra was v1 nightly.

I tried to keep the code tight by only deciding if the block happened, (if rebounds and maybe death with be played at all, instead of jedi pain sound) and how many files with random leading delays should be played. the death sound is random on that version.

Anyhow just in case you guys want to hear how it sounds in action, to see if you want to go to that trouble. A new version will be in my releases after ProffieOS v6 is out so you can wait and see then if you want. Enjoy.

Not sure if the video will play just like that, you might have to cut/paste the link. Hope it helps somehow to hear it ahead of trying to code it or whatever. I know its old code (3 years old) but you can code that yourself anyhow, just a preview of how cool it can sound in action.

P.S. mortal kombat x pain sounds lol

1 Like

BTW, this involved making files for the font:

  • blaster bolt firing sounds (some quieter to impart distance)
  • saber blocking blaster bolt sounds
  • blaster bolt deflection A sounds
  • blaster bolt deflection B sounds (some with trooper pain)
  • jedi pain sounds

blaster bolt A and B sounds were played at once but they have different lead silence lengths. sometimes B had pain sounds.

jedi pain sounds have a small delay and are played immediately if the block did not happen.

so very little actual code to get these results, a lot was in the font design. with newer versions of proffieOS and v3, the maximum number of wav files that can play will be much higher and this will be a no brainer since many other complex proffie effects wont ever happen while you are blaster blocking.

Iā€™ll release this again when ProffieOS v6 is where it needs to be first. <3

1 Like

This is cool sounding, but its is really up to the font makers to make the wav files to include these extra nuances of rebounds, death noises, etc. I donā€™t know if any proffie coding is really needed for this kinda thing.

like if font makers didnt include these extra little nuance sounds in their bslt.wav filesā€¦all that proffie code would be for nothing.

Unless Iā€™m missing the point and dont fully understand?

I want to be cautious with adding features that require a lot more sounds to play. We have a large V2 board install base, and when possible I want to make features that they can enjoy too. Not saying we shouldnā€™t add features that play more sounds, just that we need to carefully consider how we implement new features.

2 Likes

EXACTLY and this is why it stayed in my fork originally, and probably stay there indefinitely. :slight_smile: we both agreed on this back then as well, and I never made those pull requests for that reason. I suggest it stays that way, Iā€™ll take care of all that stuff as I did before and push the envelope in a safe container as before. That way I can work faster like I did before :slight_smile:

Iā€™m just waiting for v6 to drop officially as something people will get, so I can release a lot of what Iā€™ve been working on the last 2 years (interactive gaming etc). Exciting!

You guys are all doing such amazing work, and Proff is on track as always!

Honestly just a common folder with default sounds could work.

I suggest if you have an idea, to get your hands dirty and actually try to achieve the result you are looking for yourself!

Not only is it fun and rewarding, even if you are off or it doesnā€™t sound good in the end, at least you will have moved beyond the realm of ā€œopinionā€ and into ā€œbeen there, done thatā€.

You could do like Plecter, and try to approximate results that others achieve with your own methods, or try to replicate what otherā€™s create to understand how they did it better.

Good luck! I know seeing things like this done over the years has influenced so many people in so many ways, so I keep going. We have so much new things now as a result and its just fantastic!

So keep up with the good ideas and opinions, and if you can, try your hand at coding some of them yourself so you can see how much coding is required to get the results you want.

Rock on!

cfx and verso have blaster sound, then delay, and blade impact. Its cool, but speed of light within blaster range wouldnt create that drastic of a delay. Speed of sound? Maybe, butā€¦I like proffie blaster the way it is.

1 Like

Star wars blaster bolts travel at a brisk walking pace I think.

2 Likes

I really enjoy how they kind-of slow down the speed of the blaster bolts in the Star Wars Vader Immortal VR dojo games, slowed down so you can reasonably block them with your lightsaber. Thereā€™s no question it would travel at the speed of light, and those are travelling super slower than even the speed of a brisk walking pace like Proff says, but boy is it fun to block them in-game! :slight_smile:

1 Like