I’m trying to make a How-To page for the POD. Regrettably, I’ve never done a blaster install, and the documentation is somewhat lacking. So I will write the bulk and let other make the corrections.
First, I have some questions regarding the fonts:
Do the blaster prop uses: boot, font and hum as do the Plecter specification?
What’s the mechanics of range? Does it needs multiple .wavs for each level?
I’m confused between the blast.wav and fire.wav, I understand that you need 16 blast##.wav, but then why do you need fire.wav` for?
What’s the mechanics of autofire? Because you have bgnauto, auto and endauto. But then you have the many blaster.wavs. I know Plecter uses those, and even proposes that you increase in volume or pitch for weapons with increasing power levels.
Regarding the mechanics:
If I set the BLASTER_SHOTS_UNTIL_EMPTY to 0 then I get infinite shots? Or you get zero? Is it an 32bit int or uint if you wanted an “infinite amount”?
BLASTER_JAM_PERCENTAGE range is 0 to 100 or 1 to 100?
Can the blaster prop use just one button?
If you add a third button for power it “power off” in the sense that it will stop the hum, but will not turn off the Proffie, right?
How does the OLED works? It defaults to shots left? Which events can have a dedicated animation?
Does the &style_charging works under blaster.h prop?
In any case, here is a link to my branch from which I will make the pull request:
Jam percentage is basically 0-99… so if you put 100 it will always jam… if you put 0. it will jam 1% if you put -1 it will never jam.
If you want infinite shots dont define that BLASTER_SHOTS_UNTIL_EMPTY… thats the easy way. I you put 0 you get 0.
As it is now Its a 2 button prop… I believe @NoSloppy is working on a new prop file. And I have been working on one two. But I would like to include as much of brians that I can. I have a different ideology of button use. I would also like to add in a couple new modes. And yes 3rd power button in at least my prop will do power on and off.
I believe someone was working on the OLED side of things but I am not sure exactly how far it is.
What do you mean style charging.
Blast is the shot sound. Fire does nothing currently. As far as I know you need one for each but you can have muitiple. And yes it does boot, font, and hum as the proffie.
Btw I dont know way you are talking about plecter. as this is a site for proffie.
Bgnauto is the start of the auto, auto is the loops sound and end auto is the end of the loop. Blast is for the fire not auto fire.
Does that answer your questions? @NoSloppy weigh in if I missed anything or got something wrong.
I’m sorry that there’s something I didn’t quite understand. For BLASTER_JAM_PERCENTAGE 0 does not means 0%, you have to use -1?
As it happened with the Font specification, much of it was made to be compatible with Plecter, who made the original specification. In the case of the blaster, the only actual specification I found was on their site. The fact that we have fire defined but does nothing points to that. I’m trying to understand the deltas between Plecter’s and Proffie’s behaviors. That’s why I’m referring to them.
Let’s see if I can provide some answers.
I’m not actually an expert on the blaster prop, as I don’t have an installed blaster…
Anyways, here goes:
Yes, the blaster prop is meant to support plecter blaster fonts directly. There may be some differences, but most fonts should work out of the box.
The range sound effect doesn’t seem to be tied to any button or function. However, you could trigger it with TrDoEffect<… EFFECT_RANGE> Not sure why we even have that really though.
I don’t see a reference to fire.wav anywhere. There is an EFFECT_FIRE, but it plays blast##.wav.
Also, you don’t need to have exactly 16 blast.wav files, you can have as many (or few) as you like.
I’m not sure exactly what the question is. Autofire works like a lockup and plays bgnauto, auto and endauto, it does not play blaster.wav during autofire from what I can tell.
It’s a 32-bit integer. If you want it infinite, you just don’t add that define to your config file.
The code looks like this:
virtual bool CheckJam(int percent) {
int random = rand() % 100;
return random < percent;
}
That means that a value of 0 is valid, and means zero percent chance of jamming.
Yes, but there is no support for gestures, so you just get “fire” and nothing else I think.
It’s not really made for it.
That is generally correct, yes.
Unless you make it a latching switch which cuts the power of course.
It doesn’t default to it. You need some special code in your config file to make that work.
Yes
It will save some things, but it won’t save the firing mode afaik.
The define is ENABLE_AUTO
Afaik, there is no “hold fire to go into auto” mode either way.
You have to use the mode button to select auto mode, then when you press fire, it will fire accordingly. Without ENABLE_AUTO you can’t go into auto mode.
First, thanks for all the input. With your answers I’ve been through blaster.h and… I think that prop needs a lot of love. Let me go over your answers and then make some further questions.
I went over Plecter’s BlasterCore manual first to understand the mechanics of the soundfont. In Plecter’s case is used for blasters with increasing power/range, and those sounds are supposed to be increased in pitch to matchs the level.
I was quite surprised that blaster.h defines the effect, defines the button, but lacks any handling. The current prop doesn’t use them. So I don’t know how much to document them.
The fire reference I got if from the Sound Font Configuration page. But I couldn’t find it. I would delete that reference not only from my How-To but from the Sound Font page, too.
I can’t get a clear list of sounds used. For example the code does this:
virtual void SelectAutoFirePair() {
if (!SFX_auto.files_found() || !SFX_blast.files_found()) return;
int autoCount = SFX_auto.files_found();
int blastCount = SFX_blast.files_found();
int pairSelection;
// If we don't have a matched pair of autos and blasts, then don't override the sequence to get a matched pair.
if (autoCount == blastCount) {
pairSelection = rand() % autoCount;
SFX_auto.Select(pairSelection);
SFX_blast.Select(pairSelection);
}
}
And I can’t understand how is the pairing. I don’t know where they inherit the .files_found() and if auto has a bgnauto, auto and endauto, how does blaster does pairing? As a fall back with just the blaster?
Incidentally, I know that if there are many autoxx.wav Plecter concatenates them, if we have many we just chose one at random?
Incidentally, would #define NO_REPEAT_RANDOM work with this prop?
As far as I read on the prop file, it is ENABLE_BLASTER_AUTO
virtual void NextBlasterMode() {
switch(blaster_mode) {
case MODE_STUN:
SetBlasterMode(MODE_KILL);
return;
case MODE_KILL:
#ifdef ENABLE_BLASTER_AUTO
SetBlasterMode(MODE_AUTO);
#else
SetBlasterMode(MODE_STUN);
#endif
return;
case MODE_AUTO:
SetBlasterMode(MODE_STUN);
return;
}
}
But I was confused by a comment on how to use from the very header of the prop file:
/* Basic blaster prop use.
Default Startup Mode = STUN
Add the following to your config file if so desired:
#define BLASTER_SHOTS_UNTIL_EMPTY 15 (whatever number)
#define BLASTER_JAM_PERCENTAGE if this is not defined, random from 0-100%.
Blaster Buttons: FIRE and MODE
(Blaster is always on with power, unless dedicated Power button is installed.)
Cycle Modes - Click MODE.
Next Preset - Long click and release MODE.
Previous Preset - Double click and hold MODE, release after a second.
Reload - Hold MODE until Reloaded. (Or Click Reload if dedicated button insatlled)
Start/Stop Track - Double click MODE.
Fire - Click FIRE. (Hold to Auto Fire / Rapid Fire)
Clip In - Clip Detect pad Latched On. ( or Hold Momentary button)
Clip out - Clip Detect pad Latched Off. ( or release Momentary button)
Unjam - Bang the blaster.
- If there's a 3rd button for Power,
Power On / Off - Click POWER.
Wavs to use for switching Modes:
mdstun.wav
mdkill.wav
mdauto.wav
- If these are not present, mode.wav will be used for all modes.
- If no mode.wav either, then Talkie voice speaks selected mode.
*/
Yet, I didn’t saw the event handling for EVENTID(BUTTON_FIRE, EVENT_HELD_MEDIUM, MODE_ON): so I assume the writer of the comment never got around to the feature or meant only if auto was enabled. Care to comment on that?
Now, I have a couple of questions of my own:
The prop handles BUTTON_BLADE_DETECT, which is of low utility in a blaster prop. I’m more interested in documenting the BUTTON_CLIP_DETECT or implementing a fourth button for Reload. Since we only have 3 button pins, which other pins could I use for extra buttons?
I don’t think that ProffieOS handles rotary butttons, right? Because there’s a classical use in weapons for the Safe, Semi and Auto lever. For a Blaster Safe/Semi/Auto/Stun could also be done. But I don’t know how would one handle that with a Proffie. I guess that if I could have an event with pressing two buttons at once, for example, I could wire a 4 points lever into a two bit option. Any other ideas?
The goal of blaster.h was never to implement all plecter features. Instead the goal is to implement the features that we want, while being compatible with plecter fonts.
This function doesn’t seem to do anything useful, so just ignore it.
Normally, when there are multiple choices of a looped file (such as hum, lockup or auto) then ProffieOS will choose a random one every time the previous one ends. However, since SelectAutoFirePair will call Select, that won’t happen, instead it will loop the same file over and over until the next time SelctAutoFirePair is called.
Yes, NO_REPEAT_RANDOM should work with all props.
You’re right, I read it wrong.
I didn’t read the comment, I just read the code.
No, I didn’t write that comment.
RX, TX or any of the data pins.
There is some basic handling of rotary buttons in ProffieOS, but there is currently no tie to the blaster prop. Could easily be added though.
Wow! Just wow. Look, I think I want to do some blaster clean up. So, I’m building a blaster test stand. (Wish M2 were available ). If I do that, I think I will try to do two things:
Clean up blaster.h. I think that I can add auto on trigger hold with a define. And want to give some sanity to the power up and down so it can handle a single button.
Now that I see you had your blaster_BC_buttons.h almost ready, I will go over it, and discuss with you any changes, so we can maximize the coordination between blaster.h and your prop.
Then we bring both together if the timing is right. What do you think?
I initially thought the same way, that modifying the default prop was the way to go, but it turns out that it’s probably best left basic, as is. I mean, it should probably support relatively standard things of modern OS, like Volume menu, but still basic functionality should be an option for users.
If you want to develop features and stuff, you should copy it (and any parts from mine you want) and make your own prop.
While saber props are probably more likely to have “all you need” for multiple saber use, I think blasters are a more personalized experience. Or, a less numerous one at least. There’s lots of room for customization, so a personalized prop would be my suggestion. Whether or not you end up wanting to share it with the world or not by submitting it for official ProffieOS use is up to you, but at least you can make it do exactly what you think it should for YOU.
I think “blaster.h” should be fairly basic, sort of like “saber.h”. There is still a lot of room for improvements and cleanup while still leaving it basic though.
Super-advanced, mega-props with menu systems and self-aware tactical AI should probably go in a separate prop file.
Wow! Just wow. Look, I think I want to do some blaster clean up. So, I’m building a blaster test stand. (Wish M2 were available ). If I do that, I think I will try to do two things:
Clean up blaster.h. I think that I can add auto on trigger hold with a define. And want to give some sanity to the power up and down so it can handle a single button.
Now that I see you had your blaster_BC_buttons.h almost ready, I will go over it, and discuss with you any changes, so we can maximize the coordination between blaster.h and your prop.
Then we bring both together if the timing is right. What do you think?
I’ve been through blaster.h and it’s a mess. It even has parts of the deronator code, it defines Range button and effect but does nothing, and even the in-file instructions are nor implemented. When I said cleaning up blade.h, I just meant that. General clean up, comment and may be feature complete (implementing Range and single button use). That’s all. I also think it should be as basic as possible.
). If I do that, I think I will try to do two things: