In the last few month, I have been playing/testing my multi_prop.h.
It was working great until I started using #define BLADE_DETECT_PIN
multi_prop works with:
struct FakeBladeID { // Sabersense code part 1 of 2 adapted to multi_prop.h
static int return_value;
float id() { return return_value; }
static void SetFakeBlade(int id) {
return_value = id;
}
};
// Initialize return_value to a default of 0 - SABER mode
int FakeBladeID::return_value = 0;
#undef BLADE_ID_CLASS_INTERNAL
#define BLADE_ID_CLASS_INTERNAL FakeBladeID
#undef BLADE_ID_CLASS
#define BLADE_ID_CLASS FakeBladeID
before the prop definition and in the prop definition:
void updateBladeIDAndDetect(int blade_id) { // Sabersense code part 2 of 2 adapted to multi_prop.h
FakeBladeID::SetFakeBlade(blade_id);
PropBase::FindBladeAgain();
SaberBase::DoBladeDetect(true);
}
Without #define BLADE_DETECT_PIN blade5Pin, it works perfectly, and each prop only uses it’s own/assigned Preset set & BladeConfig blades set. But with the BLADE_DETECT_PIN defined, all props only uses the first Preset & BladeConfig blades set (assigned to the saber).
Is there something I can change in my code to ensure that each prop (saber, blaster, detonator & jetpack) only uses its “assigned by multi_prop” Preset set & Blade set when BLADE_DETECT_PIN is defined?
For reference, please find attached my latest multi_prop version. multi_prop.h (23.7 KB)
Thank you for reading and any help you can provide.
MTFBWY
Blade detect will add NO_BLADE, which is equal to 1000000000, to the id, then it will find the closest id in the blade array, which is usually the NO_BLADE entry. However, there is nothing stopping you from have an entry for NO_BLADE +1, NO_BLADE+2, etc.
(Although the NO_BLADE thing is probably disabled since you override BLADE_ID_CLASS_INTERNAL…)
Alternatively, it wouldn’t be that hard to make it so that entirely different array of blade entries are used for different props. Essentially you would do something like:
replace all places whee “blades” is used with a function, like GetBlades()
replace NELEM(blades) with GetNumBlades()
In the base class, GetBlades() and GetNumBlades() would just return blades and NELEM(blades), but in the multi_prop, these could be overridden with functions that return different values for different props, so for a blaster, it could returnblaster_blades and NELEM(blaster_blades).
Because I would like bladein/bladeout.wav to play when I insert/remove the blade.
My fake blades ids are 0, 1, 2 & 3.
3 is the “closest” to 1000000000 but 0 is the one that gets selected.
My 4 blades arrays are all identical except for the first and last lines:
BladeConfig blades[] = {
{ 0, //SABER
// === Main Blade: ===
WS281XBladePtr<144,bladePin,Color8::GRB,PowerPINS<bladePowerPin2,bladePowerPin3>>(),
// === NPXL Connector inner ring ===
SubBladeWithStride(0,15,2,WS281XBladePtr<16,blade2Pin,Color8::GRB,PowerPINS<bladePowerPin2,bladePowerPin3>>()),
// === NPXL Connector outer ring ===
SubBladeWithStride(1,15,2,NULL),
// === Crystal Chamber: ===
WS281XBladePtr<1,blade3Pin,Color8::GRB,PowerPINS<bladePowerPin1>>(),
// === Bluetooth: === (fake blade)
SimpleBladePtr<CH3LED,NoLED,NoLED,NoLED,bladePowerPin6,-1,-1,-1>(),
CONFIGARRAY(presets_saber), "__saber_save" },
{ 1, //BLASTER
// === Main Blade: ===
... same as above ...
CONFIGARRAY(presets_blaster), "__blaster_save" },
{ 2, //DETONATOR
// === Main Blade: ===
... same as above ...
CONFIGARRAY(presets_detonator), "__detonator_save" },
{ 3, //JETPACK
// === Main Blade: ===
... same as above ...
CONFIGARRAY(presets_jetpack), "__jetpack_save" },
};
Since the blades arrays are identical, I don’t feel I need more than one. But I would like to assign one set of presets (Preset presets_saber, Preset presets_blaster, Preset presets_detonator & Preset presets_jetpack
per prop with or without blade.
I do not have at the moment a NO_BLADE array in my config. Do I need to add one ? Or add NO_BLADE for saber, NO_BLADE+1 for blaster, NO_BLADE+2 for detonator, … ?
I thought that is what I did already ? I have 4 blades arrays and 4 presets arrays, one per prop. It works perfectly until I use blade detect.
Sounds like a fantastic place you could use a helper function
// constexpr probably won’t work here…
// presetArray is auto because I don’t remember how that macro expands… that would need to be updated almost certainly since auto alone probably won’t do what is expected
constexpr BladeConfig makeBladeArray(uint32_t id, auto presetArray, const char *arrayName) {
return { id,
/* actual blade config stuff */,
presetArray, arrayName
};
}
BladeConfig blades[] = {
makeBladeArray(0, CONFIGARRAY(presets_saber), “__saber_save”),
};
That’s the thing, I would rather not have 4 blades arrays (or 8 for “BLADE” + NO_BLADE). I’d prefer to have only 2 blades array (“BLADE” + NO_BLADE) with 4 presets arrays (1 presets array per prop) and a way to declare the location for saving curstate.ini/tmp & presets.ini/tmp in 4 different directories.
Ideally, I would like to get rid of FakeBladeID altogether and have multi_prop “decide” which preset array can be used by which prop and where each prop can save curstate.ini/tmp & presets.ini/tmp. Is that even possible?
Replacing NELEM(blades) with GetNumBlades() is pretty straight forward, only 4 files have that with only one or two instances each (prop_base.h, saber_BC_buttons.h, saber_fett263_buttons.h & saber_sabersense_buttons.h).
But replacing all the places where “blades” is used with a function, like GetBlades(), now that seems a lot harder because there are a lot of “blades” instances in ProffieOS:
83 files, most, I am pretty sure, can be ignore like all the config files, or where “blades” is spelled differently (like “blades_”, “BladeS” or “BLADES”) witch still leaves me with 3 files: saber_base.h, prop_base.h & saber_fett263_buttons.h but they all haves a lot of “blades” instances each (100+35+46=181). And I know, many of those 181 instances are spelled differently.
Is there a way to “case sensitive search” on Github Master to reduce it further ?
I used “blades” in my search but I still get blades, BladeS & BLADES as a result.
Do I also need to change:
blades[i].ohm to GetBlades()[i].ohm (in prop_base) ? My hunch is saying yes.
blades() to “something” (in saber_base) ? My hunch is saying no.
location.blades() to “location.something” (in saber_base) ? My hunch is saying no.
Shouldn’t be virtual, and the point is to return the array you want for the current active prop.
So you’d need a switch (or just if statement ), to return the correct array.
For replacement, I just use Ripgrep and neovim cdo on the quick fix list… that latter part doesn’t help you but ripgrep (or just plain grep) will let you look for exactly what you want in the files using regex.
Just have to clone the ProffieOS repo to run grep on your computer.
I’m not entirely certain why setting BLADE_DETCT_PIN messes things up though. It seems to me like if your blade array has two entries for every preset array (one with NO_BLADE, one without) then it should just work.
In multi_prop, yes but I need a default behavior in prop_base.
so in prop_base:
and in multi_prop:
const GetBlades() override {
switch (currentMode_) {
case Prop_Mode::SABER: return blades_saber;
case Prop_Mode::BLASTER: return blades_blaster;
case Prop_Mode::DETONATOR: return blades_detonator;
case Prop_Mode::JETPACK: return blades_jetpack;
}
}
int GetNumBlades() override {
case Prop_Mode::SABER: return NELEM(blades_saber);
case Prop_Mode::BLASTER: return NELEM(blades_blaster);
case Prop_Mode::DETONATOR: return NELEM(blades_detonator);
case Prop_Mode::JETPACK: return NELEM(blades_jetpack);
}
}
Sorry @ryryog25, maybe I didn’t formulate my question correctly.
When I asked "
I was expecting “some code (that would give me case sensitive only)”+“blades” so the Github search would only return instances of “blades” and not “BLADES” or “BladeS” (as in “BladeStyles”). There are ways in sublimetext to only return what I need already, so I guess I’ll go with that. I do like using GUI and I usually stay away from command lines programs when ever I can.
Is that on Github? When I edit a Github file, on Github, I don’t see a search or any checkmarks boxes. But there is a “Case sensitive” button in the Sublimetext search.
“Why?”, because:
I would like to have the ability to use the “real” BladeID for it’s intended purpose, aka when I put a different blade in, I get all the pixels to behave as per the blade style.
I am planning to have 6 props running on my “physical prop” and I see no good reason to have the same blade array duplicated 12 times ((blades +NO_BLADES) times 6 props)). Or, if I have 2 “real” BladeID, I would need 18 blade arrays, with 3 “real” BladeID, I would need 24 blade arrays, …
Is there a way to “divorce” blade(s) arrays from preset arrays ? I feel the answer lies in this tread:
After a lot of back and forth with ChatGPT (like asking “what does this do”) and exploring all the functions involved in FindBladeAgain(); I have multi_prop working as I want with BLADE_DETECT_PIN.
I tried the blades and NELEM(blades) route:
I was not too successful with it because when I realized that it was not going to help me reduce my number of almost identical blade(s) arrays and make my fork become a mess at each update, I decided to stop that “madness”.
I tried to go another madness route: try to influence the presets arrays directly by following the same blade route madness described above (with some GetPresets() and GetNumPresets() functions). It always failed because ultimately presets and NELEM(presets) are apparently not accessible by prop_base AT COMPILE TIME thus always producing some kind of compile error (Compilation error: 'presets' was not declared in this scope; did you mean 'Preset'?, no matter how hard I tried.
If presets can’t be accessed by prop_base at compile time, multi_prop can’t override it! But I would love to know how to make presets accessible by prop_base if at all possible?
I did have some success with some “GetSaveDir()” overrite function (it compiled) but that was a “somewhat useless exercise” since I couldn’t influence the presets directly to help reduce my blades array size.
At least, I did gain some knowledge, so maybe “partially useful” ?
I can confirm that it isn’t disabled with my BLADE_ID_CLASS_INTERNAL…, in fact it was in some case part of the problem to think that it was disabled and ending up with some NO_BLADE+NO_BLADE+Blade_ID values which for some reason was making FindBladeAgain() return with my 0 blade array! I still don’t understand why NO_BLADE+NO_BLADE+Blade_ID is closer to zero than NO_BLADE+highest Blade_ID (3, in my case) ? After finding that out, I removed my manual addition of NO_BLADE and everything is now working as I was hopping for.
My BladeConfig blades is now like this:
BladeConfig blades[] = {
{ 0, //SABER with a blade
// with my "identical" blade(s) definition(s) here.
CONFIGARRAY(presets_saber), "_save_saber" },
{ 1, //BLASTER with a blade
// with my "identical" blade(s) definition(s) here.
CONFIGARRAY(presets_blaster), "_save_blaster" },
{ 2, //DETONATOR with a blade
// with my "identical" blade(s) definition(s) here.
CONFIGARRAY(presets_detonator), "_save_detonator" },
{ 3, //JETPACK with a blade
// with my "identical" blade(s) definition(s) here.
CONFIGARRAY(presets_jetpack), "_save_jetpack" },
{ NO_BLADE, //SABER without a blade
// with my "identical" blade(s) definition(s) here.
CONFIGARRAY(presets_saber), "_save_saber" },
{ NO_BLADE+100, //BLASTER without a blade
// with my "identical" blade(s) definition(s) here.
CONFIGARRAY(presets_blaster), "_save_blaster" },
{ NO_BLADE+200, //DETONATOR without a blade
// with my "identical" blade(s) definition(s) here.
CONFIGARRAY(presets_detonator), "_save_detonator" },
{ NO_BLADE+300, //JETPACK without a blade
// with my "identical" blade(s) definition(s) here.
CONFIGARRAY(presets_jetpack), "_save_jetpack" },
};
I chose NO_BLADE+100, NO_BLADE+200, … because I like the look of it better but it will also work with NO_BLADE+1, NO_BLADE+2, … (I tested it).
Please find attached my latest and greatest (so far) multi_prop version 065.15 (yes the final version will be 66!) multi_prop.h (31.4 KB)
I hope someone will find it useful, or at least enjoy the humor I put in some of the comments.
Cheers & MTFBWY.
Edit: yes I had some ChatGPT help but all the code (as far as I know) has been tested and it is working well.
