## About The Pull Request
Right now, there are two ways to set the aquarium visual for fish. The
first is to make a small little blob of pixels representing the fish
inside the aquarium, and then set the fish' sprite_width/sprite_height
vars for that little blob of pixels. The second is to set the fish'
source_width/source_height representing the boundaries of the fish
original icon state and then sprite_width/sprite_height to get how much
the icon state will be resized when used as an aquarium visual.
So far so good, except we're only humans, and this sort of stuff can and
will confuse us and overall make the process of adding new fish more
complex. There are quite a few fish that don't have these vars set up in
the right way, so I've decided to butcher out the second method in favor
of the first one. Given the size of the aquarium icon states, this is a
pretty trivial task. Furthermore it works better for fish whose sprites
are coiled or snakey-looking (jumpercables and emulsijack) or on a
diagonal axis.
I've also added an unit test to ensure future contributions don't ever
forget to set the right vars and make an aquarium icon state.
## Why It's Good For The Game
Less confusion, and two less fish variables (they've over 40!).
## Changelog
🆑
fix: fixed a few minor nits with aquarium fish visuals.
/🆑
Loosely adapted from /vg/. This is an entity component system for adding behaviours to datums when inheritance doesn't quite cut it. By using signals and events instead of direct inheritance, you can inject behaviours without hacky overloads. It requires a different method of thinking, but is not hard to use correctly. If a behaviour can have application across more than one thing. Make it generic, make it a component. Atom/mob/obj event? Give it a signal, and forward its arguments with a SendSignal() call. Now every component that want's to can also know about this happening.
Ghom
3a2d4258b2