ProffieOS 7.7 Beta (done)

Taking this to here:

1 Like

yay, this was needed!!! The stock fonts are all awesome, but all needed some updating! Thanks BC!

Ok. Preface: This does not really matter much.
But it would be cool to know whether this is supposed to work and it is not,
or if it’s NOT supposed to work so don’t worry about it…
Not worrying about it is fine, and it just means to be complete and not omit stuff as shorthand.

This was the same issue back in these posts:
WavLen<> Specified or not is weird
Prof knows maybe why

The issue is WavLen<> needing taking the EFFECT_XXX or not.
In the following test, it does NOT work without specifying the EFFECT. (in the style Editor this would show as EFFECT_NONE)


To work, it needs to be:


So the lesson learned I think without bothering with this too much is to just always provide the EFFECT and move on.
Unless it’s an actual under-the-hood thing that should be fixed?

So, obviously it would be nice if this worked.
I’m pretty certain the issue is that TrConcat gets in the way.
The link between TransitionEffectL and WavLen only exists for a single run() call, and TrConcat ends up calling run() on TrInstant when that happens, not the TrFadeX.
I think fixing it will have to be opportunistic, meaning that if I can figure out a better way, then I will fix it.

So yeah. Nice, but not necessary. Bigger fish to fry for sure. ok thanks.

but also just to note it’s not consistant.
The layer beneath for stab is working fine as just Wavlen<> ( here’s the not-simplified layer)


So I was taking a look at why this WavLen works but not the other one, and I realized that they really should both work. So now I’m investigating why the first one didn’t work instead…

Did some testing, and the layer seems to work for me…

Maybe something in context? because it’s Percentage?

This is where it was happening to me.

This is an effects layer pack I use, and it’s where the clash layer wasn’t working with just WavLen<>.
Mind you, the first part of the TrConcat DID show (the GreenYellow flash for 25ms), but none of the localized impact that follows worked.
Again, specifying the EFFECT_CLASH makes it work.

It’s most likely due to EFFECT_CLASH_UPDATE being last detected.

1 Like

Wonder if maybe there are quite a few EFFECT_CLASH_UPDATE events.
Blades only remember the last 7 events, so maybe the clash effect ends up getting forgotten.

No… that’s not it. EFFECT_CLASH_UPDATE isn’t stored in the blades effects_ array.

I tested the BC_effects_1, and it seems to work for me.
Unless I just magically fixed when I made WavLen an SVF somehow…

Ok. I’ve extensively tested this now, even with the new WavLen as SVF update, it’s not working 100%.

The issue seems to be something about using regular TransitionEffect<> as the effect COLOR inside the layer TransitionEffectL<>.

Here are my tests and results.

// this works (no nested TransitionEffect<>, no EFFECT specified)

// this works on its own not nested in a TransitionEffectL wrapper.

// This is not working: nesting the TransitionEffect<> as COLOR, still no EFFECT specified anywhere)

// This works when adding specified EFFECT only in TransitionEffectL wrapper.

// but not working with EFFECT specified in nested TransitionEffect<> only.

// This also works without 2nd WavLen in TransitionEffectL wrapper.

This makes sense I think.
TransitionEffect(L) doesn’t save the previous value of the found effect, so when it pops back out, the found effect becomes null. Should be relatively easy to fix.
I don’t think I ever imagined anybody putting a TransitionEffect inside a TransitionEffect…

I don’t know, I wrote it a long time ago, and the colors and shape are all omitted for this test/example, but I guess I wanted a concurrent 2 color transitioning impact and the fadeout.
I suppose a close enough version could be done straight in a TrConcat, such as:


But having things work just in case someone ever does do weird stuff is a good thing, right?

Having it work is always good, unless of course fixing it is more trouble than it’s worth.
In this case, I don’t think it is.

Does it work better now?

It does indeed!

Since we’re adding EFFECT_QUOTE to saber_base, would it make sense then to make it an official sound added to sound/effect.h?