OK, so it looks like there was a scenario (or two) where the clash_type_ was getting a value which gets handled in Loop(). I’ve added a fix to that branch and reverted to normal clash behavior.
Pull down the update to this fork (same steps as above just be sure to overwrite the previous completely or save in another new location) and run your normal config. This should correct and also reset clash detection when you come out of Spin Mode.
If you can confirm I’ll get the bug fix submitted to profezzorn.
Okay, I downloaded this OS with the same config file with your test blade style and did the same testing. I hope these findings help.
Outside of Spin mode: hitting the saber causes a red clash; fast spinning still causes the delayed false clash, and is also red.
Spin mode enabled: hitting saber causes no clash; fast spinning no longer triggers a false clash after performing the same movements and variations of it many times.
Would this potential fix also stop these delayed false clashes in the normal mode, outside of Spin mode? I don’t normally use spin mode, but I only added it to my config as a means to troubleshooting these strange false clashes I’ve been getting during my normal usage.
Swinging or spinning really quickly and abruptly coming to a stop creates the same scenario in the accelerometer as the saber moving and hitting something -or- the saber sitting still and being suddenly accelerated from you hitting it. Clashes are detected when the blade suddenly accelerates or decelerates. There’s no way to determine if the sudden change in acceleration was from you swinging quickly and hitting an object or swinging quickly and then forcibly stopping the blade, that’s why Spin Mode was added. Since users spinning would typically create scenarios like you were experiencing with quick direction changes and stopping exceeding the CLASH_THRESHOLD_G are technically “clashes” to the board.
The “bug” I fixed and was checking for is only clashes happening in Spin Mode because they should not happen. Clashes outside of Spin Mode are acting as they should. You can mess around with your CLASH_THRESHOLD_G to give you more leeway in stopping abruptly but that then also means you need to hit the blade harder for real clashes.
So my Proffieboard is function as it should in the normal mode? I guess I’ll just leave Spin mode on my config from here on. Only issue I found with having Spin mode was it made it so I couldn’t toggle the Gesture Sleep function. When I would try to toggle it (hold PWR + clash), it would almost always toggle Spin mode instead.
I just tried setting CLASH_THRESHOLD_G to the maximum setting (16.0), and it would still trigger those strange delayed false clashes, but obviously it was impossible to trigger a clash in the traditional fashion. I’m guessing there is no way getting around these with the current config settings. I’m wondering if there would be a possibility in the future to have a define or something that would disable those clash events that triggered the yellow flashes from that test bladestyle, or would that really mess with the clash algorithm?
I’m sorry if it sounds like I don’t know what I’m talking about. I’m actually pretty new to Proffie and have only started less than a month ago. I’m still trying to learn as much as I can, especially thanks to the resources on your site.
Missed this the first time around, this means there’s most likely something else going on still. We’ll need another test to try to narrow down. Go to the branch again, pull down again (overwrite old version or put in new place).
Then add this style and test in normal mode (not Spin Mode).
If you see the top half of the blade go Cyan, let me know the bottom color that is with it as well. This is to check if there’s more than one thing triggering which might be why there’s an odd delay and/or hard to replicate. The effect will also stay a little longer on the blade to give time to see if more than one trigger.
Interesting, not where I thought it might be but narrows down a bit more. I made a few changes so get new version (either overwrite or extract in new location keep the same style code from last round).
Set your Clash Threshold to a normal number 3.0 ~ 4.0 (you don’t want false clashes just normal clashes during use).
Test outside Spin Mode again, see what colors come up in the same scenarios (they’re the same colors but have been moved in the code to identify the spots in that might be prop triggering).
Clash threshold set to 3.0. Clashed by hitting saber with hand flashes yellow. Spinning fast and stopping flashes magenta after a delay. Did not see any cyan.
Interesting, ok not where I originally thought it would be, but definitely helpful. Now I just need to figure out “why” and how to address. Might need another test if I can track down what’s not working as expected. Today’s a bit tight on free time so might need a couple of days. Thanks.
No worries, I’m also a bit tight on time this week too, but I’ll do what I can to help. Let me know what other tests you need me to do whenever you can. I’ll have my setup at the ready to try to get results back to you as soon as I can.
OK, I “think” I found it and fixed. Can you get updated version here and just run any style, (we’re not looking for colors anymore)? This should address the delayed Clash after fast spinning, it looks like the momentum of your swinging coming to a stop was mimicking the Force Push movement, but since you don’t have Force Push enabled it fell through to a clash, the delay is because we check if a Push ends in a Clash or not because certain hits to the saber (particularly the hilt) can also mimic a Push movement. This should handle correctly now when Force Push isn’t enabled, when it is enabled it would do the Force Push effect and if you got a clash we’d extend the Force Push Length to handle.
If you can confirm this fixed, I’ll get it submitted as a bug fix.
Sorry, I’ve just been so swamped with Christmas just passing. I’ve been meaning to upload that OS to my saber to test but I just couldn’t spare the time. I should be able to get that test done later today.
So I uploaded this new OS with the same config file as last time.
Did my spin test and was able to trigger a delayed false clash still. It flashed red this time. Clash threshold was set to 3.0. Hitting the saber with my hand also flashed red.
Set the clash threshold all the way to 16.0 and was still able to easily replicate the same delayed false clash. Also flashed red. It was almost impossible to get it to clash hitting it against my hand.
OK, yeah that style was specific to some testing to narrow down the code that was triggering. You can use a normal style the rest of the way, it will only show Red in the style going forward, the other colors aren’t tied to anything anymore.
I think I had the fix in the wrong location, try this version, same process as before just be sure you’re uploading from the new location or have completely overwritten the previous versions before uploading.
If the false clash still persists add this define and test again, but test without it first. It shouldn’t be needed but just as a second test you can add and run. See if the new version fixes or if the addition of the define does.
I just uploaded this OS to my saber with my own config. I did my spin tests and could not get the delayed false clashes to trigger. I tried various different spins and mixed up a bunch of directional changes and could not get it to clash. Clashed the saber by hitting it with my hand and it triggered just fine. I usually have my clash threshold set to 2.0 for my normal usage. Tried the spin test in “Spin mode” for good measure and it also seems fine. Didn’t bother to add the force push length define.
I’ll keep this OS loaded on my saber for the time being until you can get that bug fix submitted. Maybe I’ll manage to find a way to trigger another false clash until then. So far, it seems like you found the glitch.