Feature update

[nomakewan]

This PR removes video game modes from MODE_ORIGINAL, implements rotary firing mode selection inspired by Kaden, implements slime tank cyclotron animation inspired by Kaden, implements all remaining secondary fire modes from the 2009 video game, implements long press for quick vent to perform full manual overheat sequence, enables quick vent by default, removes the now-redundant "venting" fire mode, adds sounds for the ribbon cable switch to replicate sounds seen in Frozen Empire, adjusts some datatypes to reduce RAM usage, adds the bargraph and Frutto barrel arrays to PROGMEM on the wand, updates sound effects, and adds the "thunk" power switch sound to the ion switch power-on sequence in Afterlife and Frozen Empire modes.

It also gets rid of the "SETTINGS" firing mode as it is redundant, and got rid of the b_vg_mode boolean variable in favor of allowing the vgModeCheck() function return a bool all on its own, making the code a bit cleaner. It also cleaned up a few no-longer-used pack serial data commands. Finally, it updates the documentation in accordance with the changes.

[nomakewan]

Okay, the basics should now be covered. A few notes, however. First, the new firing modes, being semi-automatic (that is, they can only fire once per press of the firing button) do not trigger a "FIRING" state on the wand (nor on the pack). Since we do not (yet) have a heat management system in the code this is not a problem. Instead, they simply play an animation on the barrel LEDs, play a sound, and tell the pack to play a sound. Incredibly simple.

The one thing I do not currently like about this arrangement is that there is no change in bargraph animation when firing one of these semi-automatic modes. This is because I do not know what sort of animation would go best here, if any. Again, these are all very brief "pulse" shots, so not a whole lot of time to react (and can be fired with just a moment's press, so the bargraph animation would likewise have to play out immediately rather than being tied to holding down a button like how modeFiring() works). I am open to suggestions and changes. Fixed as of f4cc195

The other thing to note is that I created a function to interpolate the 5-LED animations I wrote for these new firing modes into commands for the 48-LED barrel. This of course gives up some resolution on the barrel, but I feel like for a quick pulse like this it should be acceptable. Once it's time to throw out the existing barrel animation code and remake it, we can focus better on having unique animations that take full advantage of the Frutto barrel's capabilities. That being said, please do test to make sure that it works the way I expect it to, and as with the bargraph issue, feel free to suggest alternative solutions or commit changes.

[nomakewan]

-Meson: The animations for power level 1 do not match the sound effect speed. Power level 4 seems to have a big of hiccup in the animation.

This means that the speed bump for the 48-LED barrel needs to be adjusted, which I figured. Right now I think it's a x10 multiplier which doesn't seem right to me. A 48-LED barrel is essentially just a 12-LED barrel with extra steps, so it's actually 2.4x "longer" across the same distance. However, since I don't have the barrel yet to test, I couldn't fix any existing bugs with it.

-Slime: The regular slime beam is solid green, not sure if this in intentional? Maybe have something pulse through to show some kind of movement? Crossing the streams is yellow?

Uh oh. This means that on the 48-LED barrel, fireStreamEffect is overriding fireStreamStart. Either that or the update rate is so fast that you can't perceive the changes.

-In CTS mode, I can't remember if before when using alt fire, it would play the higher power proton stream sound effect (like the power level 5 one) while intensify would play the weaker one (as it is currently in power levels 1-4).

CTS mode was unaltered by this PR, but yes, the alt fire button always played S_FIRING_LOOP_GB1 regardless of power level.

-Regular menu system: I noticed while the wand is on, you can only enter the menu system while the bottom toggle is up and top toggle is down. Perhaps allow entering it while both top and bottom toggle switches are down?

Ah, simple oversight. I will change that right now.

-For the suggestions for the bargraph animation on the semi auto firing, perhaps you could use the mode original bargraph firing animation routine for these?

Ah, so like a "jump" to the top? I'll give that a shot.

[gpstar81]

The mode original animation routing for firing is random, as in the bargraph scrolls to a random position near it's power level, either above or below.

I wouldn't worry too much about the animation bugs, until you get your barrel in so you can see it in person how things react.

[gpstar81]

Also I think it might be wise to put some kind of debounce on the rotary dial for changing the firing modes. You can easily overload the system by turning it like crazy, particularly the sound effects system and serial system. Maybe perhaps put a stop on it as well so it doesn't loop over to the beginning or end?

[nomakewan]

Also I think it might be wise to put some kind of debounce on the rotary dial for changing the firing modes. You can easily overload the system by turning it like crazy, particularly the sound effects system and serial system. Maybe perhaps put a stop on it as well so it doesn't loop over to the beginning or end?

Easy enough to do. Let me implement both of those right now.

[DustinGrau]

Can you expand on what that means that there's no FIRING state on the wand? Is this changing how a continued button press affects the streams? Or is this just temporary until more logic is worked out?

[nomakewan]

Can you expand on what that means that there's no FIRING state on the wand? Is this changing how a continued button press affects the streams? Or is this just temporary until more logic is worked out?

Using one of the semi-automatic firing modes (Boson Dart, Shock Blast, Slime Tether, Meson Collider) does not change WAND_ACTION_STATUS to ACTION_FIRING. Likewise it does not send a serial datagram to the pack saying that it is firing, which would set the pack's b_wand_firing bool to true. This is because these are instant "pulses" which can only be fired once per button press. Holding down Intensify/BWB does nothing. So since their firing state lasts only a moment, no firing state is currently set.

The stream-type firing modes (Proton Stream, Stasis Stream, Slime Blower, Overload Pulse) work exactly the same way as before, setting WAND_ACTION_STATUS to ACTION_FIRING and sending the serial data message to the pack about its firing state.

[DustinGrau]

Oh, that makes way more sense now, being based on the firing type. I just wanted to be sure that there would still be streams that emit the continued firing state. And I saw the removal of the VENTING state as I presume that will be part of a new set of states for pre-heat/overheat/venting?

[nomakewan]

Oh, that makes way more sense now, being based on the firing type. I just wanted to be sure that there would still be streams that emit the continued firing state. And I saw the removal of the VENTING state as I presume that will be part of a new set of states for pre-heat/overheat/venting?

The "VENTING" state which was removed was the FIRING_MODE one. This is no longer necessary for two reasons.

1. MODE_ORIGINAL only uses CTS/CTS Mix, and so would not be able to access it anyway.
2. Quick Vent now performs a quick vent on a short press, and the full overheat venting sequence when held down. This "long press" version is identical to what the VENTING FIRING_MODE did, so that firing mode is now redundant.

The latest commit makes it so that the rotary firing mode selector cannot go faster than the barrel heat-up animation. This is in fact significantly slower than what was previously allowed when selecting the firing modes was done for the barrel wing button, so I am going to leave it as-is and allow wrap-around. Instituting a "stop" at each end is actually a bit more complicated as you need to keep track of how the user got to each end, plus it means you have to call "modeCheck()" in every single conditional statement rather than just calling it once at the end.

[nomakewan]

Found a missing PROGMEM call in the Frutto 48-LED barrel code and fixed it. Let's see if that fixes the issues with Slime and CTS.

[nomakewan]

Okay, now that I've received a Frutto barrel and had a chance to play around with it, I think all of the bugs are out of it. All firing modes appear to be working correctly, animations appear to be synchronized properly with sounds, colors are what I expect, etc.

Please do give this another test and see if there's anything I might have overlooked.

[DustinGrau]

This is looking fantastic! The only oddity I noticed was that in slime mode the Intensify was the continuous fire/stream while the BWB was the single-shot blast. This was opposite the Stasis and Meson modes--was this intentional to match the games? Personally I prefer the Intensify to be the continuous fire but can understand if it was meant to match the game modes.

[nomakewan]

This is looking fantastic! The only oddity I noticed was that in slime mode the Intensify was the continuous fire/stream while the BWB was the single-shot blast. This was opposite the Stasis and Meson modes--was this intentional to match the games? Personally I prefer the Intensify to be the continuous fire but can understand if it was meant to match the game modes.

You nailed it--this is because of how it worked in the games. Intensify is now the primary firing mode from the game, while the BWB is the alternate firing mode from the game.

[DustinGrau]

Intensify is now the primary firing mode from the game, while the BWB is the alternate firing mode from the game.

In terms of the slime mode vs. the other VG types, was that a mixup that the continuous stream came from the alt fire? I just wanted to be sure I was seeing the right stream or blast from each mode.

[nomakewan]

Intensify is now the primary firing mode from the game, while the BWB is the alternate firing mode from the game.

In terms of the slime mode vs. the other VG types, was that a mixup that the continuous stream came from the alt fire? I just wanted to be sure I was seeing the right stream or blast from each mode.

In the game, the firing modes were as follows:

PROTON Primary Fire: Proton Stream Secondary Fire: Boson Dart (semi-automatic)

DARK MATTER Primary Fire: Shock Blast (semi-automatic) Secondary Fire: Stasis Stream

SLIME Primary Fire: Slime Blower Secondary Fire: Slime Tether (semi-automatic)

PARTICLE Primary Fire: Meson Collider (semi-automatic) Secondary Fire: Overload Pulse

[DustinGrau]

When using the wand rotary dial to change the stream modes, I did notice that (per documentation) it uses a counter-clockwise movement to step through the modes in the order we previously used for the alt fire button. Though in most every case we use a clockwise direction for changing the volume or power higher. Does it make sense to keep our same mode order and use clockwise for consistency?

[nomakewan]

The reason for the change in direction is, once again, linked to the 2009 video game. Video demonstration attached.

https://github.com/gpstar81/GPStar-proton-pack/assets/11485516/240e1bbb-7a0e-4987-b024-98f2755ebecd

I am of course open to thoughts. Might be appropriate for another poll on FB?

[DustinGrau]

Sadly I've not played the games enough to have gotten familiar with all the modes, which is why I'm trying to read the docs before doing more testing. I wasn't aware that even the direction of the dial was accurately linked to in-game actions. And the slime tether was what confused me with that mode. Is there a video that would be a good reference to link which shows each of the stream modes and firing patterns for the unfamiliar among us?

[nomakewan]

Not one that only focuses on the firing modes, no. But I took a short one just now for reference:

I can always take another where I commentate over top or something if that's desired.

[DustinGrau]

If you can work in a link to that video as part of the operation guide related to talking about the VG modes that may be of use. I also found the dedicated wiki pages to the various modes:

• Proton Streams
• Composite Particle System
• Dark Matter Generator
• Plasm Distribution System

[DustinGrau]

I've realized that once this release goes live, I'll plan to work on updating the web UI with the corrected modes. Though if you want to change them to be more accurate that's perfectly fine.

[nomakewan]

I've realized that once this release goes live, I'll plan to work on updating the web UI with the corrected modes. Though if you want to change them to be more accurate that's perfectly fine.

I don't mind changing up the Attenuator code a bit if you don't mind me doing it. Could you refresh my memory as to what exactly on the web UI would need to change? I had a look at the serial datagram for the Pack/Attenuator and didn't see a way for it to tell the pack to change firing modes, but maybe there's something else?

EDIT: Oh I figured it out. Literally the names of the modes. Yeah, I'll take care of it!

[DustinGrau]

Yeah, the function getWandMode() in the Wireless.h states the current mode. If those names changed at all from the ENUM then they'd need to be updated to match.

[nomakewan]

Okay. Attenuator web UI is updated, Operation Guide is updated with links to the wiki as well as a new demo video of the video game modes (I added captions to make it easier to know what was being fired).

Also implemented the "bubbling" slime effect for the cyclotron based on Kaden's awesome work on his TVG pack. It's actually fairly lightweight and straightforward code. I have some potential improvements in mind for the future (especially regarding power-down) but for now this should be a good improvement over the existing implementation.

[Toy203]

Got any video of this new "bubbling effect"? i'm really curious

[nomakewan]

Got any video of this new "bubbling effect"? i'm really curious

Here's Kaden's video showing his original implementation (timestamp included to skip to the relevant part):

[Toy203]

That is nice. They should implement the refill animation so only the bottom two ring turn green then after a few sec the two top one as well as if it was filling up the ciclotron.

[nomakewan]

Filling/draining was an idea I had for later, yes. I'm not sure if I'll have time to implement it right this moment.

[nomakewan]

The problem still persists. The issue is t_cDelay - i_cyclotron_multiplier can end up going negative which then on the unsigned int becomes 65535. It applies to all cyclotron led setups.

While the problem persisting means that the problem still exists and is indeed an underflow, again it cannot possibly be the math specified.

The only two times that equation is used is on lines 2281 and 2309. Please see the entire check containing them:

if(i_cyclotron_multiplier > 1) {
  t_cDelay = t_cDelay - i_cyclotron_multiplier;

  if(t_cDelay < 1 || t_cDelay > cDelay) {
    t_cDelay = 1;
  }
}

Since cDelay, the input to cyclotron2021(uint16_t cDelay) is unaltered prior to this point, then if t_cDelay underflows the second part of the OR statement will trigger and t_cDelay will be set to 1.

I will continue to look through the code and see if I can figure out where an underflow is still being allowed to happen.

[nomakewan]

Okay. Found an additional potential underflow even further down in the code and fixed that. Hopefully now there will be no more shenanigans.

[DustinGrau]

So far it seems to be looking good for me. Cyclotron ramps up to full speed without issue, both the lid and inner cyclotron. Though I've noticed that when in slime mode there's no LEDs lit for the inner cyclotron. Was that intentional or do we want a twinkling effect for the ring as well?

[nomakewan]

So far it seems to be looking good for me. Cyclotron ramps up to full speed without issue, both the lid and inner cyclotron. Though I've noticed that when in slime mode there's no LEDs lit for the inner cyclotron. Was that intentional or do we want a twinkling effect for the ring as well?

It was not intentional, but was an accidental side-effect that I just noticed because it's controlled by the main cyclotron code rather than being its own separate function. I can create a twinling effect for the inner cyclotron ring within the slime effect functions, it'll just use the same randomness as the main cyclotron does. Give me a little bit. Gonna switch to draft in the meantime.

EDIT: Actually, I think it was just an oversight at the end of the cyclotronControl() function. I'll restore it now, we can do fancy animations later when considering how best to use the awesome resolution of those Frutto Max LEDs.

[DustinGrau]

Yup, slime effects are working for the inner cyclotron and the sound ease in/out for that mode appears to be working.

Once this is merged I'll have some updates ready as based on this new code (testing in my fork currently).