[Feature]: Optional additional momentary switch on the Attenuator for game mode select.
Opened this issue · 12 comments
What would you like to add in terms of software changes?
Is it possible to add an extra momentary switch on the Attenuator to switch between video game modes? This would allow occasionally switching modes at a con or parade without having to draw the wand and then try to re-hook it. Ideally it would also allow skipping the "overheat" and "command input" modes by using the the Attenuator button even when you are holding the wand. That would give it a feature besides merely duplicating an existing function.
Would this request involve any specific hardware?
There should be open connections on the Attenuator controllers to utilize an additional momentary switch. It shouldn't require anything other than a willingness to mod the Attenuator to have an additional button.
Homework Completed
- I did my part!
We made sure to leave some extra pins available on the Frutto controller board, so I'll need to make sure those will work. If they do, we should have 2 inputs possible as that's all that's possible with the hardware at hand (we used up a LOT of pins for the other inputs and lights, and using the WiFi makes some unavailable).
I'm actually using an Arduino nano for my Attenuator. I should have checked the other boards for open connections. I mistakenly thought the hard part would be whether the software could actually do the job. Sorry, I am a total novice with Arduino so I don't quite follow how the boards communicate with each other and what the limitations are.
This is sounding like a much bigger feature than what was initially requested. I can't implement anything unique to the Attenuator without providing an option via a wand menu. And if we can offer that, then there's not much of a reason to put it into the Attenuator as a physical switch. Now knowing that it's the Nano involved, that platform is unfortunately not really maintained and will be separated into a legacy state once we reach the v6 release, in favor of improving for the ESP32 platform.
Just so it is 100% clear with what I am using, I have the GPStar wand board, an Arduino Mega in the pack, and a Nano in the Attenuator.
So the Attenuator can't just send the message "change to this game mode" and affect the pack and wand then. OK. My thinking was it could have skipped the "overheat" and "control menu" modes to make it different that what the wand already does. If it can't actually tell the other boards "change to this" it won't work then. At least now I know. Thanks for your time.
I realize I should've started with a more direct question: what do you mean by "change to game mode"? I'm also not clear on what you mean by "skipping the overheat" or the "control menu" modes? What release of the software are you currently running?
Right now the only switching we have for "game modes" is the toggles which exist in the config menu system to enable video game colors and is not really a single toggle for on/off, there are numerous devices which can be configured. And the non-proton streams are automatically available when you're in the Super Hero mode, so the only way to limit to just the non-game modes would be to switch to Mode Original. Though I think if you can restate your desire here we could figure out what the feature really is that's being requested--right now there's not a means to do what I think you're asking, which is what I'm slowly realizing.
What he is requesting is a way for the Attenuator (which is running on a Nano in his case) to switch between Proton Stream, Stasis Stream, Slims Blower, and Particle Collider firing modes using a physical switch on the Attenuator. That way he does not need to flip down the top-right switch on the wand and rotate the top knob (for example, when the wand is on the pack V-hook and inaccessible).
I have no clue what he means by "skipping the overheat and command input modes" however. We haven't had those firing modes since...V4, I think? I think you might be right, they might be on a very old software revision.
"to switch between Proton Stream, Stasis Stream, Slims Blower, and Particle Collider firing modes using a physical switch on the Attenuator"
Oh, yeah, if that's the case then we don't have an API set up for that...yet. So my statement of needing to implement more basic functionality stands, regardless of whether we have pins on the hardware to do it.
And yes I'm curious about whether the "skipping" is related to the old menu system which you've very helpfully cleaned up with the new toggle behavior in V5. Which in that case already gives you some pretty direct access to changing the firing modes on the wand with little in the way of user inputs.
"to switch between Proton Stream, Stasis Stream, Slims Blower, and Particle Collider firing modes using a physical switch on the Attenuator"
Yes that is what I was asking. If it can't be done, then now I know. Thanks.
I apologize for the confusion. Apparently I am using an older version of the software that has the menu system cycle through on the wand hat switch when switching through the video game modes. (proton, slime, stasis, meson, optional modes, overheat, control menu) I didn't realize that had been changed. I went through and tweaked a lot of little things (mainly specific color values like making the powercell lights yellow in slime mode like the movie slimeblower) and haven't updated because I didn't want to redo all that. My Attenuator is currently just stand alone so I was looking at updating and integrating it into the pack operation. I read through all the main pages and didn't really notice anything significantly different. I hadn't realized those changes with the mode select. Sorry.
Thanks for taking the time to try and figure out what I was talking about.
It can absolutely be done. There's plenty of I/O available, and the impact on program space and RAM would be negligible to add a single comm message and a little bit of code defining what an input to the I/O should do. If you've tweaked a bunch of your stuff, then heck, you could probably even do something like this yourself.
The question is just a matter of practicality. The actual physical Attenuator isn't my area of expertise or focus, but I'm happy to help interpret your intentions when there's confusion. ;)
I actually really like your idea of changing the Power Cell to match the GB2 slime blower color. I think I'm just gonna go ahead and implement that for 5.3.4 (after all, in TVG the power cell didn't change colors at all).
This is definitely a much larger request, but could lead to some other functionality that's been lacking. I suggest we all take our part in this.
@PetroManGB if you could please update to the latest software, and try out the features for mode switching as described in the operation guide. Report back what works for you with regards to the new mode switching with the top dial, since that avoids the menu and overheat modes formerly handled by the barrel wing button. If that meets your immediate needs then great--if there's another behavior you're not getting out of that feature then please explain in detail the use-case you're wanting and how it differs from the current behavior.
@nomakewan we should move forward with consolidating the API calls across the pack-wand and pack-attenuator, standardizing on the same list of abilities for all devices. There's now so much overlap that if we really need something specific for the attenuator it should be aptly named--otherwise most anything you can do from the wand we should be able to do from the attenuator. It'll just come down to what's been implemented in the Serial.h for each device and just gives a no-op if we're not handling that call.
I'll investigate what to do at the hardware level to add additional physical buttons to the attenuator devices. As I noted, there's only 2 pins we left open and available on the ESP32 platform, and I need to confirm if those might match up to similar pins on the Nano. At this point I'm considering whether these just might become user-defined buttons which would allow you to specify an API call to send to the pack, and just let the user decide what each does (a default could be set for those with the Nano who don't have access to the web UI). Though there would need to be a specific list of options we could handle as some may require additional conditions. In particular, the firing mode change would need to happen when the wand is NOT firing as we have lighting and audio effects that we can't just stop--we have the toggle switch as an interlock which ensures the wand is in an idle state when the firing mode switch occurs.
I'm of course willing to help out however I can. I'll go ahead and slap a v6.0.0 label on this one though, since it seems like it'll be coming along with more of our major system refactors.
I agree that we need to be careful about the timing here; that's why the early trigger was the same as the Hasbro (pressing the wing button but only while the wand is idling), and why the current trigger requires turning the top-right switch off (because by doing so, you cannot possibly fire).
At its most basic, one could make it so that the change can only happen while the wand is not ready to fire (for any reason). This would satisfy OP's request with being able to change firing modes while the wand is on the V-hook and inaccessible. It would however preclude using the Attenuator for changing firing modes while the wand is in your hand and armed, but I would argue that in such a case one would be better served by using the firing mode selection built into the wand itself.
The main thing I was hoping for was the ability to cycle through the game modes while the wand is on the v-hook. I am a total novice with Arduino so I didn't even know if it was possible at all. The skipping the "overheat" and "menu" was just something I figured would be useful for everyone beyond just that. I didn't realize that was already done.
Sounds like it is technically possible but will require a bit of coding well outside my level. Thanks everyone for all your work on this project.