Multi_prop.h, I feel I am getting closer to something usable but

Props
41

Definitely take a look at that article I linked about the C Preprocessor to understand #if

42

So if I understand the button mapping properly:

The SaberBlasterProp assumes that the Blaster prop
needs key mapping to work properly.

So this code alternates at each Prop change.
It is not suitable for multi_prop.h

It needs to be re-written to suit the needs of each prop:

  • Saber: “normal mapping”
    (If 3 buttons: POWER, AUX & AUX2)
    (If 2 buttons: POWER & AUX)
  • Blaster: “alternate mapping”
    (If 3 buttons: POWER, FIRE, MODE_SELECT)
    (IF 2 buttons: FIRE & MODE_SELECT)
  • Detonator: same as Saber (or is it ?)
  • Jetpack: same as Saber (yes I am also attempting a jetpack prop)

Did I understand button mapping correctly ?

43

It currently toggles, that is correct.
Sounds like instead, maybe it’s a good candidate for a switch case for each prop?

enum?

44

I thought of switch & enum but since only the blaster need something different, I thought I would get a much shorter code with (please don’t mind the syntax, I’ll figure it out - just trying to get the idea correct first)

if (currentMode = =:: blaster:)
"change mapping"
else "set/reset standard mapping"

I already have 4 working props plus another 3 or 4 in the pipeline so a 7 or 8 switch case would be a lot longer, no ?

45

I would write a mapping function similar to what’s in dual prop:

uint32_t mapButtonToBlaster(uint32_t button) {
    switch (button) {
#       if NUM_BUTTONS == 3
        case BUTTON_FIRE: return BUTTON_AUX;
        case BUTTON_MODE_SELECT: return BUTTON_AUX2;
#       else
        case BUTTON_FIRE: return BUTTON_POWER;
        case BUTTON_MODE_SELECT: return BUTTON_AUX;
#       endif
        default: return button;
    }
}
uint32_t mapButtonToSaber(uint32_t button) {
    switch (button) {
#       if NUM_BUTTONS == 3
        case BUTTON_AUX: return BUTTON_FIRE;
        case BUTTON_AUX2: return BUTTON_MODE_SELECT;
#       else
        case BUTTON_POWER: return BUTTON_FIRE;
        case BUTTON_AUX: return BUTTON_MODE_SELECT;
#       endif
        default: return button;
    }
}

/* in event2 after handling any of your own combos */
    switch (currentMode) {
        case BLASTER: return Blaster::Event2(mapButtonToBlaster(button), effect, modifiers);
        case SABER: return Saber::Event2(mapButtonToSaber(button), effect, modifiers);
        /* Would also do this for `DETONATOR`, though maybe that could also use `mapButtonToSaber` and wouldn't need its own */
    }

Basically, the goal is to make sure the prop the events are being forwarded to is getting the expected button (the ones it’s set up to handle). So by running the button arg from Event2 through the map...() functions, the button will be switched to the appropriate one, or simply fed back out if it was already, for example BUTTON_POWER and the goal was to feed that event to the Saber prop.

46

There isn’t a “change mapping” thing going on.
Re-mapping the events is a conditional process, and it’s either done or not. The decision whether to re-map is directly based on the current state of the prop, so there is no map to set or reset.

47

That is what I meant, only two “maps” to be written and each prop uses/calls/if’s… one or the other.

48

No, both functions are used only for blasters.
The reason there are two functions is because there is a bit field of currently pressed buttons, and that bitfield gets mapped one way before the Event2 function is called, and then it gets mapped back afterwards.

For the saber prop, no button mapping is done at all.

1 Like
49

Please find attached my latest version for multi_prop.h

You can find the sound files (created by NoSloppy) on my dropbox here:
https://www.dropbox.com/scl/fi/p2pj9os5v4seel0wmzwcz/Multi_prop_sounds_by_NoSloppy.zip?rlkey=hi6589mexymnx4jmxhtwqjfu0&st=3klofs5m&dl=0

I would appreciate your comments, suggestions or critiques (spelling mistakes).

Thank you for all who helped me and especially @ryryog25, @profezzorn & @NoSloppy

Edit: "appologies, previously posted versions had an unfinished comment at the end /*, this is the correct one:
Edit2: "appologies a thousand times, deleted again, I got mixed up in the different revisions. I can’t find the working version, but I promise, it did work (compile). I will re-post once I find the correct version. I am really sorry.

Also for your enjoyment, comment, suggestions, critiques, … , here is an initial version of my vision of a jetpack_prop.
jetpack_prop.h (7.2 KB)

50

Does it work?

51

They both compile but my chassis is not finished yet so I can’t test it.

52

Well, after a quick glance, I have two comments:

  1. Your SB_Effect() only checks the mode, not what type of request was requested, which means that every effect will play the mode change sound.
  2. If you would like to get the code added to proffieOS eventually, you should stick to the same style as the rest of the code. For instance, do not put } after other stuff, and only one per line.
53

Thank you for the feedback.

That I can absolutely do.

I understand this is a problem but I will need a bit more explanations, or maybe a link or two where I can educate myself.

Obviously nobody wants that.

Does the buttons mapping function seems right to you ?

Maybe, you would like me to change the comments ?

54

Didn’t read in that much detail yet.

You can read how SB_Effect works in the other props.
Also, it might be helpful to know that all the SB_* functions are part of the event-distribution system in ProffieOS. All the objects that inherit from SaberBase get stored in a linked list, and when one of the Do* functions is called (like DoEffect) that function is called in all the SaberBase implementations, which includes the prop, sound, blades and displays.

55

I will definitely do that.

I am guessing that SB stands for Sound Board ? But could you give me a “non-initiated” definition ?

So what “kind of type” of request “can be requested” ?

56

Apologies, I posted the incorrect multi_prop.h file above twice. Now I can’t find the working (compiling) one. I will re-post it when I find it. I swear on my children, it did work !

57

No, it stands for SaberBase

I’m not sure what that means.

Ops, I meant the type of EFFECT that was requested.

58

@profezzorn , if I may ask, when you say: “Does it work?”
Is it because you saw something that shouldn’t work or because you tested it (tried to compile) and it didn’t work/compile for you ?

If it is because you saw something, please tell me in which part ?

I know I saw them (multi_prop & jetpack_prop) compile with the other props.

But now multi_prop doesn’t compile anymore and I can’t find the working version.

59

I ask because the more effort you put in to it, the more interesting it is for me (and possibly other people) to read, comment on and help with.

1 Like
60

I think the question meant did YOU try it and it worked for you.

I suggest making a free Github account.
It will have every change you ever made, and it’s off site so if your computer falls out a window, you’ll be fine.

1 Like