- 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.
- 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.
- Set initialized = FALSE on unsimulated turfs that need to intialize.
- Most of area/New() to initialize
- Faster lookup of self-init on atoms
- Split air alarm and fire alarm files, move new to initialize
- Tweak decals and opacity
Co-authored-by: Aronai Sieyes <arokha@arokha.com>
Co-authored-by: Leshana <Leshana@users.noreply.github.com>
- This will let us react to the change appropriately.
- While we're here, lets define some constants so we can stop using bare numbers.
- Always use those constants when calling update_use_power()
* Renaming local var 'machines' to avoid confusion with the global var of same name.
* Delete the unused process scheduler machinery.dm file. Long since replaced with SSmachines
* Split and clarify global lists of processing vs non-processing machinery.
- Renamed the list of processing machinery from "machines" to "processing_machines"
- Added new global list "machines" to be a list of all machines.
- Since nearly every reference to machines actually wanted to iterate over all machines anyway, this works out great.
* This is PHASE 1 of a multi-phase conversion. In this first phase we implement the subsystem, but leave it processing the existing global list variables. In the next phase we will switch to use datum variables in the subsystem. The main reason for splitting into two phases is ease of code review; change the meaningful code without the hundreds of machines -> SSmachines.machinery substitutions.
* We did declare macros for adding/removing things to the processing lists, and convert everywhere to use the macros.
* Added var/is_processing to /datum to keep track of whether an instance is already in a processing list (prevents it being in the list twice!) and also debugging, making sure its not in two lists etc.
* NOTE: The global machines list is **no longer sorted** for performance reasons. As far as I know, the only module that actually ever cared was cameras. Our camera system already handles its own sorting in the cameranets anyway, so it should no longer be needed.
Links many map-specific details such as the station name, z-level information, and allowed jobs from global vars to map datum vars, which should help us maintain multiple maps at once in the future, which will be needed for the future Southern Cross.
Note that a config change will be needed to change GENERATE_ASTEROID to GENERATE_MAP, otherwise no changes should be required to continue normal map usage.
To change to a different map, it's suggested to tick the file that ticks all the other needed files, which for the Northern Star is called northern_star.dm.
'chu heard me. S'what it does. When you're on a call, there's a "Start Video" button next to each person. When you click it, you actually look through their thing, like a ghost might if they ghostcalled. You have to stay within 1 tile of a video showing communicator to see it.
Multiple people can share one communicator video stream by setting it on a table or whatever, and examining it. There's a message like "It appears to be showing a video: [view]" and you can click view and you can all look at the video. COLLABORATION. SYNERGY. OTHER BUZZWORDS.
I also added the feature of DECLINING requests from people.
Also communicators show up on a special camera list on security consoles, but the same EPv2 network visibility turns this off as well if you wanna be all hidey. This does mean that people with the visiblity on serve as sort of roaming AI cameras for the AI as well. So the AI can watch you repair the outside of the station or whatever if you want.
Makes the name of the starsystem and station generic such that it can be modified in global.dm and replace the strings where it is used. This won't have an effect on Polaris itself, but makes changing the name much more simple for forks. Using string concat constants on the advice of Psi.
