Blade detect and my multi_prop.h

[olivierflying747-8]

@ryryog25

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.

In multi_prop, yes but I need a default behavior in prop_base.
so in prop_base:

@olivierflying747-8

virtual const GetBlades() { return blades; }
virtual int GetNumBlades() { return NELEM(blades); }

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);
  }
}

@ryryog25

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.

Sorry @ryryog25, maybe I didn’t formulate my question correctly.
When I asked "

@olivierflying747-8

Is there a way to “case sensitive search” on Github Master

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.

@NoSloppy

if you edit a file, the search has checkmarks for Regex and Match case

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.

@profezzorn

Why? FakeBladeID is how multi_prop can make that decision…

“Why?”, because:

1. 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.
2. 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:

Switching between many (more than 2) preset lists

Well this is turning into a good week - prop file accepted, had a small service charge victory, it hasn’t rained on me on my motorcycle commute, and now I’ve managed to get array saving to work! Pull request submitted.

but I can’t see the answer I am looking for.