Skip to content

Reserve Backward Transfer UI#286

Open
aquanight wants to merge 8 commits intoblkerby:mainfrom
aquanight:reserve-backfill-ui
Open

Reserve Backward Transfer UI#286
aquanight wants to merge 8 commits intoblkerby:mainfrom
aquanight:reserve-backfill-ui

Conversation

@aquanight
Copy link
Contributor

@aquanight aquanight commented Feb 4, 2026

Improvement of the reserve backward transfer UI: removes the magic key (Up+B with reserve=manual while selecting the MODE indicator - which also now conflicts with disableable e-tanks due to Up moving to the e-tanks)

With mode = MANUAL, press D-Pad Left to move the cursor to the "arrow" and press A to flip it over. Activate the RESERVE TANK item (like you would for normal manual reserve) to transfer from regular energy to reserve. Filling reserve will dump regular energy to 01. Reversed state can be flipped back, and also returns to normal when leaving the equipment menu.

Things to do:

  • Selection sprite for the arrow, or some other way to indicate it is selected.
  • Currently can't select RESERVE TANK at 000 reserve even on [MANUAL]. Can still select if at max reserves, but this much will stay for quick energy dumping.
  • Make arrow not selectable on [AUTO].
  • Currently need to press A to restart reserve transfer when switching direction. Consider auto-resuming transfer (in the new direction).

@aquanight aquanight marked this pull request as ready for review February 6, 2026 02:54
@blkerby
Copy link
Owner

blkerby commented Feb 7, 2026

Very nice. A few things I noticed from testing:

  • Pressing left from a Boots item moves to reserves instead of beams (tested with all items collected).
  • The top-left pixel on the screen glows pink when the arrow is selected. It looks like it's the ball selector sprite.
  • When the arrow is set to backfill, the arrow-head is in need of some clearance from the the Supply box; I'd be interested to see it with the arrow head shifted two pixels left. Similarly, the tail of the arrow could use a couple pixels more space below "Energy".
  • I don't love the pink color of the flashing arrow. The two sets of colors for highlighting the arrow (vanilla yellow and the new pink) feels overall too messy/complicated. When the backfill option is enabled, I think it would be better to just remove all the vanilla cases that make it yellow, and only have it flash yellow when the arrow is selected. The way that vanilla uses the yellow is not a very clear indicator of anything anyway; and you still have the "Auto"/"Manual" text which is more clear, so I don't really imagine players getting confused by the vanilla yellow behavior being taken away.

@aquanight
Copy link
Contributor Author

  • Pressing left from a Boots item moves to reserves instead of beams (tested with all items collected).

I do not touch boots code here. I believe this behavior is due to the Glitch Beam Fix.

  • The top-left pixel on the screen glows pink when the arrow is selected. It looks like it's the ball selector sprite.

Fixed.

  • When the arrow is set to backfill, the arrow-head is in need of some clearance from the the Supply box; I'd be interested to see it with the arrow head shifted two pixels left. Similarly, the tail of the arrow could use a couple pixels more space below "Energy".

Images of the adjustments I could make shared on Discord. Within the rotated arrowhead I only had one pixel of clearance.

  • I don't love the pink color of the flashing arrow. The two sets of colors for highlighting the arrow (vanilla yellow and the new pink) feels overall too messy/complicated. When the backfill option is enabled, I think it would be better to just remove all the vanilla cases that make it yellow, and only have it flash yellow when the arrow is selected. The way that vanilla uses the yellow is not a very clear indicator of anything anyway; and you still have the "Auto"/"Manual" text which is more clear, so I don't really imagine players getting confused by the vanilla yellow behavior being taken away.

The choice of pink was meant to match with the selector and intended to draw on that visual cue (Indeed I used the colors from the selector ball). I'm hoping I can find a solution that is at least intuitive.

What I'm worried about happening is using the vanilla yellow for the selected state won't be particularly obvious that it is selected, or that something different than normal is happening. With a glowing arrow, it'd just look like what it does when the AUTO is highlighted but with no ball selector visible.

I agree, the vanilla behavior is largely unintuitive visual noise: either someone knows what it's "supposed" to be doing and will get confused by it, or has just mentally tuned it out and will get tripped up by assigning new meaning to something previously meaningless.

So my thought process was that keeping the vanilla behavior (and the associated visual noise) and then contrasting it with the selector color makes the new behavior stand out.

I could try changing to repurposing the vanilla glow, but I think in the interest of something that will actually be intuitive to work with... if the arrow seems too clumsy to work with, I have a plan F:

There's one row of buffer space tiles between the SUPPLY and BEAM box. I could just add an entire third line to the SUPPLY box for this.

@blkerby
Copy link
Owner

blkerby commented Feb 7, 2026

I do not touch boots code here. I believe this behavior is due to the Glitch Beam Fix.

Oh right. Funny I never noticed that before. We might want to look into that later; there's probably a less invasive way to prevent glitched beams.

Images of the adjustments I could make shared on Discord. Within the rotated arrowhead I only had one pixel of clearance.

It looks like shifting two pixels should work though maybe I'm missing something (image shared on Discord).

The choice of pink was meant to match with the selector and intended to draw on that visual cue (Indeed I used the colors from the selector ball). I'm hoping I can find a solution that is at least intuitive.

Yeah mainly I think it's just a bit of an unpleasant coloring, and the connection with the selector ball will probably not be generally recognized. What about if we try making it glow gray/white? Then it could kind of match the disableable tanks where we also made the cursor glow gray/white.

So my thought process was that keeping the vanilla behavior (and the associated visual noise) and then contrasting it with the selector color makes the new behavior stand out.

Yeah, it makes sense. I'm not as enthusiastic about the one I proposed after seeing it.

There's one row of buffer space tiles between the SUPPLY and BEAM box. I could just add an entire third line to the SUPPLY box for this.

I think the arrow is pretty neat and intuitive, and I imagine it should work out fine with just a change to the glow color.

@aquanight
Copy link
Contributor Author

Oh right. Funny I never noticed that before. We might want to look into that later; there's probably a less invasive way to prevent glitched beams.

From looking at the vanilla equipment code, I believe a lower touch fix would to do the following in each of the $82:B0C2 (suits) and $82:B150 (boots) routines:

  • $24 = $09A6 early in the routine (right after the "move response" works)
  • After the JSR $B568 (button response), follow with JSR $B068 - this is the Plasma/Spazer check.

Alternative to adding it to those routines would be to add directly to $B568.

This change would cause the Left+A from boots to just toggle plasma/spazer like normal, rather than activating glitch beams.

I think the arrow is pretty neat and intuitive, and I imagine it should work out fine with just a change to the glow color.

New color scheme is up. The new approach uses a custom color sequence, aligned with the pause sprite animation (14 animation frames). It should be relatively simple to adjust the color from here, if needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants