Accent color based on Blaster Mode

[HolyAcorn]

Hey! I’m still quite new to ProffieOS and particularly Lightsabers.

I have been trying to create a way for an accent LED to be in a different color depending on which mode you have selected (for example red = kill, green = auto, blue = stun). I tried searching the documentation and on here but couldn’t find it.

My thought was to perhaps get the current mode from the blaster.h file into a IsLessThan function in the blade style, but I haven’t been able to find a way to do that.

Do you guys have any ideas on how to do something like this, if possible.

Happy Easter!

[NoSloppy]

That’s a blade style thing.
I don’t think I’ve ever seen it used before, but you should be able to use ColorSelect<> with EFFECT_MODE.
Try something like:

StylePtr<ColorSelect<EffectIncrementF<EFFECT_MODE,Int<32768>,Int<10921>>,TrInstant,Red,Green,Blue>>()

[profezzorn]

EffectIncrementF might not line up if you switch styles.
It would be better to create a function that actually returns the mode.

[NoSloppy]

You mean switch presets? Ah, yeah mode persists so it would go out of sync unless you always cycle back to kill before switching. Not ideal.

[profezzorn]

We already have BulletCountF and BlasterChargeF which only apply to blasters, so we should just do something similar I think.

[HolyAcorn]

This got me on the right track! Thank you! But it did start to go out of sync after a few switches.

[HolyAcorn]

I started looking at those functions, but I have never written C++. But this is an excellent execuse to learn another programming language.

[profezzorn]

The ProffieOS style templates are not exactly the easiest place in the world to start…

[profezzorn]

If you do want to understand those functions, you should probably also read this:

Masterpiece Theater presents: SVFs

It was a dark and stormy night, and I was trying to figure out why styles use so much RAM. So I used a debugger to print out all the things that are allocated in the style. Turns out that there is a whole bunch of variables called “value” or something similar. So, it turns out that a whole bunch of the files in functions/ look something like this: class RandomF { public: void run(BladeBase* blade) { value_ = random(32768); } int getInteger(int led) { return value_; } private: int value_; }; As you can see, run calculates a value, it is stored in value_, and then getinteger returns it. It’s done this way so that RandomF will return the same value for every LED. Of course, a most of the time when we use functions like this, we don’t actually need the function to return the same value for every LED, because all we do is call getInteger(0) on it from some other run function. Here is an example that does both: template<class MAX> class SwingSpeedX { public: void run(BladeBase* blade) { max_.run(blade); float v = fusor.swing_speed() / max_.getInteger(0); value_ = clampi32(v * 32768, 0, 32768); } int getInteger(int led) { return value_; } MAX max_; int value_; }; See how it only calls max_.getInteger(0) from run? So if we were to use a style like SwingSpeedX<RandomF<>>, storing the random value in value_ is entirely wasted. This might not be a great example, but there are lots of cases of this in the code. So, what can be done about it? Well, the first step is to split up RandomF and similar classes into two parts: One that calculates the value, and one that stores the value so that getInteger() will work properly, and later we can work on optimizing away the storing part… We’ll need a new API for the calculating part, and this new API is called an SVF, which means “Single Value Function”. For RandomF, the new SVF looks like this: class RandomFSVF { public: int calculate(BladeBase* blade) { return random(32768); } void run(BladeBase* blade) {} }; So the new thing here is the calculate function, which is sort of like getInteger(0), or like a run() function which returns a value. The part that does the storing of the value, looks like this: class SingleValueBase { public: int getInteger(int led) { return value_; } int value_; }; // Converts an SVF to a FUNCTION template<class SVF> class SingleValueAdapter : public SingleValueBase { public: void run(BladeBase* blade) { single_value_function_.run(blade); val…

[ryryog25]

lol. I would second this, do not try to start learning C++ with ProffieOS blade styles. Templating and meta programming is not exactly beginner friendly

[NoSloppy]

@profezzorn

We already have BulletCountF and BlasterChargeF which only apply to blasters, so we should just do something similar I think.

is this the worst ever?

// blaster_mode.h

#ifndef FUNCTIONS_BLASTER_MODE_H
#define FUNCTIONS_BLASTER_MODE_H

#ifdef BLASTER_SHOTS_UNTIL_EMPTY
#include "props/blaster.h"

// Usage: BlasterModeF
// Returns the current blaster mode as an integer:
// 0 for MODE_STUN, 1 for MODE_KILL, 2 for MODE_AUTO
// This function should only be used when BLASTER_SHOTS_UNTIL_EMPTY is defined,
// indicating that the current prop is a Blaster.
// Example usage in a style:
// StylePtr<ColorSelect<BlasterModeF, TrInstant, Red, Green, Blue>>()

extern Blaster prop;

class BlasterModeSVF {
public:
    void run(BladeBase* blade) {}
    int getInteger(int led) { return prop.blaster_mode; } 
    int calculate(BladeBase* blade) { return prop.blaster_mode; }
};

template<>
class SingleValueAdapter<BlasterModeSVF> : public BlasterModeSVF {};

using BlasterModeF = SingleValueAdapter<BlasterModeSVF>;

#endif // BLASTER_SHOTS_UNTIL_EMPTY

#endif // FUNCTIONS_BLASTER_MODE_H

[profezzorn]

@NoSloppy

is this the worst ever?

Nope, not even a little bit.
However, there are a few issues:

1. prop files have side effects and should only be included once, and only if that’s the prop file you want to use. To work around this, you can add a global function for getting the blaster mode. This function would be declared in this file, and defined in blaster.h, which would mean that you get a linker error if you try to use without the blaster prop.
2. Not all blasters use BLASTER_SHOTS_UNTIL_EMPTY, so it’s not the best define to use to decide if we should have a BlasterModeSVF or not. In fact, we don’t need an #ifdef at all since we’ll get a linker error (see 1 above)
3. It’s not a PR

[NoSloppy]

@profezzorn

It’s not a PR

It is now. Working well.

[profezzorn]

Looks pretty good, just needs a couple of tweaks.

[HolyAcorn]

Oooh, thank you very much.

Is there anything I need to do besides creating a file in the functions folder called blaster_mode.h with this in it?

[NoSloppy]

Yes not just that.
Once it’s added to the code on GitHub, you can download the latest development build there.

[HolyAcorn]

I saw that it was added now. Thank you Profezzorn and NoSloppy for your help! I really appreciate it!