Adds a HUD for observers
Adds a HUD for rigs and mechs
Adds up/down buttons for AI hud
Add more tg style alerts
Fix some bugs with the tg alerts
Improve icon_states usage by caching it
Redo how respawning works, add a button to ghost hud for it
The default falloff value for sounds is 0.5 (lower means quieter).
There was only 3 things ingame with a sound falloff of a whole whopping 5 (10x)
These things were explosions, telepads, and instruments.
One had a volume of 25%, another one had a volume based on distance threshold, and you can probably guess which one of the bunch had a hardcoded 100% volume.
This adds throw_alert() and /obj/screen/alert, a system that allows you to do custom hud alerts for any variety of things from "You're too cold!" to mecha status indicators for the pilot.
There's quite a few things that actually got replaced; the
fire/oxy/tox/co2 alerts are all now just alerts, as is nutrition. There's also a number of new alerts, such as blindness, highness, legcuffed, buckled, handcuffed, and probably some more I missed; read code/_onclick/hud/alert.dm and see for yourself!
Additionally, a number of tweaks have been done to resisting code, to make it so that there's an indicator when you're buckled or handcuffed, and can just click the alert to start resisting. This includes a refactor that combines the logic for lockers, holders all into one proc, called container_resist().
Also, the health and internals indicator got moved down one tile each. Needed room for the alerts. If we add the oxygen tank action buttons from /tg/ and remove the internals indicator, the health indicator can go back where it was originally.
Alerts, pictured in the top right.
- Instead of using auto_use_power to re-tally up machinery's power usage every cycle, track the steady "static" load separately from the transient "oneoff" usage. Machines then only need to inform the area when they use oneoff power or *change* their steady usage.
- Remove auto_use_power and stop SSmachines from calling it.
- Add vars to track "static" usage for each of the three power channels to /area
- Rename the existing three vars to "oneoff" so its clear what they mean (and to catch people accidentally updating them directly)
- Update area power procs and APCs to use the new variables.
- Rename /area/proc/use_power() to use_power_oneoff() to make it clear what it is doing.
- Deprecate /obj/machinery/use_power() in favor of use_power_oneoff() but don't delete yet. Can transition gradually.
- Add logic to the update_power procs on machines to calculate the deltas and update static area power whenever their usage changes.
- Add logic to machines to update area power when they are created, destroyed, or move.
- Moved /obj/machinery procs related to area power usage into machinery_power.dm to make them easier to find.
- Added or updated comments in several places to explain what is going on and how to use it.
* Port Bay's Catwalks
Allows for various new funtimes.
* Always initialize plated catwalks for you
* Allow climbing up and falling through opened plated catwalks
* 2 catwalk fixes, climbing and decon
* Use turf test helpers
* Update structure loops
- Add additional can_atmos_pass value ATMOS_PASS_PROC which indicates custom behavior requiring calling the CanZASPass proc.
- The benefit being for the other three values we DON'T need to call CanZASPass at all! We already know the behavior without the overhead of a proc call.
- Obviously any atom with can_atmos_pass = ATMOS_PASS_PROC cannot now call ..() in CanZASPass() since the default behavior would be to (recursively) call CanZASPass()
- This required re-numbering the constants, so I also fixed all code that assumed particular values for the constants.
- Switched all types which overrode CanZASPass with custom logic to be can_atmos_pass = ATMOS_PASS_PROC
- Changed /turf/c_airblock() to skip calling /atom/movable/c_airblock() for the three can_atmos_pass values that don't require calling the proc.
- CanZASPass is supposed to return boolean. Nobody noticed this bug because ATMOS_PASS_YES and ATMOS_PASS_NO happen to be defined as 1 and 0. But thats not a good assumption to make, so lets fix it!
* Large amount of work; Animal taming, shearing. Random animal spawns on sif grass/forest turfs. New PoIs, thermal poncho.
* Combat drone DMI moved to drones folder. Mining Drone subtype added. "Tameable" with ores, will collect and store ores when not in active combat.
- Please fasten your seatbelts, this will be a long one as it joins few older Bay PRs into one.
1. Ports https://github.com/Baystation12/Baystation12/pull/12626
- SMES units may now be damaged and destroyed. Charged SMES units fail quite violently. Damage can be fixed by welding tool.
- PSUs completely refactored, ghetto variant no longer exists.
- Cell rack PSUs now can be considered a hybrid between large battery charger and a SMES. They actually use the cells to store power (so you can hot-swap the cells to get more juice simply via the UI without deconstructing the whole machine), but in comparison to SMES have poor throughput and capacity in general (cells are simply too small). They are also somewhat limited in configuration options (lacks the precision electronics of a SMES). Better matter bin lets you put in more cells, up to 9.
- Cell rack PSU also has a mode that allows charge-balancing all inserted batteries (moves energy around so each battery has the same charge %)
2. Ports https://github.com/Baystation12/Baystation12/pull/11977
- SMES units now have full load balancing capability, getting rid of that annoying "One SMES charges at full, other SMES gets nothing" problem. If insufficient power is available on input, all inputting SMESes will now charge at same percentage. If more SMESes power a single output, they will all output equal percentage of their setting.
- This appears to have a pleasant side effect of fixing the issue where SMESes could starve APCs of energy. SMESes are ALWAYS last to input power on a powernet.
- This also appears to have fixed weird values displayed in SMES output/input load readings in the UI. By weird values i mostly mean inputs/outputs actually higher than the SMES is set to have.
3. Ports https://github.com/Baystation12/Baystation12/pull/18137
- SMES units (and subtypes, therefore effectively also PSUs from previous entry) can now have more than one terminal. This effectively allows a setup where two (or more) sources feed a single SMES, which then feeds the output. SMESes can not exceed input setting even with multiple terminals.
- Typical example of use in practice would be SMES that runs something important (for example an AI, telecomms, pick whatever you want). It could have one input from the power grid, and second input from a PACMAN generator set up nearby as a backup. Before the generator would have to be wired into main grid, therefore main grid would siphon off power from it. Now the generator can be separate and dedicated for whatever use you want.
