It might be easier to just put the arg strings in the config file instead…
I appreciate the idea, and I’ve thought it over several times. Unfortunately, it would undo a lot of what OS6 ushered in with Presets.ini housing much of the style variations.
Will find a way.
Not really.
OS7.x lets you put a string in the parenthesis that go at the end of the style, which becomes the default argument string for that style.
You could have styles like:
StylePtr<LongStyleHere>("65535,0,0"), // red blade
StylePtr<LongStyleHere>("0,0,65535"), // blue blade
Since the StylePtr use the same style, very little extra memory is used.
Really the only thing that uses more memory is the string itself, which is fairly small.
This lets you have most of the benefits of using an ini file without using an ini file.
These strings can still be edited in edit mode, or in the ini file, so everything still works, but it lets you set the base configuration in the config file, which means that you can always delete presets.ini/presets.tmp to go back if you mess something up.
I wish that would work with the styles I’m using, but I’m afraid they are far too convoluted. I have no issue with Presets.ini, but manual editing just made minor changes easier. The Workbench is just fine at making those modifications.
I’m not sure why “convoluted” styles makes a difference.
It’s because those styles have been the foundation of a library of customized presets I’ve built all saved to Presets.ini and not in the config. So, I’m using essentially 1 style in my config to generate 20+ Presets via Workbench/Edit Mode, or more specifically 5 styles to create the 60+ presets I referenced.
So, it’s less whether transitioning to the config is possible and more that Presets.ini brought the convenience of style adjustments / re-assignments without the need to flash the board. In that transition, I went in heavy on Presets.ini, as did my reliance on editing it via Workbench, Edit Mode, and sometimes manually.
Hope that clarifies.
At some point I figure I’ll try to write up a howto page for editing the ini/tmp files.
It’s mostly a matter of finding suitable editors I think.
Or, maybe I could write some sort of helper tool or something.
I really appreciate the help. I’ll continue my search and see if I can get something that works. I’ll report what I find.
Oh, one other question. Given that with OS7, we don’t know whether the INI or tmp is the recent savefile, shall we backup both when making SD Card Backups?
*I customarily make .INI backups for curstate, global, gesture, and presets files.
I would recommend backing up all files on the SD card.
If you just want to back up the config files, then you definitely need to do both, or you may get the last-but-one settings.
Well, this is interesting.
I just inadvertently ran this blade style again. Keep in mind where it says etc... above is actually several of each effect, so clash clash clash, blast blast blast, stab stab stab and so on.
When I shut off the blade pretty much right way to move on to my intended testing, I noticed:
- The effects continued through the preon (expected sortof), and then stopped when the preon was done. However, I then bumped the hilt and it played the next effect in the sequence of the TrConcat.
- repeated banging (triggering clash) would trigger the next TrDoEffect sound and TrDelay , then wait until the next “off-clash”, where the whole TrConcat ran in order until the list was exhausted… all while the saber was off.
So, while nobody would likely have a long sequence that could go on longer than the ignited session, they could and might?
We could certainly wrap the layer in an IfOff<>, but maybe we should figure out how to make sure any running TrConcats from the blade on state get stopped once retraction finishes?
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?
1 Like
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:
- OLED: made sure that error messages stay on the screen for a few seconds
- NoSloppy added a feature to let smoothswing sounds sync with hum
- A compile fix (missing variable) for the BC prop
- Fett263 updated usage comments and fixed a few cases where events were ignored.
- A bugfix for number of loops in TrLoopN
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?