Interesting.
I guess the question is; what do we do about it?
I think we want a way to send effects even when the saber is off, but it would seem we also need a way to NOT do it when the saber is off.
Maybe we should have something like:
TrDoEffect<TRANSITION, EFFECT, WHEN_OFF=false>
?
@Fett263, what do you think?
It also occurs to me that mini games and other state machines inside the style will end up stuck when you turn the blade off, and then continue when you turn it on again. Not sure if that’s what we want, or if we need some way to reset it automatically?
Ok, I made a 7.2 zip.
It’s all the same stuff, plus:
Can confirm 7.2 (and 7.1) that AUDIO_CLASH_SUPPRESSION_LEVEL is working and working even better than when it was under OS6.x. Used Darksaber to test since speaker was so close to board by design. Formerly using suppression level at 25 which was working with problem font (Kyberphonic Dark V3) under 6.7 and clash threshold of 2.5. Was able to go all the way to Suppression level 20 and clash threshold of 2.0 for optimal no false clashes while minimizing injury with a sharpened darksaber blade (using 7.1 primarily to test but still working on 7.2). Both tested static and swinging 180, volume at 1800.
Will try the proffieboard that’s been corrupting a lot of my SD cards (6 total) when I can with the new OS beta.
So does this actually change how swingl.wav and swingh.wav files interact with hums? Will this change how sabers sound when swinging?
Maybe, would need to test to make sure it doesn’t muck up other intended uses.
The mini game I demoed used conditional effects, including Ifon, to run to prevent triggering when not desired. I wouldn’t typically recommend chaining a long group of TrDoEffect inside a single transition because you could end up stuck in a loop. That said as long as it doesn’t interfere with the intended uses I have it’s not a bad idea to try to prevent issues when users build their own interpretations.
We probably want the WHILE_OFF to call done() to just end the transition if the saber is turned off mid-chain.
I might have time tomorrow evening to write it up and test unless you get to it first. I’d just want to ensure it doesn’t detract from all of the other uses I had.
I always keep a backup of the SD Card upon any changes to font/track folders.
For config files only, will start saving both ini and tmp files to ensure I have the full backup. Is there any way to decipher which is the most recent?
Isn’t it easier to add a flag to work after saber is off, plus another if it keeps state through off/on cycle? That way you can get the “expected” behaviour, but have a couple (or a single one) flag for people that really know what they are doing.
Sort a list view of the files by date modified?
ProffieOS doesn’t update the modification date when modifying a file though.
It’s kind of pointless since the board doesn’t know what time/date it is anyways.
It’s hard to know which file is most recent. In most cases, you have to read the iteration number (as described here: ProffieOS Documentation: Save File Format) but even that’s not always enough, because the iteration number isn’t valid unless the checksum is correct. The checksum should generally always be correct unless the saber crashed or lost power while saving though.
Maybe what I should do is to create an Emacs mode for editing these files. Emacs is programmable and cross-platform, so it would make it possible to edit these files directly.
At first, I was thinking that this would be a bad idea, since it would immediately stop the transition. However, with a slight modification, it could work: We only make done() return true after the blade is actually powered down. That way, any abrupt change would be guaranteed to not be visible.
That makes sense. Just not clear how the transition would “know”, is there a current function for this or we need to add?
I’ll have to look if there is an existing function on the blade or not.
If not, we might have to add one.
Whatever you can do to make it easier to determine would be great. If there was a way to make it more approachable a la OS6, that’d be ideal. Appreciate any or both.
Just “spitballing”, I haven’t looked into the new .ini and .tmp but if you just copied the same preset info into both you wouldn’t need to know which was most recent, right?
The question is which file has the most up-to-date information to start with before you make additional changes.
Precisely.
Is it hard to just have a timestamp line printed to the file somewhere?
Yes, ProffieOS doesn’t know what time it is.
Ah of course.
Well how about just an ever growing number then?
Write # 0000001
Write # 0000002…
Meh. I suppose that gets reset each boot.