## About The Pull Request
Replaces a ton of `turn(dir, 180)` calls with the aforementioned macro.
## Why It's Good For The Game
Afaik, `REVERSE_DIR` was coded to be faster than the classic `turn(dir,
180)` call, being a simple set of binary operations. To sum it up, micro
optimization.
## Changelog
N/A
## About The Pull Request
Signals were initially only usable with component listeners, which while
no longer the case has lead to outdated documentation, names, and a
similar location in code.
This pr pulls the two apart. Partially because mso thinks we should, but
also because they really aren't directly linked anymore, and having them
in this midstate just confuses people.
[Renames comp_lookup to listen_lookup, since that's what it
does](102b79694f)
[Moves signal procs over to their own
file](33d07d01fd)
[Renames the PREQDELETING and QDELETING comsigs to drop the parent bit
since they can hook to more then just comps
now](335ea4ad08)
[Does something similar to the attackby comsigs (PARENT ->
ATOM)](210e57051d)
[And finally passes over the examine
signals](65917658fb)
## Why It's Good For The Game
Code makes more sense, things are better teased apart, s just good imo
## Changelog
🆑
refactor: Pulled apart the last vestiges of names/docs directly linking
signals to components
/🆑
A long long time ago, when I was but a wee coder, I made the Scrubber
Clog event. I wasn't great at coding then, but about a year later I have
returned to finish what I started.
This PR contains a full code/balance/feature update for the event,
bringing it up to what fledgeling coder Rhials had envisioned but wasn't
experienced enough to do. This contains no fundamental or conceptual
changes, just some TLC.
Since everything's in a new file and there isn't a diff to compare
things with, I'll try to give a quick summary of everything:
FEATURES:
- _The clog event now uses the ventilation pumps instead of scrubbers.
It is now the ventilation clog event. Rejoice._
- Clogs now make a filthy mess when they occur, and make noise when
spawning mobs.
- As more mobs spawn, even more of a mess is made. Different clog event
intensities will produce different messes.
- The mob roster has been updated to include the Mobroach, Mothroach,
and Viscerator for the Strange clog event, and the Hauberroach for the
Major clog event.
CODE:
- The event is now fully self-contained, without requiring any code on
the vent itself to work.
- plunger_act() now has its own signal.
BALANCE (This is just a bunch of tiny insignificant number tweaking
don't worry):
- More mobs can be spawned at once by the event. This shouldn't have any
real impact on how dangerous the minor/major clog events are, but might
make the critical/strange events a smidge more dangerous.
- Max occurrences have been increased. The minor/major clog events are
no longer limited to only three per round.
- There is now a slight chance that a clog event will not announce
itself.
## About The Pull Request
Added a variable to `/obj/` that can be set to adjust the object sprite
when it mapspawns or being wrenched on top of a table.
Set this variable for some popular tabletop machines, removing the
default `pixel_y` offsets for some of them.
Also moved the wrenching logic to /obj/. It was under machinery for some
reason.
## Why It's Good For The Game
Did you ever unwrench something from the table by accident and then was
annoyed that you can't revet it back?
## Changelog
🆑
qol: Objects have a variable to adjust them visually when they're
wrenched or spawned on a table
refactor: Removed redundant code that had similar purpose, moved `obj`
wrenching logic into the `objs.dm`
qol: food/slime processor can be moved on table and adjusts to it when
wrenched
/🆑
## About The Pull Request
Generally cleans up code on both components.
Moves burn proc back to /obj level, I'm not sure why I moved it to /atom
level, it was unnecessary.
Acid component generalized so it can be used on any atom that uses
atom_integrity.
Fixes a bug where objects that stopped burning didn't update their burn
overlay properly due to bad removal logic and leftover code.
Standardizes examine messages on burning items by just slapping an
examine signal registration on the component.
Adds fire particles to items thanks to Lemon's PR:
https://github.com/tgstation/tgstation/pull/74524
## Why It's Good For The Game
Particles look cool
Bugfixes are good
Code improvements are good
## Changelog
🆑
add: Burning items now get (small) smoke particles. Sick.
fix: Burning objects now clear their burning overlay properly.
qol: Examining burning objects will always tell you that they are
burning.
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
Removes network_id as it was completely unused now.
Also reworks the maints access secret buttons to work with how accesses
work now, taking into account req_one_access. This is theoretically a
problem when we moved to req_one_access more often in maints so
departments can access their own maint areas.
## Why It's Good For The Game
This is just minor changes I found while trying to edit other things,
and thought I should PR it.
## Changelog
🆑
admin: Secret buttons for Engineering/Brig maint accesses should now
work more consistently.
/🆑
## About The Pull Request
This is a continuation of
https://github.com/tgstation/tgstation/pull/74085 - I announced in the
comments there that this would be my next PR, and this is it.
Removes SSnetwork, ``/datum/ntnet``,
``/datum/component/ntnet_interface``, ``var/network_root_id``, the
network unit test, and a lot of other things related to networks.
- NTNet circuits now check for an Ntnet relay, and uses signals to
operate.
- Logs in Wirecarp is now only for PDA and Ntnet Relay things, so you
can no longer see what ruins exist using it (why should Wirecarp know
that Oldstation spawned? The flavor is that they dont know its there).
- Removed it from MULEbots entirely, I don't think it even did anything
for them? Botkeeper seems to work without it, so it's possibly there
from pre-tgui PDAs.
- Moves assigning random names to a base proc instead of being tied to
network, this is things like random-naming scrubbers/vents. The behavior
hasn't changed at all.
- Makes Ntos work for consoles when relays are down, as the comments
said they're supposed to (because they're wired). I think this was an
accidental change on my part, so this is a revert of that.
## Why It's Good For The Game
Ntnet is ancient code that hasn't given us much that we can't do with
already existing alternatives, we've been slowly moving away from it for
init times, and though a large portion of that was limited to airlocks,
I still don't think this is a system worth keeping around.
It's way too complex to expect feature coders to do anything with it,
and too old with better alternatives for anyone to want to improve any
of it.
## Changelog
🆑
fix: Computers are now properly connected to Ethernet, and can use Ntos
when Relays are down.
refactor: Removes Ntnet and Ntnet interfaces, which was only used by
Ntnet circuits (which now directly checks for a Relay to work) and
MULEbots, which did nothing with it.
balance: Wirecarp no longer tells you what ruins spawned in a round,
instead it's limited to PDA logs, and tells you the source too. This
means the RD can catch someone running illegal programs if they don't
make any attempt at hiding it.
qol: Wirecarp logs is now set to save 300 at once, instead of 100 and
being increased to 300 by the RD during the round. This is pretty
insignificant, since there's no reason to NOT want as many logs as
possible.
/🆑
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
Although all objects that _have_ the flag attach it to
`resistance_flags` (which is what the define location implies it's
supposed to be set on), all the code that checked it for the purposes of
applying the freezing element used `obj_flags`.
As far as I can tell, that meant the only things immune to freezing were
things that "blocked z falling from above".
Also, freezing only happens with some obscure weapons and low
temperature water vapour, but hey 🤷.
🆑 coiax
fix: Coffee cups are now correctly immune to becoming frozen by low
temperature water vapour.
/🆑
---
Shout out to RaveRadbury who helped me with debugging this.
This builds on what #69790 did and improved the code even further.
Notable things:
- `Topic()` is a deprecated proc in our codebase (replaced with
Javascript tgui) so it makes sense to rename `canUseTopic` to
`can_perform_action` which is more straightforward in what it does.
- Positional and named arguments have been converted into a easier to
use `action_bitflag`
- The bitflags adds some new checks you can use like: `NEED_GRAVITY |
NEED_LITERACY | NEED_LIGHT` when you want to perform an action.
- Redundant, duplicate, or dead code has been removed.
- Fixes several runtimes where `canUseTopic` was being called without a
proper target (IV drips, gibber, food processor)
- Better documentation for the proc and bitflags with examples
## About The Pull Request
Part of a prior PR that was closed (#72562). This version does not add
the check in CI.
## Why It's Good For The Game
The work is already done, so I figured why not.
## Changelog
N/A Nothing player facing
Co-authored-by: Jeremiah Snow <jlsnow301@pm.me>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Hey there,
Now that every instance of `req_access` and `req_one_access` is a list
of strings, there is absolutely no reason for
req_access_txt/req_access_one_txt to exist. In fact, any instance where
they were still used in the codebase was very convoluted and was very
broken! Don't worry, I fixed it all out, and life is good.
I also dmdoc the surviving access variables, because those were missing.
I went on the side of caution and made a more verbose documentation with
an example just to have people really grasp this (it took me a while to
actually get it)
I believe that we changed _everything_ over to the
req_access/req_one_access system earlier this year in VV, but the
problem is that _new mappers don't understand the difference between the
two systems_. In fact, the "txt" system is completely redundant since
all it does is transition stuff to the "base" system. So, let's just
completely cull the one that's all but deprecated and ensure this
confusion no longer arises. The whole purpose of "txt" seemed to be to
convert the access, but it's all pointless now that we can just read the
list directly.
I'm also 99% certain that the "access check" on vending machines broke
(and didn't seem to have correct logic in the first place? I
legitimately couldn't find a case where it could fail in testing, so I
changed that up), and that's fixed up now. Let me know if I was clueless
there. I know it's short-circuiting now as opposed to "all must be
true", but it just didn't work.
## About The Pull Request
Updated crafting menu, adding a lot of new functions and recipes that
were not in the crafting menu before.
<img alt="cult"
src="https://user-images.githubusercontent.com/3625094/206009533-aec3a1dd-cbe5-45eb-8515-1b75fabb65c5.PNG">
<img alt="nH77dLyyGx"
src="https://user-images.githubusercontent.com/3625094/206009786-b6706f70-0599-40bf-b051-8f499de43abd.png">
https://user-images.githubusercontent.com/3625094/206009841-738e4a03-0660-45b7-8d83-15eeb6501967.mp4
## Why It's Good For The Game
It is easier to use, and it has a lot of recipes that were spread
throughout the game, some of which weren't even on the wiki.
Crafting and cooking now count about 1200 recipes in total, including
conditionally available ones.
## Changelog
🆑
qol: Rewrote the crafting/cooking menu UI
qol: Split crafting and cooking menus in two different menus
qol: Crafting is no longer blocking the entire UI, only the "Make"
buttons are disabled
qol: Added stack crafting recipes to the crafting menu
qol: Added cooking recipes that were absent in the crafting menu before
(tool recipes, machine recipes, reactions)
qol: Added option to search recipes by title
qol: Added option to filter recipes by required materials/ingredients
qol: Added food types to the cooking menu, highlighting diet of your
species (liked, disliked foods)
qol: Added total nutrition value of the result to the cooking menu
qol: Added option to filter cooking recipes by the food type of the
resulting food
qol: Added "Can make" category that lists all currently craftable
recipes throughout all categories
refactor: changed categories and reshuffled some items in them
code: Reagents now have default container to get an icon from the
reagent datum
code: Objects now have `desc_controls` var for OOC information about
mouse controls that are visible on examine, but not in the description
fix: Fixed alignment on many food icons
fix: Fixed missing icon for beef stroganoff
/🆑
Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com>
## About The Pull Request
Neutral pride pin quirk added. Pride pins can be infinitely reskinned
now. Changes "sexuality" to "pride" in description of pin.
## Why It's Good For The Game
Pride pins are cute and having to buy them every round is a chore. Pride
pins are purely cosmetic and have no reason to be locked into only being
reskinned once.
## Changelog
🆑
add: Pride pin quirk! Start the shift off with a pride pin in-hand.
qol: Pride pins can be infinitely reskinned now.
/🆑
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
More than a decade ago, these were all coded to use a weird dynamic list
radio broadcasting system to communicate with each other. If there was
any depth that they were planning on creating with this, it didn't come
to fruition, and it instead just wasted a lot of init time.
Removing `post_signal` saves 198.41ms, fired 588 times from lots of
different machinery. Its self cost was 81.44ms.
`broadcast_status`, also removed, was taking 218ms.
I'm pretty sure I'm done with this, but it's hard to tell given the
nature of old radio signal code.
A small self cost of 34.9ms was added in the form of /obj/Initialize
checking id_tag to set in a global list. This could be optimized away by
tagging everything that does use id_tag, but it's a loooot and I think
this is just a useful mechanism to have. Not worth it IMO.
The "Check Atmos Chamber Devices" verb has been removed. Everything it
did *should* be replicated by runtimes on Initialize, which is both more
obvious to mappers and shows up in unit tests since we spawn every ruin.
Makes the code compatible with 515.1594+
Few simple changes and one very painful one.
Let's start with the easy:
* puts call behind `LIBCALL` define, so call_ext is properly used in 515
* Adds `NAMEOF_STATIC(_,X)` macro for nameof in static definitions since
src is now invalid there.
* Fixes tgui and devserver. From 515 onward the tmp3333{procid} cache
directory is not appened to base path in browser controls so we don't
check for it in base js and put the dev server dummy window file in
actual directory not the byond root.
* Renames the few things that had /final/ in typepath to ultimate since
final is a new keyword
And the very painful change:
`.proc/whatever` format is no longer valid, so we're replacing it with
new nameof() function. All this wrapped in three new macros.
`PROC_REF(X)`,`TYPE_PROC_REF(TYPE,X)`,`GLOBAL_PROC_REF(X)`. Global is
not actually necessary but if we get nameof that does not allow globals
it would be nice validation.
This is pretty unwieldy but there's no real alternative.
If you notice anything weird in the commits let me know because majority
was done with regex replace.
@tgstation/commit-access Since the .proc/stuff is pretty big change.
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* canUseTopic now uses TRUE/FALSE instead of defines that just say TRUE
The most idiotic thing I've seen is canUseTopic's defines, they literally just define TRUE, you can use it however you want, it doesn't matter, it just means TRUE. You can mix and match the args and it will set that arg to true, despite the name.
It's so idiotic I decided to remove it, so now I can reclaim a little bit of my sanity.
About The Pull Request
I've reworked multiz. This was done because our current implementation of multiz flattens planes down into just the openspace plane. This breaks any effects we attach to plane masters (including lighting), but it also totally kills the SIDE_MAP map format, which we NEED for wallening (A major 3/4ths resprite of all wall and wall adjacent things, making them more then one tile high. Without sidemap we would be unable to display things both in from of and behind objects on map. Stupid.)
This required MASSIVE changes. Both to all uses of the plane var for reasons I'll discuss later, and to a ton of different systems that interact with rendering.
I'll do my best to keep this compact, but there's only so much I can do. Sorry brother.
Core idea
OK: first thing.
vis_contents as it works now squishes the planes of everything inside it down into the plane of the vis_loc.
This is bad. But how to do better?
It's trivially easy to make copies of our existing plane masters but offset, and relay them to the bottom of the plane above. Not a problem. The issue is how to get the actual atoms on the map to "land" on them properly.
We could use FLOAT_PLANE to offset planes based off how they're being seen, in theory this would allow us to create lens for how objects are viewed.
But that's not a stable thing to do, because properly "landing" a plane on a desired plane master would require taking into account every bit of how it's being seen, would inherently break this effect.
Ok so we need to manually edit planes based off "z layer" (IE: what layer of a z stack are you on).
That's the key conceit of this pr. Implementing the plane cube, and ensuring planes are always offset properly.
Everything else is just gravy.
About the Plane Cube
Each plane master (except ones that opt out) is copied down by some constant value equal to the max absolute change between the first and the last plane.
We do this based off the max z stack size detected by SSmapping. This is also where updates come from, and where all our updating logic will live.
As mentioned, plane masters can choose to opt out of being mirrored down. In this case, anything that interacts with them assuming that they'll be offset will instead just get back the valid plane value. This works for render targets too, since I had to work them into the system as well.
Plane masters can also be temporarily hidden from the client's screen. This is done as an attempt at optimization, and applies to anything used in niche cases, or planes only used if there's a z layer below you.
About Plane Master Groups
BYOND supports having different "maps" on screen at once (IE: groups of items/turfs/etc)
Plane masters cannot cover 2 maps at once, since their location is determined by their screen_loc.
So we need to maintain a mirror of each plane for every map we have open.
This was quite messy, so I've refactored it (and maps too) to be a bit more modular.
Rather then storing a list of plane masters, we store a list of plane master group datums.
Each datum is in charge of the plane masters for its particular map, both creating them, and managing them.
Like I mentioned, I also refactored map views. Adding a new mapview is now as simple as newing a /atom/movable/screen/map_view, calling generate_view with the appropriate map id, setting things you want to display in its vis_contents, and then calling display_to on it, passing in the mob to show ourselves to.
Much better then the hardcoded pattern we used to use. So much duplicated code man.
Oh and plane master controllers, that system we have that allows for applying filters to sets of plane masters? I've made it use lookups on plane master groups now, rather then hanging references to all impacted planes. This makes logic easier, and prevents the need to manage references and update the controllers.
image
In addition, I've added a debug ui for plane masters.
It allows you to view all of your own plane masters and short descriptions of what they do, alongside tools for editing them and their relays.
It ALSO supports editing someone elses plane masters, AND it supports (in a very fragile and incomplete manner) viewing literally through someone else's eyes, including their plane masters. This is very useful, because it means you can debug "hey my X is yorked" issues yourself, on live.
In order to accomplish this I have needed to add setters for an ungodly amount of visual impacting vars. Sight flags, eye, see_invis, see_in_dark, etc.
It also comes with an info dump about the ui, and plane masters/relays in general.
Sort of on that note. I've documented everything I know that's niche/useful about our visual effects and rendering system. My hope is this will serve to bring people up to speed on what can be done more quickly, alongside making my sin here less horrible.
See https://github.com/LemonInTheDark/tgstation/blob/multiz-hell/.github/guides/VISUALS.md.
"Landing" planes
Ok so I've explained the backend, but how do we actually land planes properly?
Most of the time this is really simple. When a plane var is set, we need to provide some spokesperson for the appearance's z level. We can use this to derive their z layer, and thus what offset to use.
This is just a lot of gruntwork, but it's occasionally more complex.
Sometimes we need to cache a list of z layer -> effect, and then use that.
Also a LOT of updating on z move. So much z move shit.
Oh. and in order to make byond darkness work properly, I needed to add SEE_BLACKNESS to all sight flags.
This draws darkness to plane 0, which means I'm able to relay it around and draw it on different z layers as is possible. fun darkness ripple effects incoming someday
I also need to update mob overlays on move.
I do this by realiizing their appearances, mutating their plane, and then readding the overlay in the correct order.
The cost of this is currently 3N. I'm convinced this could be improved, but I've not got to it yet.
It can also occasionally cause overlays to corrupt. This is fixed by laying a protective ward of overlays.Copy in the sand, but that spell makes the compiler confused, so I'll have to bully lummy about fixing it at some point.
Behavior changes
We've had to give up on the already broken gateway "see through" effect. Won't work without managing gateway plane masters or something stupid. Not worth it.
So instead we display the other side as a ui element. It's worse, but not that bad.
Because vis_contents no longer flattens planes (most of the time), some uses of it now have interesting behavior.
The main thing that comes to mind is alert popups that display mobs. They can impact the lighting plane.
I don't really care, but it should be fixable, I think, given elbow grease.
Ah and I've cleaned up layers and plane defines to make them a bit easier to read/reason about, at least I think.
Why It's Good For The Game
<visual candy>
Fixes#65800Fixes#68461
Changelog
cl
refactor: Refactored... well a lot really. Map views, anything to do with planes, multiz, a shit ton of rendering stuff. Basically if you see anything off visually report it
admin: VV a mob, and hit View/Edit Planes in the dropdown to steal their view, and modify it as you like. You can do the same to yourself using the Edit/Debug Planes verb
/cl
* Optimizes away /obj/Initialize
We were spending like 0.15 seconds just checking for blueprints, obj
flags and network ids
All these things can just be applied where they're wanted, saves time
Oh and I replaced object flags with an emag injector. I'll give it a
sprite and name later I promise
* Requires a GenerateTag() call to set DF_USE_TAG, rather then doing a check in atom New
This is technically harder to use, but I don't really want people using
tags, and it saves 0.15 seconds
* Moves generatetag to /datum
* I am dumb
* Saves 0.5 seconds, makes init emissive blockers actually work
Ok so background. If an overlay is added with add_overlay, and not
"managed" somehow, it will effectively never be removed, because
nothing's tracking it.
Update_overlays uses the managed_overlays list/var (one of those) to do
this.
I'm gonna piggyback off this to make emissive overlays actually like,
respect overlay updates.
Oh and uh, I've saved maybe 0.5 seconds by caching the new emissive, and
not using add_overlay. There's a chance this will lead to overlay
corruption, but since we never readd the flattened, I think we'll be
safe
* Fixes plane not being set right, changes color logic too, since alpha will override past color sets
* Makes it actually work. also makes rand posters update appearance to clear away the overlay, since it shows on right click and looks bad
* Fixes blockers showing as emissives. It turns out alpha sets override the color list we use. Not sure why we pretend to support them
* Makes the injector support traits, adds an amazing sprite
* - Fixes storage mass transfer
- Brings some sanity to storage procs
- Implements a griddle feature that never was
* Uncomment this
* Right-click attack fix
* Scoop fix
* Smartfridges use silent
* Restores some lost checks
* Fixes storage implants
* Removes ComponentInitialize()
Completely removes ComponentInitialize() as a proc, which was called on every single atom in the game, twice in some instances (like new players), over something that can already be done with Initialize().
This is the second attempt at doing this, after the first attempt fell apart for some reason. This time it was way easier though, since storages are no longer a Component.
* update icon blocker added before calling parent
* Update code/game/machinery/porta_turret/portable_turret.dm
Co-authored-by: san7890 <the@san7890.com>
* adds a mapload while I'm here
* moves human mood
* Does some UNRELATED thing to the PR
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
* On the storage datum, properly registers secondary singals to their own secondary procs to handle the different stuff they do.
* Fixes click & drag storage containers by calling them on where they are supposed to be moved to using atom_storage.
ever see the tram take 10 milliseconds per movement to move 2100 objects? now you have
https://user-images.githubusercontent.com/15794172/166198184-8bab93bd-f584-4269-9ed1-6aee746f8f3c.mp4
About The Pull Request
fixes#66887
done for the code bounty posted by @MMMiracles to optimize the tram so that it can be sped up. the tram is now twice as fast, firing every tick instead of every 2 ticks. and is now around 10x cheaper to move. also adds support for multiz trams, as in trams that span multiple z levels.
the tram on master takes around 10-15 milliseconds per movement with nothing on it other than its starting contents. why is this? because the tram is the canary in the coal mines when it comes to movement code, which is normally expensive as fuck. the tram does way more work than it needs to, and even finds new ways to slow the game down. I'll walk you through a few of the dumber things the tram currently does and how i fixed them.
the tram, at absolute minimum, has to move 55 separate industrial_lift platforms once per movement. this means that the tram has to unregister its entered/exited signals 55 times when "the tram" as a singular object is only entering 5 new turfs and exiting 5 old turfs every movement, this means that each of the 55 platforms calculates their own destination turfs and checks their contents every movement. The biggest single optimization in this pr was that I made the tram into a single 5x11 multitile object and made it only do entering/exiting checks on the 5 new and 5 old turfs in each movement.
way too many of the default tram contents are expensive to move for something that has to move a lot. fun fact, did you know that the walls on the tram have opacity? do you know what opacity does for movables? it makes them recalculate static lighting every time they move. did you know that the tram, this entire time, was taking JUST as much time spamming SSlighting updates as it was spending time in SStramprocess? well it is! now it doesnt do that, the walls are transparent. also, every window and every grille on the tram had the atmos_sensitive element applied to them which then added connect_loc to them, causing them to update signals every movement. that is also dumb and i got rid of that with snowflake overrides. Now we must take care to not add things that sneakily register to Moved() or the moved signal to the roundstart tram, because that is dumb, and the relative utility of simulating objects that should normally shatter due to heat and conduct heat from the atmosphere is far less than the cost of moving them, for this one object.
all tram contents physically Entered() and Exited() their destination and old turfs every movement, even though because they are on a tram they literally do not interact with the turf, the tram does. also, any objects that use connect_loc or connect_loc behalf that are on the same point on the tram also interact with each other because of this. now all contents of the tram act as if theyre being abstract_move()'d to their destination so that (almost) nothing thats in the destination turf or the exit turf can react to the event of "something laying on the tram is moving over you". the rare things that DO need to know what is physically entering or exiting their turf regardless of whether theyre interacting with the ground can register to the abstract entered and exited signals which are now always sent.
many of the things hooked into Moved(), whether it be overrides of Moved() itself, or handlers for the moved signal, add up to a LOT of processing time. especially for humans. now ive gotten rid of a lot of it, mostly for the tram but also for normal movement. i made footsteps (a significant portion of human movement cost) not do any work if the human themselves didnt do the movement. i optimized has_gravity() a fair amount, and then realized that since everything on the tram isnt changing momentum, i didnt actually need to check gravity for the purposes of drifting (newtonian_move() was taking a significant portion of the cost of movement at some points along the development process). so now it simply doesnt call newtonian_move() for movements that dont represent a change in momentum (by default all movements do).
also i put effort into 1. better organizing tram/lift code so that most of it is inside of a dedicated modules folder instead of scattered around 5 generic folders and 2. moved a lot of behavior from lift platforms themselves into their lift_master_datum since ideally the platforms would just handle moving themselves, while any behavior involving the entire lift such as "move to destination" and "blow up" would be handled by the lift_master_datum.
also
https://user-images.githubusercontent.com/15794172/166220129-ff2ea344-442f-4e3e-94f0-ec58ab438563.mp4
multiz tram (this just adds the capability to map it like this, no tram does this)
Actual Performance Differences
to benchmark this, i added a world.Profile(PROFILER_START) and world.Profile(PROFILER_START) to the tram moving, so that it generates a profiler output of all tram movement without any unrelated procs being recorded (except for world.Profile() overhead). this made it a lot easier to quantify what was slowing down both the tram and movement in general. and i did 3 types of tests on both master and my branch.
also i should note that i sped up the "master" tram test to move once per tick as well, simply because the normal movement speed seems unbearably slow now. so all recorded videos are done at twice the speed of the real tram on master. this doesnt affect the main thing i was trying to measure: cost for each movement.
the first test was the base tram, containing only my player mob and the movables starting on the tram roundstart. on master, this takes around 13 milliseconds or so on my computer (which is pretty close to what it takes on the servers), on this branch, it takes between 0.9-1.3 milliseconds.
ALSO in these benchmarks youll see that tram/proc/travel() will vary significantly between the master and optimized branches. this is 100% because there are 55 times more platforms moving on master compared to the master branch, and thus 55x more calls to this proc. every test was recorded with the exact same amount of distance moved
here are the master and optimized benchmark text files:
master
master base tram.txt
https://user-images.githubusercontent.com/15794172/166210149-f118683d-6f6d-4dfb-b9e4-14f17b26aad8.mp4
also this shows the increased SSlighting usage resulting from the tram on master spamming updates, which doesnt happen on the optimized branch
optimized
optimization base tram.txt
https://user-images.githubusercontent.com/15794172/166206280-cd849aaa-ed3b-4e2f-b741-b8a5726091a9.mp4
the second test is meant to benchmark the best case scaling cost of moving objects, where nothing extra is registered to movement besides the bare minimum stuff on the /atom/movable level. Each of the open tiles of the tram had 1 bluespace rped filled with parts dumped onto it, to the point that the tram in total was moving 2100 objects. the vast majority of these objects did nothing special in movement so they serve as a good base case. only slightly off due to the rped's registering to movement.
on master, this test takes over 100 milliseconds per movement
master 2000 obj's.txt
https://user-images.githubusercontent.com/15794172/166210560-f4de620d-7dc6-4dbd-8b61-4a48149af707.mp4
when optimized, about 10 milliseconds per movement
https://user-images.githubusercontent.com/15794172/166208654-bc10086b-bbfc-49fa-9987-d7558109cc1d.mp4
optimization 2000 obj's.txt
the third test is 300 humans spawned onto the tram, meant to test all the shit added on to movement cost for humans/carbons. in retrospect this test is actually way too biased in favor of my optimizations since the humans are all in only 3 tiles, so all 100 humans on a tile are reacting to the other 99 humans movements, which wouldnt be as bad if they were distributed across 20 tiles like in the second test. so dont read into this one too hard.
on master, this test takes 200 milliseconds
master 300 catgirls.txt
when optimized, this takes about 13-14 milliseconds.
optimization 300 catgirls on ram ranch.txt
Why It's Good For The Game
the tram is literally 10x cheaper to move. and the code is better organized.
currently on master the tram is as fast as running speed, meaning it has no real relative utility compared to just running the tracks (except for the added safety of not having to risk being ran over by the tram). now the tram of which we have an entire map based around can be used to its full potential.
also, has some fixes to things on the tram reacting to movement. for example on master if you are standing on a tram tile that contains a banana and the TRAM moves, you will slip if the banana was in that spot before you (not if you were there first however). this is because the banana has no concept of relative movement, you and it are in the same reference frame but the banana, which failed highschool physics, believes you to have moved onto it and thus subjected you to the humiliation of an unjust slipping. now since tram contents that dont register to abstract entered/exited cannot know about other tram contents on the same tile during a movement, this cannot happen.
also, you no longer make footstep sounds when the tram moves you over a floor
TODO
mainly opened it now so i can create a stopping point and attend to my other now staling prs, we're at a state of functionality far enough to start testmerging it anyways.
add a better way for admins to be notified of the tram overloading the server if someone purposefully stuffs it with as much shit as they can, and for admins to clear said shit.
automatically slow down the tram if SStramprocess takes over like, 10 milliseconds complete. the tram still cant really check tick and yield without introducing logic holes, so making sure it doesnt take half of the tick every tick is important
go over my code to catch dumb shit i forgot about, there always is for these kinds of refactors because im very messy
remove the area based forced_gravity optimization its not worth figuring out why it doesnt work
fix the inevitable merge conflict with master lol
create an icon for the tram_tunnel area type i made so that objects on the tram dont have to enter and exit areas twice in a cross-station traversal
add an easy way to vv tram lethality for mobs/things being hit by it. its an easy target in another thing i already wanted to do: a reinforced concept of shared variables from any particular tram platform and the entire tram itself. admins should be able to slow down the tram by vv'ing one platform and have it apply to the entire tram for example.
Changelog
cl
balance: the tram is now twice as fast, pray it doesnt get any faster (it cant without raising world fps)
performance: the tram is now about 10 times cheaper to move for the server
add: mappers can now create trams with multiple z levels
code: industrial_lift's now have more of their behavior pertaining to "the entire lift" being handled by their lift_master_datum as opposed to belonging to a random platform on the lift.
/cl
Adds a modifier variable which can be used to increase or decrease a given items damage to structures, machinery, vehicles, and robots (including cyborgs, simple-bots, and anything else with the MOB_ROBOTIC biotype)
* AtmoZphere tablet app now has the previous functionality of the BreatheDeep cartridge's scanning ability, meaning you can swap to analyzer mode to analyze with right-click.
Extends CanAStarPass to atom level and allows turfs to specify their pass check method to speed this up a bit.
Allows pathing over openspace with lattices/by flying things, otherwise disallowed.
Solves issue with diagonal movement where diagonal movement first step would use turf that was marked as impassable in pathfinder by splitting invalid diagonal move into valid orthogonal ones. In most cases this is pretty inconsequential but for openspace/other dangerous non-dense tiles it's pretty important.
About The Pull Request
https://imgur.com/a/pMMEi4ihttps://imgur.com/a/xCrIcz4
Title, really.
Adds an ingame guide to atmos. Currently hooked to the atmos monitors, analyzer, and the tablet app.
Lots of reaction data not implemented yet, banking on the cleanup to get merged first, so drafting.
Done, all reactions in. Haven't double checked them though.
Code is pretty much finished, feel free to take a look. Ill probably retidy them while adding stuffs so no rush.
Might add a reaction handbook obj later Implemented in analyzer.
Dotted tooltip idea shamelessly stolen from preferences.
Lots of the diffs are from breaking the sensor file up, dont worry about it.
Why It's Good For The Game
Less need to open the wiki in another page I guess.
Changelog
cl
add: Added an ic atmos reaction guide. Available in your atmos control consoles/monitors, ntosatmos app, and analyzer.
code: Some changes to how gas canister descriptions are generated.
/cl
Implements the Modernizing radiation design document ( https://hackmd.io/@tgstation/rJNIyeBHt ) and replaces the current radiation sources with the new system, as well as replacing/removing a bunch of old consumers of radiation that either had no reason to exist, or could be replaced by something else.
Diverges from the doc in that items radiation don't go up like explained. I was going to, but items get irradiated so easily that it just feels pretty lame. Items still get irradiated, but it's mostly just so that radiation sources look cooler (wow, lots of stuff around going green), and for things like the geiger counter.
Instead of the complicated radiation_wave system, radiation now just checks everything between the radiation source and the potential target, losing power along the way based on the radiation insulation of whats in between. If this reaches too low a point (specified by radiation_pulse consumers), then the radiation will not pass. Otherwise, will roll a chance to irradiate. Uranium structures allow a delay before irradiating, so stay away!
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)
Fixes a ton of harddels, sourced from #59996
I think this brings us down to like, ~100 per round from ~200, with only like 20 of those being proper hell failures. I've seen harddel profiles below 1 second of total cost. Feeling good.
See you on the other side
Makes the cryopod control computer into a weakref, never trust bee code
Converts brig door timer internal lists to weakrefs
Fixes a harddel caused by qdeling a motion sensitive camera after it had left its source area, jesus christ why didn't we do this already holy shit
Converts the radio implant ref held by the antenna mutation to weakrefs because it isn't reliably cleaned up, makes the radio implant actually qdel its fucking radio
Removes the target var from the throwing datum, it does literally nothing and just exists to cause harddels, mostly for the singularity
Fixes a cable harddel sourced from things that try to enter blueprints after smoothing, but before roundstart. IE, shuttles. Removes shuttles from the blueprints
Fixes emmisive blockers being added post qdel
Removes some manual ghosting from cryopods, I initially did this for harddel reasons, but I figured out a better fix for that. I'm now doing it because it's got this really strange logic for like "re-entering the game" that doesn't actually link to what the ghostize proc does. We should remove this at some point
Fixes robot hud objects harddeling due to hanging refs
Fixes buildmode related hanging refs, I'm coming for you admin team
Fixes a few instances of trying to add the forensics component post qdel, hhhhhhhhhhh
Fixes some split personality harddels/weirdness
Replaces a use of disconnect_duct with an init qdel hint, I suspect there's more issues with duct harddels, I've seen some odd logs about ahhh the area_contents list, but we can worry about that later
Makes teleporter targets into weakrefs, properly types them as /atom
Makes frequency devices into weakrefs
Makes cameras remove themselves from camera nets on Destroy
Makes tgui ui datums implement destroy, this means if I ever see one hang a ref to user or whatever, I know there's an error with calling close() properly. I've seen this harddel once, but not after this change so I assume there was some error with close(). IDK maybe this is a papering over? Would have to ask @stylemistake
I've seen logs of beartraps being in world post del, putting a return there just in case. The same is true of nerf darts, but I haven't really looked into that yet
Makes a shoe's ref to untying alerts a weakref, yes this is needed.
Moves clearing client_in_contents to the Login of the new mob. This prevents doing things like ghosting someone before a mob qdel causing harddels
Fixes a harddel set sourced from adding a status effect to a qdeleted thing. Is this an error? I'm honestly not sure.
Converts bsa code to weakrefs
Converts the partner var of heat exchangers to weakrefs
Converts camera assemblies to weakrefs
Fixes some dumb behavior with ammo casings and assuming you'll be on a turf post Destroy parent call
Fixes? merger related harddels, you were never cleared from your own members list, so origin objects would end up making a new list, creating harddels. Potential input from @ninjanomnom about the logic
Chasms store a static list of "falling atoms", which only exists for chasms that go somewhere else. This list wasn't being cleared of qdeleted objects, which is what happens when you fall in most chasms. Fixes this, and converts the list to weakrefs.
Fixes some runtimes in both sheet code, and the weather listener element. This is here because runtime spam made testing more of a pain, didn't think it needed its own pr
Fixes colorful reagent harddels sourced from reagents that were qdel'd before roundstart. I'm only like 50% sure this actually got it, but the issue may have been solved by #60174, so eh
Turns the nuke op antag datum's ref to the war button into a weakref
Fixes some holopad code that was not nulling refs all the time
Converts camera bugs to weakrefs, this was the result of the bug being "reworked" like 6 years back without taking the existing ref clearing into account. Whole item needs a redo, but this'll do for now.
Ensures that the both pulling and pullee refs are cleared on Destroy
The crew monitor held all users in a non clearing list, makes that list a weakref because I hate everything
Oh and I removed all sources of gas_mixture qdeletion, I'm kinda unsure on this since it's not technically supported, but any harddels from it might? indicate something going wrong with like, gas passing logic. I'd like @MrStonedOne's thoughts, since I trust him to call me an idiot if I'm wrong.
<!-- Please add a short description of why you think these changes would benefit the game. If you can't justify it in words, it might not be worth adding. -->
## Why it's not good for the game
I crashed sybil like 10 times to get this data, I'm gonna put it to good use. Don't think you're safe sybilites, I'm coming for you.
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.
* Fixes a harddel caused by the FUCKING MACHINE VAR WHAT THE FU-
* Fixes a tram related harddel, the proc that removed things from the riders list worked on stuff passed in by Uncrossed, but failed with the qdeleting signal. I've made a wrapper proc to better support these things, added signal handlers, and removed an if check that hid nulls (If it's breaking I need to know)
So a month or so ago I wanted to make it so dogs in my dog AI PR could path through doors if they had access, and was told I'd need to improve our pathfinding efficiency if I wanted to use full pathfinding for them. Thus, enter JPS, a pathfinding algorithm that allows for massive timesavings in systems with uniform cost grids like ours. This code is still fairly rough and needs polishing, but it's fully functional and already shows massive savings over traditional A*! I plan for this to replace A* as our default pathing method, but I'll leave the A* code in place in case someone ever needs it for whatever reason, like if a specific case needs variable cost pathing.
Note that this allows for diagonal pathing instead of the cardinal pathing our A* uses right now, and the current version of the code costs the same to move diagonally as it does to move laterally, which may change later. There's also a lot of dummy/test code in right now in general, but you should still be able to test it out for yourself by spawning a bot like a medibot and using your PDA to summon it.
Preliminary Profile Results
A preliminary profile is available here. Using one medibot by itself on Metastation, I generated a list of 500 random blob spawn points around the station, gave the medibot all access, then let each algorithm tackle the list. The old A* algorithm took a total of 86 seconds to complete the list and processed 978065 nodes, while JPS took a total of 46 seconds and processed only 100062 nodes, for a 47% decrease in total time and an almost 90% decrease in nodes processed!
Why It's Good For The Game
Significantly cheaper pathing, which will very much come in handy for the AI datums I'm looking to dig into, what's not to like?
Done using this command sed -Ei 's/(\s*\S+)\s*\t+/\1 /g' code/**/*.dm
We have countless examples in the codebase with this style gone wrong, and defines and such being on hideously different levels of indentation. Fixing this to keep the alignment involves tainting the blames of code your PR doesn't need to be touching at all. And ultimately, it's hideous.
There are some files that this sed makes uglier. I can fix these when they are pointed out, but I believe this is ultimately for the greater good of readability. I'm more concerned with if any strings relied on this.
Hi codeowners!
Co-authored-by: Jared-Fogle <35135081+Jared-Fogle@users.noreply.github.com>
