ProffieOS v6.7 is now LIVE

It probably needs to be looked at and addressed, but that’s my guess looking at it.
Preon works as expected.

1 Like

Huh? If you use that define then the older presets.ini will override your new config, if it’s not then the new config is used if the .ini is older.

Sigh, that’s why I asked. The minute I plugged the SD back in and turned the board on it overwrote everything because I didn’t have it defined prior. Oh well, style rebuild time.

On a different subject, what is the % level that the lowbatt.wav will kick on in OS6? I’m seeing batteries going as low as 19% and it didn’t play. Even at 12% where the blade showed red I had nothing happen.

Guessing you didn’t read the page first then.

NOTE: It is strongly recommended you save a backup of all SD card contents (fonts and *.ini files) after making edits in case your SD card is erased or corrupted.

Something a little different that I’m having an issue with in that same config is my no-blade font, I just got my sabertrio and it’s the first one I’ve had with a blade detect pin. I have a font set up and everything was working perfectly, it auto-switched to that font when the blade was out, up until I’m guessing I changed something and my presets.ini was created? Because now when I remove the blade the font doesn’t change. The pin is still working because I hear bladein and bladeout (I put those in common) and motion ignite doesn’t work when the blade’s not in, so that’s all functioning properly. But it no longer auto-switches the font like it used to. I saw this comment from prof in another thread:

“If you don’t have SAVE_CURRENT_STATE in your config file, it will just go to the first preset in p2 when there the blade is removed. (Or if you boot up with no blade) If you insert the blade (or boot up with blade inserted) it will go to the first preset in p1.
If it saves the presets, things gets a little more complicated, but by specifying separate save dirs (“save” and “nbsave” above) it will keep the saved positions for separate for when there is no blade and when there is a blade, which will work better.”

So I’m guessing it might have something to do with the fact that I have #define SAVE_STATE and/or KEEP_SAVEFILES_WHEN_PROGRAMMING? I did a fresh upload and deleted curstate/global/presets and it was working I think up until I did color change and the presets was created? I also checked the link below and I’m really not sure where the issue is but maybe do I just need to switch SAVE_STATE for something else or something like that? Thanks again in advance for any help! Omen - Pastebin.com

1 Like

Exactly what I was looking for, can’t believe I didn’t find that, thanks so much!

1 Like

I read it, then while running tests this past week I ignored it because you need a fresh clean plate when testing a change or else you risk something that was saved tainting the result(s).

Both @NoSloppy and you’ve reminded me about that bit a year or so ago. :smiley: I just screwed up and forgot to remove the //'s when I got things working right and began building stuff out is all. Rookie mistake.

1 Like

If you saved a backup copy of your .ini files with the changes you just apply them to the new .ini files yo reinstate your edits.

So basically go ahead and copy out all the ini files, run the flash on the board and SD, then go in and remove the new ones and sub in the old ones which makes sense.

Thanks

1 Like

With the caveats covered in the article linked above.

1 Like

First of all: Wavlen is supposed to work with postoff, so if it doesn’t that is a bug and we need to fix it, not avoid it.

Second; I took at the Omen config file (named .cpp for some reason?) and I found one instance where Wavlen<EFFECT_POSTOFF> is used in a TransitionEffectL<...., EFFECT_RETRACTION> That won’t work since the length of the postoff isn’t known until it starts playing.

Maybe that’s what’s causing the problem here? If that’s not it (or not all of it) please let me know and I’ll check again.

I’ve added a save directory to the example on the blade detect wiki page.

1 Like

Thanks Prof. Just checked the Wiki. Only thing I have left to answer is does adding a new save directory for noblade only affect the Presets.ini for the noblade state?

It won’t overwrite my “with blade” state Presets.ini in the root directory, right?

1 Like

That is correct, it will not change your presets.ini in the root directory.

Each entry in the blades[] array can have it’s own save directory. If none is specified. then the root directory is used. Generally, entries that have the same presets can also share save directories.

1 Like

Thank you, Prof. This is helpful and “ties it all together”.

MTFBWY

Thanks, not sure why it’s .cpp, maybe that’s a pastebin thing? It’s definitely .h on my computer lol.

As for the retraction effect, maybe that’s why sometimes it doesn’t work and sometimes it does? Like if I retract 4 times and go through all 4 pstoffs, it should then know then length of each of the pstoffs, so then from that point on it works? Otherwise I’m not sure why it seems to randomly start working. It also looks like that’s how they’re handled in the os6 library as well, here’s a “pstoff” effect I pulled that’s actually a retraction effect, it waits for the in.wav to finish then uses the pstoff.wav in the middle of the EFFECT_RETRACTION, is that not the same thing?

TransitionEffectL<TrConcat<TrJoin<TrDelayX<RetractionTime<>>,TrInstant>,AlphaL<White,SmoothStep<IntArg<EMITTER_SIZE_ARG,2000>,Int<-4000>>>,TrFadeX<Mult<Scale<IsLessThan<WavLen<EFFECT_POSTOFF>,Int<200>>,WavLen<EFFECT_POSTOFF>,Int<4000>>,Int<10923>>>,AlphaL<Orange,SmoothStep<IntArg<EMITTER_SIZE_ARG,2000>,Int<-4000>>>,TrFadeX<Mult<Scale<IsLessThan<WavLen<EFFECT_POSTOFF>,Int<200>>,WavLen<EFFECT_POSTOFF>,Int<4000>>,Int<10923>>>,AlphaL<Red,SmoothStep<IntArg<EMITTER_SIZE_ARG,2000>,Int<-2000>>>,TrFadeX<Mult<Scale<IsLessThan<WavLen<EFFECT_POSTOFF>,Int<200>>,WavLen<EFFECT_POSTOFF>,Int<4000>>,Int<10923>>>>,EFFECT_RETRACTION>

I also used something similar for the lockup, if you look at that you’ll see I actually have 4 lockups, selected based on the endlock.wav. Each lockup has a different endlock effect, to match the endlock.wavs, and it works perfectly, so I guess somehow when bgnlock>lock starts, the saber already knows which endlock.wav will play? Because the effects match up perfectly. Maybe something similar is going on with the retraction/pstoff? (edit: to be fair, the endlock still uses ms and not wavlen)

I guess I could always split it up into two layers, the first half being an EFFECT_RETRACTION and the second half being an EFFECT_POSTOFF and then only reference the applicable wavs in each effect

I’m also wondering if in>pstoff is linked in the config.ini if it could use that to know what pstoff.wav will play? Sorry for the wall of text lol I’m just kind of going through all my thoughts on this

I think what will happen is that it will use the length of the last played pstoff sound. Also, the value can suddenly change in the middle if a new pstoff is played while the effect is running.

I think it will work if RetractionTime is greater than the length of the retraction sound.

Uhm, no. Not only does it not know which endlock sound it will play, but it also won’t copy the number to where the styles can read it until EFFECT_ENDLOCK occurs.

Yes, that should work better.

Yes, if they are linked, then you can use WavNum<EFFECT_RETRACTION> to know which pstoff will play. However, you can’t use WavLen the same way since it won’t know the length of the pstoff until it plays it.

2 Likes

Testing using #define PROFFIEOS_MOTION_FREQUENCY 800 and leaving my clash and volume alone for this. Nothing bad to report, so far it works and I see less False Clash but I want to test this some more and then retest elsewhere rather than jinxing things.

If anyone else still working against the issue could please test at the same time I would appreciate it. The single best font pack I found so far for repeatability is the Jedi Knight Dark Forces Free font. Set your board up for BATTLE_MODE and use repeated triggered clash if you don’t get an accidental clash. With quick repeated manually triggered clash if the issue exists the same will go into either a lockup or melt showing up. Don’t mess with your Clash or Volume thresholds until you see if the 800 define solves it first. This is where BATTLE_MODE will help because it will make anything false show as something easier to catch than a quick blip since it’s a held effect.

Ultimately please report back what your results are.

Thanks again for the reply, I still have a few questions though if you don’t mind:

So does this mean if I have a 4 second pstoff.wav and am using WavLen, and ignite/retract 3 times within 4 seconds, do they just stack and they just keep “resetting”? Or that if I have 2 pstoffs, one 6 seconds and one 3 seconds and I ignite/retract two times it auto-adjusts to the new one?

What do you mean by this? If we’re using WavLen, ReatractionTime should equal the length of the retraction sound, right? Unless you mean the EFFECT_RETRACTION layer, in which case mine uses a trigger for the effect to start once EFFECT_POSTOFF starts, so that whole retraction transition should always last the length of the retraction sound + pstoff sound.

Really not sure how my endlock selection is working then lol, but it does work. Here’s the code from that same config for specifically selecting the lockup based on endlock.wav. Each lockup effect has its own endlock to match whatever endlock.wav plays. It also works with bgnlock selection, so theoretically with bgnlock>lock paired in the config.ini, you could actually pair a lockup effect to a lock “state”, because it’s picking the whole lockup (begin, state, end) based on bgnlock. I’ve tested it out and not really sure what’s going on behind the scenes but it’s all working: