So I’ve been trying to troubleshoot these false clashes I’ve been getting with my Proffie 2.2 board. It consistently happens after I abruptly stop from fast spin, then a clash would trigger after a short delay when stopped.
So far I’ve tried audio clash suppression at various levels and it didn’t help. I’ve tried spin mode, which does its job to not trigger clashes from actually hitting the saber, but will still trigger after a fast spin. Also, putting the saber in mute and I could visually see the blade doing a clash animation. I’ve tried all the extreme settings for clash threshold detection and still would get these false clashes.
I also looked at stabilizing my board and core by “shimming” with some electrical tape to eliminate any movement in the soundboard.
After all of this troubleshooting and searching, I’m at a loss as to why this is happening. Especially since spin mode should eliminate clashes altogether, but it doesn’t stop these delayed false clashes. Is this a known issue, or is there something I can define in my config to stop it? I feel I’ve tried every define possible from the list of possibilities. I even found another thread about using defines for “PROFFIEOS_MOTION_FREQUENCY 80” and “PROFFIEOS_DONT_USE_GYRO_FOR_CLASH”, etc and these didn’t seem to stop the issue I’m having.
This shouldn’t be possible, spin mode ignores the clash event completely, there’s no way it could trigger. Perhaps its your “blast” from a button short or click? Try setting a different color for blast and clash or hook up to Serial Monitor to see what actually triggers.
Yeah I thought it was a possibility that it might have been another similar sound file, so I tried a Greyscale soundfont that had very distinctive sounding clash when compared to blasts and other sound types. I’m fairly certain it’s a clash sound. When in spin mode, I definitely can’t trigger a clash just by hitting the saber, as it should be expected. Doing the fast spins, then stopping abruptly will trigger a clash sound and blade flash animation after a split second delay when I stop moving. I can get this to trigger pretty consistently. I am totally stumped at this phenomenon, especially so since it even happens in spin mode.
I will try to set all the different blade effects to different colours just to make for certain what’s actually triggering.
Yeah, I can’t see any way this would occur. Try loading this style, Clash will change the blade Red, Stab will change the blade Yellow and Blast will change the blade Green. This will make it very apparent what is triggering. Once we know what is triggering we can see “how”.
So I uploaded a new bladestyle to my saber from your style library and changed all the blade effects to different distinct colour. This was before I saw your reply, but this should still achieve what we’re looking for. Particularly, clash = green, and blaster = red. Hit the blade to test and it flashed green. Clicked aux and it flashed red. Did a fast figure-8 spin and stopped abruptly, split second delay, and it flashed green and played a clash sound file.
Put the saber in spin mode (hold power and swing). Hear the sound confirmation that I was in spin mode. Smacked the blade to test, and nothing. Did fast figure-8 spin, and blade flashed green after the delay and played a clash sound. Made certain I was definitely in spin mode, and it was.
Post your config using pastebin.com and I’ll see if I can test over the weekend. Every EVENT_CLASH in my prop returns true when spin mode is active so I don’t see any way this should occur.
@profezzorn any ideas on this? Would EFFECT_CLASH trigger anywhere outside of the prop if we’re returning “true” on the EVENT_CLASH case in my prop?
Every case for EVENT_CLASH (and EVENT_STAB) in my prop is returning “true” while in “spin_mode_” so I can’t see any way this should be occurring, the delay is also odd, almost seems like a bug but not sure where it would come into play.
I looked, but I don’t see a way for this to happen.
That just means we need to figure it out.
It could have something to do with the pending clash logic in the base prop file, but I don’t really see how.
Your prop calls DoClash in four different places, and maybe this is not the “normal” one?
In general, this problem feels like the kind of issue where a clash is somehow delayed instead of ignored.
Would that require me to have a cable connected to my Proffie board while I swing it around? If so, I don’t think that would be possible because of the way the removable core connects to the hilt. Also, I would need to spin the saber pretty fast to get these false clashes to trigger. I don’t think I could even do that safely tethered to a cable without breaking something.
Probably the way to debug this is to add a layer to the style which lights up when the EFFECT_USER1 occur. Then we can just add USER effects is triggered, then add SaberBase::DoEffect(EFFECT_USER1, 0); in various places (or in if statements) to see what’s going on.
To speed things up we can potentially use USER1/2/3, then we can insert three different things to watch out for.
Then upload (from new ProffieOS folder) and test. We’re watching for these colors and it will tell us where in the prop (if it’s the prop) the clash is triggering.
Green (User1)
Yellow (User2)
Magenta (User3)
Red (Clash) - not coming from prop
If you’re able to get a video and post that will help too.
Yes, only yellow in Spin mode using the same spinning movement that triggered the yellow outside of Spin mode. I tested it a lot more times off camera just to see if anything else triggered. Magenta clash could only be triggered outside of Spin mode by hitting the saber, but only yellow when spinning. I did not see a green or red clash in either mode.