I will refactor this next: collider.new will take the linked list to ingest, perform the `insert` and "prevify" loops itself, then replace `hide` with `yoink`, which yoinks the item out of the original list. This pairs the `yoink` operation with the context that makes it possible to do (that is, the context when prevification was implemented); eships therefore cannot be edited in complex ways while the collider is still valid, but we can append to it as long as we don't expect those items to be procesesd correctly this frame. a new_eships+vore plan might be better if we turn out to need it, but presently we don't; flotilla spawning and raider spawning happen at a different point.
causes x offset to reverse for negative aim; may need to be careful
with how I make aiming guns actually work, but this should work for
deriving player guns from enemy guns (by using negative aim)!
I am horrified to admit that C++'s constructor static initialization
list syntax abruptly makes sense to me and I understand the problem
it is trying to solve
I decided to keep cooldown in the same unit as the frame counter,
because the extra math when calculating an upgrade is going to happen
much less frequently than actual cooldown checks and calculations, so
leaving the upgrade logic as the less efficient path seems like the
more appropriate choice.
* any amount of shielding prevents all HP damage
* when shields are sent to 0, orange blip
* all blips are 3 frames
considering a "shimmy" animation for start of shield recovery. maybe later