Should faston.wav replace out.wav?

Currently, faston.wav is played in addition to out.wav.
What are we gaining here, as in what practical sound would we use for faston if it’s only going to be mixed with out.wav anyway?
I’ve been playing with adding something like if (SFX_faston) SFX_out.Select(null);or SFX_out.Select(9999) in an attempt to have it skip out.wav, but no luck.

Since “fast on” is working it’s way into the base prop, we might want to add the sound effect for it in hybrid_font instead of a specific prop.

Now, I’m not sure how often people use “faston”, but if we change how it behaves it might break stuff for some people, so maybe we should make a “fastout” or something instead, and if that one exists, we’ll only play that one?

This I get and makes sense to me.

This part I don’t follow. Not breaking anything of course is a given. It certainly should be a “use if it exists, else just use out.wav” case so that things still act as normal when there’s no faston.wavs.
I don’t feel another sound like “fastout” which would serve the same purpose (?) is needed to be added, when “faston” in itself has, like you said, barely caught on at the moment (meaning most font creators don’t include it).

I just don’t see the point in having both faston and out play as it does currently. Please enlighten me if I’m just missing something.

The use case I can give as an example comes from when I was playing around (too deeply) with having specific out.wavs play for a certain scenario as follows:

Dooku font.
Preon.wav says “It is obvious that this contest cannot be decided by our knowledge of The Force…”
Out.wav plays ignition sound but has dialogue mixed in saying the rest " but by our skills with a lightsaber."

These and other preon and out wavs are paired via the font config.ini, so they always work together and it sounds perfect.
However, if doing a FastOn(), there’s a random chance that that out.wav gets played and sounds silly.
It would make sense if there were plain, non-dialogue infused ignition sounds (with a haste to them as a swing-to-ignite FastOn might imply) and these could just be the faston.wavs that play instead of out.wavs.

But is that how it works now?

That’s not what I said.
I said that I don’t know how much it is used.
If it’s very rarely used, then changing the behavior may be ok.

This is besides the point. I agree that it makes more sense for faston to work as you suggest, but that’s not a good enough reason to break existing behavior if we can easily make the change in a backwards-compatible way.

Ultimately we’ll need @Fett263 to weigh in as well, since he wrote it, and changing it means making changes to how his prop works.

It is not. They play concurrently.

Sorry, I didn’t mean to misquote you. I meant to simply say that at the moment, it is not a “standard” sound that is included in most fonts.

I agree wholeheartedly that backward compatibility is important. Not looking to break anything at all, but that’s the point of the original question is to ask if it’s currently behaving as intended . @Fett263 ?

Well lit turns out this is easy enough to just do in the prop with something like:

  void FastOn() {
    if (SFX_faston) SFX_out.Select(-2);
      SaberBase::DoEffect(EFFECT_FAST_ON, 0);

The magic was using -2 as an out of range selection.
I don’t know why it doesn’t want to be override though. That gives an error.

Did you make it virtual in prop_base.h ?

Ah. duh. . Now I did, and override is good, thanks.
It’s late.
Anyway, This works for me fine enough, case closed.

Still curious what Fett263 says about current behavior though.

faston.wav is a bit of a “relic”, it’s from OS5’s initial rollout of gesture ignitions as a way to have a different ignition sound but @profezzorn didn’t want it in hybrid_font.h at the time so it was originally only added in my prop but as it was adopted in other props with gestures it’s propagated everywhere. As a result it does play with out.wav instead of in place of it.
If we move it into hybrid_font so that it can be properly handled as a separate sound, with a fallthrough to out.wav if missing, then I think it’s fine to change. I haven’t actually seen it used by many font makers so I don’t think it’s widely used.
We should probably add the same support for EFFECT_FAST_OFF as well to be consistent.

Just saw this: If this works, then that’s probably fine to keep as well. Once it gets tested out I can add to my prop to keep consistent unless it’s ultimately moved to hybrid_font.

As noted I don’t think it’s actually ever made it into wide use, probably because it played over out.wav, so changing shouldn’t really impact compatibility.

1 Like

It does work, but I’m waiting for review on a PR as I’m pretty sure calling a wav file that’s out of range using -2 is not the best way, as it makes “File out.wav not found” happen.

I think we probably want to handle in hybrid_font then, since all the props adopted it with gestures, except the default, it is probably better handled there anyway. Just need @profezzorn thoughts.

So, I think what we need here is simply a sound that is played instead of out.wav/poweron.wav IF there was no SB_Preon call.

we also have an EFFECT_FAST_ON, but that normally happens after we’ve already started playing out.wav/poweron.wav.

I still think it makes sense to call this sound fastout since it’s an alternative to out.

Seems fairly straightforward to implement, and will require no prop changes. Then we can add a define around the faston sound, which defaults to off, add a a #warning that tells people that this feature will eventually be removed unless people who use it speak up.

EFFECT_FAST_ON is used a few ways depending on the style in my prop, we can change the sounds without issue but we can’t change how the EFFECT actually works, as this would break various things in the library.

I tried playing it in SB_Effect case EFFECT_FAST_ON already, it does indeed still play out.
Since it seems the general consensus is that “faston” isn’t heavily used so far, going with fastout instead is just a matter of replace-all in props that use it. (And then any existing fonts one may have it in) and then nothing gets broken, right?

The more I think about it we probably need a little planning and consideration as there’s parts of the current behavior I wouldn’t change but parts that may need additional attention even if we just change the sound behavior/name because the EFFECT is used for specific things and I don’t want to break or lose compatibility.

EFFECT_FAST_ON is used when we skip preon, that’s the “FAST” part, the effect was intended to give the option for a special effect to be applied if a user wanted. We still get EFFECT_IGNITION triggered.

It’s really just the sound faston.wav (or fastout.wav) that is ok to change, I don’t want to rework anything with the actual EFFECT_FAST_ON beyond not playing out.wav if fastout.wav exists and we trigger EFFECT_FAST_ON. There are several uses and effects in the library that use (and will use EFFECT_FAST_ON).

Here’s how I believe the sound should be handled.
If EFFECT_FAST_ON is triggered -and- SFX_fastout exists, play fastout.wav and don’t play out.wav.
Any other ignition scenario should just use out.wav.

Now, for effects it gets a little tricky, EFFECT_IGNITION triggers in all instances which is fine and expected but many ignition effects can/do use WavLen<EFFECT_IGNITION> so we need may need a way to handle timing to EFFECT_FAST_ON. Since it’s OS8 I can probably handle in the style, but if there’s a way to handle for backwards compatibility we may want to consider. It may also make sense to look at handling On() and FastOn() as well as Off() and FastOff() in a way that works with InOutTrL<> to allow separate transitions for each. I can probably handle via TrSelect<> in styles but to simplify for users building their own it might be something we handle in the template as well.

Yes, this is all I was suggesting with the original post.
Just suppressing out.wav if faston (fastout) is played .

Yeah, the problem comes with WavLen<> in an ignition effect though, if we don’t use the EFFECT_IGNITION sound out.wav you may break ignition effects that rely on the wav file, so we need to consider.

Doesn’t WavLen<> just listen to the current effect sound playing though?

It should use the effect that triggered when in a Transition, I believe, which for InOutTrL would be EFFECT_IGNITION, correct @profezzorn?

I made a very simple implementation, which I think is what we want:

The only drawback I can think of is that you may need to use WavLen<EFFECT_IGNITION> instead of Wavlen<> in EFFECT_FAST_ON. But this kind of makes sense anyways, otherwise you get the length of the “faston.wav” sound.

Since EFFECT_FAST_ON happens after EFFECT_IGNITION, WavLen<EFFECT_IGNITION> should always work. (I think)