I am definitely seeing and increase in false clash occurance in OS6 compared to the same saber/config/font combo using OS5.9. I have tried OS6 on 3 different hilts and I see the difference on all 3.
Try increasing the clash threshold a bit.
Not sure how much, but it could be as much as 100%.
What if we have the “maximum” for Clash Threshold be a factor of MAX_CLASH (this it the highest value used in Clash Strength Sound for Real Clash, technically this gets used with SelectFloat so we can’t let Clash Threshold (which is the minimum value) be higher than Max Clash (which top value for calculation) or we’ll be trying to select a negative file number. So I’m thinking we do a fixed number less than Max Clash or a % of Max Clash as the menu’s “maximum” value. This way we prevent getting a negative value when calculate for the sound when using the menu. Thoughts?
Unless that factor is 1, it doesn’t really make any sense to me.
clash threshold should obviously not be greater than MAX_CLASH, but other than that I think it’s really hard to predict exactly what people will want.
Maybe just do:
#ifdef MAX_CLASH
#define CLASH_THRESHOLD_MAX min(MAX_CLASH, 16)
#else
#define CLASH_THRESHOLD_MAX 16
#endif
Ok, makes sense.
This should be fixed now, you’ll be able to increase Clash Threshold in Edit Mode Menu up to Max Clash level, although if Clash Threshold and Max Clash are too close in value the CLASH_STRENGTH_SOUND selection won’t work so well.
1 Like
I think it’s time to work out a criteria for going from ALPHA to BETA.
Basically, this means making a list of things that we want to get into OS 6.x before shipping it. The things that I’m aware of are:
- Update display code to be able to do bullet counts
- Add one-button mode to FETT263 prop
what else?
Once we go from alpha to beta, we should try to avoid adding more features if at all possible, from that point on, it’s all testing and bugfixes. All new features will go into ProffieOS 7.x after that.
1 Like
AIUI, Beta means “mostly” frozen API (only allowed if seriously bugged). Release Candidate is API and feature freeze and only regression and critical bugs allowed. So I guess you’d need to have those two and see which/if any feature request/bug you want to implement before you advance to Beta?
Isn’t that pretty much what I said?
I was really hoping for an idle image for the OLED. It’s close on my end, but USBD_Connected doesn’t seem to work still, so that means Mass Storage won’t kick in because SD is busy playing idle.bmp.
I also didn’t try with the latest update and new ShowDefault() function.
Summary of how I thought it could work:
- PLI displays until first ignition. Then idle image displays instead when blade is off.
- Font image shows as normal on preset change.
- PLI shows if USB connected AND Mass Storage is enabled so idle image stops, allowing SD card to mount to PC.
- Bonus - On-Demand battery level can call PLI to display for a few seconds.
I think we can add that to the list.
We either need to figure out why USBD_Connected() is flaky, or work around it.
So… a working Pulse Rifle ammo counter?
2 Likes
Sweet! I will test it out as soon as I can, probably later this week.
I’m hoping to finish some projects today that will allow me to jump on beta tests. I have been keeping up with the Alpha discussions. Great work all. Especially exciting to see newcomers like Max (afrojedi) jumping in to help on Alpha testing! Very exciting stuff.
Tom
2 Likes
can you update this in OP to below, there are now two options.
- FETT263_SAY_BATTERY_VOLTS
- FETT263_SAY_BATTERY_PERCENT
There are also these new additions:
- FETT263_QUOTE_PLAYER_START_ON
- FETT263_HOLD_BUTTON_OFF
- FETT263_HOLD_BUTTON_LOCKUP
Descriptions are in top of my current prop file. Addition of 1 Button Support to my prop (based on SA22C prop) in is final round of testing and will be added once it’s done.
1 Like
Done.
I also added the alpha exit criteria list to the top post where it can be found and edited easily.
1 Like
That is exactly what that means! 
1 Like
I have a recreatable anomaly, but tough to explain.
This looks like a long post, but it’s mostly just a pattern to explain.
Many uploads were made to bring us this information.
Parts used:
ColorSelect, WavNum<>, WavLen<>, EFFECT_POSTOFF.
The short story is the issue of specifying EFFECT_POSTOFF within WavLen is being weird.
If it is one of several BUT the only one specified, it doesn’t display anything.
Setup:
I have 4 COLORS in ColorSelect<> chosen by WavNum<>, where the COLORS are different POSTOFF TransitionEffectL layers, AND using TrDelayX<WavLen<>> for how long they display for.
If only one of them DOES specify the EFFECT_POSTOFF while the others are just WavLen<>, the specified one will not show anything.
Example. Red will not show with this:
ColorSelect<WavNum<EFFECT_POSTOFF>,TrInstant,
TransitionEffectL<TrConcat<TrInstant,Red,TrDelayX<WavLen<EFFECT_POSTOFF>>>,EFFECT_POSTOFF>,
TransitionEffectL<TrConcat<TrInstant,Green,TrDelayX<WavLen<>>>,EFFECT_POSTOFF>,
TransitionEffectL<TrConcat<TrInstant,Blue,TrDelayX<WavLen<>>>,EFFECT_POSTOFF>,
TransitionEffectL<TrConcat<TrInstant,Yellow,TrDelayX<WavLen<>>>,EFFECT_POSTOFF>>,
Moving the position of the only only specified one down to the 2nd line, the problem moves with it, and Green will not show.
ColorSelect<WavNum<EFFECT_POSTOFF>,TrInstant,
TransitionEffectL<TrConcat<TrInstant,Red,TrDelayX<WavLen<>>>,EFFECT_POSTOFF>,
TransitionEffectL<TrConcat<TrInstant,Green,TrDelayX<WavLen<EFFECT_POSTOFF>>>,EFFECT_POSTOFF>,
TransitionEffectL<TrConcat<TrInstant,Blue,TrDelayX<WavLen<>>>,EFFECT_POSTOFF>,
TransitionEffectL<TrConcat<TrInstant,Yellow,TrDelayX<WavLen<>>>,EFFECT_POSTOFF>>,
Move to the 3rd line, the problem moves with it, and Blue will not show.
ColorSelect<WavNum<EFFECT_POSTOFF>,TrInstant,
TransitionEffectL<TrConcat<TrInstant,Red,TrDelayX<WavLen<>>>,EFFECT_POSTOFF>,
TransitionEffectL<TrConcat<TrInstant,Green,TrDelayX<WavLen<>>>,EFFECT_POSTOFF>,
TransitionEffectL<TrConcat<TrInstant,Blue,TrDelayX<WavLen<EFFECT_POSTOFF>>>,EFFECT_POSTOFF>,
TransitionEffectL<TrConcat<TrInstant,Yellow,TrDelayX<WavLen<>>>,EFFECT_POSTOFF>>,
Down to the 4st line, the problem moves with it, and Yellow will not show.
ColorSelect<WavNum<EFFECT_POSTOFF>,TrInstant,
TransitionEffectL<TrConcat<TrInstant,Red,TrDelayX<WavLen<>>>,EFFECT_POSTOFF>,
TransitionEffectL<TrConcat<TrInstant,Green,TrDelayX<WavLen<>>>,EFFECT_POSTOFF>,
TransitionEffectL<TrConcat<TrInstant,Blue,TrDelayX<WavLen<>>>,EFFECT_POSTOFF>,
TransitionEffectL<TrConcat<TrInstant,Yellow,TrDelayX<WavLen<EFFECT_POSTOFF>>>,EFFECT_POSTOFF>>,
Then, specifying for Blue AND Yellow, all the postoffs show correctly.
ColorSelect<WavNum<EFFECT_POSTOFF>,TrInstant,
TransitionEffectL<TrConcat<TrInstant,Red,TrDelayX<WavLen<>>>,EFFECT_POSTOFF>,
TransitionEffectL<TrConcat<TrInstant,Green,TrDelayX<WavLen<>>>,EFFECT_POSTOFF>,
TransitionEffectL<TrConcat<TrInstant,Blue,TrDelayX<WavLen<EFFECT_POSTOFF>>>,EFFECT_POSTOFF>,
TransitionEffectL<TrConcat<TrInstant,Yellow,TrDelayX<WavLen<EFFECT_POSTOFF>>>,EFFECT_POSTOFF>>,
The converse is NOT true. Having a single use just WavLen<> among all others specified, regardless of position, everything works fine.
Only EFFECT_POSTOFF though.
EFFECT_PREON seems to work fine, as I tested all the same conditions above with all always working.
Not to be too ambitious, but adding an in.bmp and out.bmp for ignitions and retractions could be cool while we’re at it. SOUNDS simple enough to implement.
I’m goin’ in…
Could you post the full style you’re using? I’m wondering if maybe the blade is just turning off in some cases.