Bring _HELPERS/_lists.dm to latest standards by:
-Adding proper documentation and fixing existing one
-Giving vars proper names
-Procs now use snake case as per standard (many files that use those procs will be affected)
bring code up to latest standards, move many procs to named files inside _HELPERS
no idea where to put some of these procs, help is appreciated
made more files to contain some unique code, deleted unsorted.dm, we can rest now
## About The Pull Request
stop forgetting to include mapload, if you don't include it then every single subtype past it by default doesn't include it
for example, `obj/item` didn't include mapload so every single item by default didn't fill in mapload
## Regex used:
procs without args, not even regex
`/Initialize()`
procs with args
`\/Initialize\((?!mapload)((.)*\w)?`
cleanup of things i didn't want to mapload:
`\/datum\/(.)*\/Initialize\(mapload`
Merged the item/melee/classic_baton and item/melee/baton families in this unholy matrimony.
Bad jokes aside. I have refactored the underlying code of both items with the scope of reducing potential copypasta,inconsistencies, logging, renewing some old code (like teleprods) and extending the anti-dual batoning and TRAIT_STUNRESISTANCE code** to all batons and not just security ones. Otherwise, I have tried to maintain the gameplay functionality of these items intact. They work just like they did for the most part.
** A badly designed feature that only considers one source of knockdowns - stunbatons - out of a multitude of different devices with corresponding purposes present in the game. The only thing it does is reduce the knockdown from them by 90%. The stamina damage and confusion are fully applied. The knockdown from batons is 5 seconds, standing up takes an extra 1 second and the baton cooldown is about 2.5. Doing the math, you'll have the grand advantage of one puny second of not lying horizontal on the floor with this trait before getting batoned again by the same guy because the stamina damage and the confusion have really hampered your chances of getting some distance. I wish to make the trait suck less in the future, but for now I'm including a slight gameplay change here, more for consistency than anything because as I already told you, it'll still be disappointingly bad per se.
The abductor baton is also no more a subtype of stun batons but batons, which don't use power cells to work. Its power cell is effectively infinite and can't be removed, and It overrides functions such as toggling the baton on/off. It hinders maintainability to keep it a subtype of stun batons.
Replaced the anchored check for mobs in teleprods with one for overwhelming move resistance and removed its clumsy_check copypasta (it was stunning clowns twices).
original pr here: #59789 (Closed because he didn't think it was good enough)
came back to this because i realized that
all machines were area sensitive, meaning they had a list with at least a reference to themselves (assuming they arent in the contents of another movable which most arent) for the purposes of handling power differences when their area changes
pipes are machines
there are ~14k machines and ~6k pipes
i made this problem worse with a recent pr by making it a nested list
so i needed to track what machines needed power, and this pr had work already done that could be used for that purpose. now machines that have use_power == NO_POWER_USE do not have this extra memory overhead for no reason
currently every machine that uses power draws that amount from its area from a dynamic channel via auto_use_power() which is called every SSmachines fire(), then in apc/process() the area's dynamic power draw is reset and the power is used. with static power its not calculated then reset every loop, its just taken from the grid. so now machines handle updating their static power usage from their current area (this doesnt touch power machines that require a wire connection). in order to allow this, use_power, idle_power_usage, and active_power_usage have setters to track state correctly and update the static power usage on the machines current area and handle area sensitivity.
also goes through a lot of heavy abusers of SSmachine processing time and tries to make it faster. makes airalarm/process() into a signal handler for COMSIG_TURF_EXPOSE since air alarms only need to process for changes.
Why It's Good For The Game
SSmachines isnt the heaviest hitter in terms of total cpu and certainly not in terms of overtime, but its not a lightweight. it frequently takes > 50ms to complete a run and seems to be in the top 5 or so of subsystem costs looking at some round profilers
also gets rid of a few thousand lists since every pipe no longer has two useless lists each (and any other machines that dont use power)
Love ya kyler
Co-authored-by: Rohesie <rohesie@gmail.com>
Converts most spans into span procs. Mostly used regex for this and sorted out any compile time errors afterwards so there could be some bugs.
Was initially going to do defines, but ninja said to make it into a proc, and if there's any overhead, they can easily be changed to defines.
Makes it easier to control the formatting and prevents typos when creating spans as it'll runtime if you misspell instead of silently failing.
Reduces the code you need to write when writing spans, as you don't need to close the span as that's automatically handled by the proc.
(Note from Lemon: This should be converted to defines once we update the minimum version to 514. Didn't do it now because byond pain and such)
Having things updating integrity directly is just going to cause more problems down the line as more elements and components depend on being notified of integrity changes. It's an easy mistake to make so making it private should deal with the problem.
get_integrity() might be useful in the future but is mainly a side effect of making obj_integrity private as that also disallows reads.
* Moves explorer adventures to the database.
* Fixes default images not showing up in playtest.
* Review changes.
* Please
* SPACING
* Makes this a bit atomic.
Co-authored-by: Aleksej Komarov <stylemistake@gmail.com>
A new side-job for cargo. Prepare and launch exploration drones at distant sites to encounter weird adventures, collect loot and expand the station cargo network. Adventures - the main content type here, can be written by anyone without any knowledge of programming. The purpose here is creating an way of interesting way of delivering lore (and adding some new job content/cargo expansion method).
Co-authored-by: tralezab <40974010+tralezab@users.noreply.github.com>
Co-authored-by: EOBGames <58124831+EOBGames@users.noreply.github.com>
Co-authored-by: Fikou <piotrbryla@onet.pl>
Co-authored-by: Aleksej Komarov <stylemistake@gmail.com>
