This tracks the seconds per tick of a subsystem, however note that it is
not completely accurate, as subsystems can be delayed, however it's
useful to have this number as a multiplier or ratio, so that if in
future someone changes the subsystem wait time code correctly adjusts
how fast it applies effects
regexes used
git grep --files-with-matches --name-only 'DT_PROB' | xargs -l sed -i
's/DT_PROB/SPT_PROB/g'
git grep --files-with-matches --name-only 'delta_time' | xargs -l sed -i
's/delta_time/seconds_per_tick/g'
## About The Pull Request
Fixes head revolutionaries being able to convert with the AOE mode
Why did AOE flash even have a targeted arg? Dumb
## Changelog
🆑 Melbert
fix: Head revs can no longer convert with the AOE flash mode
/🆑
## About The Pull Request
- Signallizes head revolutionary flash conversion code, moving it out of
core flash code.
- Removes "tacticool" flashing from head revs, but they can still
convert from any direction
- Fixes April Fools "You son of a bitch! I'm in" force say never
working.
- Revs are muted on conversion so they couldn't talk.
- Fixed by only muting revs on non-holidays
- Cultists are unconscious on conversion so they couldn't talk
- Fixed by only unconscious-ing cultists on non-holidays
- Brainwash victims are more often than not unconscious / asleep so they
couldn't talk
- Just left this one.
- Reduced the chance of them occurring and limits it to April Fools only
- A 1% chance of the force says ocurring means they will happen pretty
much once a week, given multiple rev / cult rounds happen every week and
on average like, 20 people are converted. A little absurd, it's good
that it never worked?
## Why It's Good For The Game
Antag code in core item code is bad
It's funny this meme has existed for like 2, 3 years now? No one's
tested it, it's never worked
## Changelog
🆑 Melbert
refactor: Removes Rev code from core flash code
fix: Getting converted on April Fools now triggers the meme force say as
always intended
del: The meme force say can no longer trigger on any day (it didn't work
before anyways)
/🆑
## About The Pull Request
- Tram crossing signals now call process() much less often
- Tram crossing signals don't turn amber/red needlessly
- Tram destination landmarks are more generic to accommodate future
maps, like Birdshot
- Renames to_where and from_where, because those vars didn't always
match tram position to/from
## Why It's Good For The Game
Tram works better, uses less processing
## Changelog
🆑 LT3
code: Tram crossing signal/platform logic improvements
/🆑
## About The Pull Request
I'm a bit sad about the state of trashbags.
They're very clunky to use, so they almost never get touched. S
depressing. Let's try and fix that.
Let's make em fit in the belt slot (again), but as a tradeoff we'll make
it harder to pull one thing from your bag.
We'll give it a say, 1.5 second delay, so you can't quickdraw from em.
If you try and dump them out into something else, we'll throw any
spillover on the ground below you
I'm also doing some general code cleanup here. Making procs more
readable, vars more direct, removing some old legacy stuff.
I've added a remove_single proc to hook into via subtype, which takes a
mob as input. this has required placing extra requirement on some helper
procs, but fortunately it's not something they're unable to meet.
My hope is this will make garbage bags usable without being stupid.
## Why It's Good For The Game
I don't see these get used at all, cause they're a pain to carry around.
They got gimped because people were using them as infinite storage for
shotgun shells and other small items.
I've made using them for this sort of thing hard and slow, so I think we
oughta be fine. If not I'll do some more touching, maybe give the
autodrop a delay.
## Changelog
🆑
balance: The janitor's trashbag now fits on his belt. In exchange,
taking something out of it sends a visible message, and has a delay.
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
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
This PR does some QOL tweaks to blast doors and their construction.
Namely, adding some balloon alerts to the whole construction process
(adding, removing electronics, adjusting their electronics IDs).
Additionally, adds some extra examine text to an open blast door by
explaining that you can multitool it to adjust the ID, and that it must
match that of the blast electronics to be added to a wall frame.
Adjusts a forcedrop to a `move_to_hands` because it's 2023 and we trust
that users can hold things during a attack_hand proc.
Also adds some description to button frames as well to guide them that
they can install and remove electronics and boards while open.
I'm gonna be real, this needs a LOT more work than this to be up to code
standards, but this was what I could pull off in the 30 minutes before I
need to sleep while away on business, but it's a start nonetheless.
## Why It's Good For The Game
Button frame code is practically ancient, yet it's still widely used to
this day. It needs some real polish more than this, but for now this
will at least make the construction process more intuitive and clear.
Also to that guy who I said I would do this about a month ago I'M SORRY
I'VE BEEN TRAPPED IN THE **_SUPERMAX WAGE CAGE_** I CAN PROVE IT
~~Wait what do you mean you need to make player made blast doors through
the CRAFTING UI WHAT THE FUUUUUUUU~~
## Changelog
🆑
qol: Improves feedback on buttons as well as the blast door electronics
so that installing your very own blast doors is less tedious.
/🆑
## About The Pull Request
- After one too many tram malfunctions, Nanotrasen's insurance provider
finally sprung the cash for a new tram. Made with the latest in
lightweight materials, there's more capacity than ever before to shuttle
your crew around the station.
https://user-images.githubusercontent.com/83487515/215639768-3f7fcb84-cfd2-4efe-b578-998197651f13.mp4
- Consolidates all the tram turfs, objs, and structures into respective
.dm files because they were haphazardly spread everywhere.
- Fixes tram doors playing open/close animations when they're already in
the correct state, corrects timing for when they change density.
- Tram now correctly has an operating status and will stop functioning
when power is lost.
- Call buttons no longer dispatch a tram that doesn't have power.
- Fix for emergency exit when tram has no power.
- Running at closing tram doors is a gamble, you may be crushed
- Fixes https://github.com/tgstation/tgstation/issues/73125
## Why It's Good For The Game
Looks nice, more space, tram doors demand a pound of flesh.
## Changelog
🆑 LT3
imageadd: Nanotrasen's insurance provider finally sprung the cash for a
new tram. Made with the latest in lightweight and mostly* non-flammable
materials, travel in comfort and style!
code: All tram components are now organised based on type
code: Tram is now aware if it has power or not
del: Removed movement slowdown running on tram plates
fix: Tram call buttons will not work calling an unpowered tram
fix: Tram doors will no longer cycle open/closed when they're already in
the correct position
fix: Fixed an edge case where running onto the tram you bounce off the
open door as if it was closed
fix: Unpowered tram doors can only be forced into the open position
fix: Westbound travel shows the correct controls animation
add: Tram doors take a chunk of flesh if you run at them last minute
qol: Reduced duration of amber stage on tram crossing signals
/🆑
## 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>
## About The Pull Request
- Nearsighted is now a grouped status effect.
- Blindness is now a grouped status effect.
- Eye handling of blindness has improved.
- When eyes are removed, they now cause you to become blind, rather than
handling it in `update_tint`.
- Being ahealed no longer blinds you for one tick, meaning that black
overlay on aheal is gone.
- Temporary Blindness is now a status effect.
- Both Nearsightedness and Blindness have been exorcised from mob vars
and life chains. This means that we've finally cut 2 procs from life,
`handle_status_effect` and `handle_traits`, and moved both to event
based processing. Wooo optimizations.
- Swapped pacifism status effect to use apply and set helpers.
- Removed an unused admin toggle that disabled welding helmet tint but
also tint from every clothing item and also blindness from losing your
eyes.
- Clothes now generally all blind their mob more consistently.
- Oculine, eye surgery, and sensory restoration are now no longer the
only way to fix blindness from eye damage. If your eyes are healed
through any other means, it will also heal your blindness.
- Some things that made you blind, such as ling blind sting, no longer
just flat made you blind from eye damage forever. They now cause eye
damage directly, which in turn makes you blind from eye damage, as
expected.
- Pacifists can't eyestab anymore. Eyestabs now have a limit on the
amount of blur applied.
- Refactored some `is_x_covered` procs to accept flags rather than have
a lot of arguments for some silly reason.
- Unit tests for blindness.
## Why It's Good For The Game
Blindness was exceptionally poorly handled prior, primarily due to the
fact that it was tied to the mob instead of separated out
On top of that the system put a LOT of faith in proper handling of
blindness on the coder's end which was misplaced evidently. Many places
didn't update or handle blindness correctly, or just let people
perma-blind.
Deferring it to a status effect improves this a lot
## Changelog
🆑 Melbert
refactor: Refactored blindness and nearsightedness. Important to note is
that all mobs are naturally blind until their eyes are actually created.
refactor: Refactored "is covered" procs
fix: Less sources of blindness now cause permanent blindness. Includes
the "Blind" Spell and "Blind Sting" from changelings.
admin: Ahealing someone no longer flashes the blind overlay for 1 tick.
admin: I removed an unused (sort of) inaccessible admin verb that
allowed you to toggle the tint from all welding helmets (and clothing)
(and lack of eyes) in existence, let me know if you want similar back
balance: Changeling "Blind Sting" now causes eye damage (enough to
blind) rather than arbitrarily forcing blindness.
balance: Visionloss virus symptom now causes eye damage (enough to
blind) rather than arbitrarily forcing blindness.
balance: Oculine has been reworked slightly. Prior, Oculine arbitrarily
healed blindness and nearsightedness from eye damage reagrdless of how
damaged the eyes were, and applied blur on success. Now, Oculine just
heals eye damage, and blindness / nearsightedness is restored in the
process. There is now a probability every tick that eye blur is applied
based on how pure the oculine is while healing very damaged eyes.
balance: Pacifists can no longer eyestab.
balance: Any clothing item that covers your eyes contributes to getting
the bonus while sleeping, and to removing temporary blindness faster
/🆑
Adds lints for `balloon_alert(span_xxx(...))` (which is always wrong),
and balloon alert where the first letter is a capital (which is usually
wrong). Fixes everything that failed them. As a reminder, abbreviations
like "AI" and "GPS" shouldn't be capitalized in a balloon alert.
In cases where this is intentional for flavor (there was one case), you
can `UNLINT` like so:
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
## About The Pull Request
You know the deal by now.
- Drowsiness is now tracked via status effect.
- Eye blue is now tracked via status effect.
In converting these over, cleaned up a bit of code relating to some
other effects. Attempts to unify behavior between some of them, namely
certain biotypes or mob types shouldn't be experiencing certain effects.
## Why It's Good For The Game
More stuff moved to status effects, slightly more cleaner and better to
work with code. Allows for all mobs that can sleep to be able to get
drowsy, too.
## Changelog
🆑 Melbert
refactor: Drowsiness and Blurred Eyes are now tracked via status effect.
/🆑
## About The Pull Request
status panel for carbons and humans instead of hardcoding stuff, uses
signals (borg material storage too)
removes combat mode indicator in status tab from xenomorphs which have a
button for it, but adds it to simplemobs, since they dont have a visual
indicator
adds status tab stuff to basic mobs, i think they were missing
everything by accident
offsets unique status tab stuff for all mobs by a single line
the delay between updates is a third of what it was before, mainly to
make shuttle timers more accurate (approved by kyler)
## Why It's Good For The Game
much cleaner code, makes future implementations easy
## Changelog
🆑
qol: you can see your combat mode status as a simple or basic mob, and
you can see your health as a basic mob
qol: status panel updates three times as fast
/🆑
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
## About The Pull Request
<!-- Describe The Pull Request. Please be sure every change is
documented or this can delay review and even discourage maintainers from
merging your PR! -->
Fixes#69798Fixes#71621
When using hypnosis on a victim, the language should be accounted for
and whether the victim can properly hear it. Before the hearing code
would magically translate any message, this is no longer the case.
This also fixes the language barrier involving hearing for:
- Mind echo trauma
- Phobia trauma
- Hypnotic trigger trauma
- Split Personality brainwashing trauma
- Codeword hearing
- Hypnotize status effect
- Impure Inacusiate reagent
## Why It's Good For The Game
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
Better consistency, improved readability, and less bugs in the future.
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and it's effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->
🆑
fix: Fix hypnosis, mind echo trauma, phobia trauma, hypnotic trigger
trauma, split personality brainwashing trauma, codeword hearing, and
impure inacusiate reagent all bypassing language and hearing checks. If
you try to give commands to a victim in a language they don't
understand, they will no longer magically understand the words.
fix: Fix sign language having accent modifications
refactor: Refactored saycode to be more robust, readable, and have more
unit tests.
/🆑
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
## About The Pull Request
Soft revert of #71224 , Fixes#71222
Fixes an exploit involving attachment of multiple igniters to one
assembly.
- Multiple igniters or condensers can no longer be attached to the same
assembly holder
- Assembly holders have a limit of 12 assemblies maximum
- I'm not sure if this is too low or limited, I picked it arbitrarily.
Please inform me if it could be upped a smidge.
- This lag exploit was born because of limitless assembly holders, which
is a little silly even with the exploit aside. All that uncapped holders
can bring are exploits or bugs, which I feel confident limited can
prevent. What use is there even for having so many?
- Cleans up / refactors some aspects of assemblies and assembly holders.
- Assemblies had a weird wire type flag that was only ever used by
signallers, but also used wrong by signallers. I did some scanning of
the code and realized that ... a lot of this was just straight up
unused, and not even assigned anywhere.
- Now, there is a flag assembly flag var, which everything is read off
of. Tested it and still seemed to all work fine.
## Why It's Good For The Game
Lag exploits are bad.
## Changelog
🆑 Melbert
fix: Fixed an exploit involving igniters attached to themselves.
Assembly holders are now limited to 12 assemblies maximum, and you
cannot attach multiple igniters to the same assembly.
refactor: Refactored some assembly jank, namely in how they pulse and
are pulsed.
/🆑
## About The Pull Request
This replaces needless GLOB.machines with more precise lists whenever
one existed, plus adding a new one for CTF machines.
## Why It's Good For The Game
GLOB.machines holds every single /obj/machinery in the game, so checking
the whole list for stuff is pretty big. This aims to cut that down by
using smaller lists whenever possible. I also gave CTF a new list
because it checked machines very often.
## Changelog
Nothing player facing.
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>
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
## About The Pull Request
Previously it didn't work while it was supposed to, setting it up to 0
tile range would make it useless and not trigger. Now it does.
https://www.youtube.com/watch?v=ouseFRoEgD8
<!-- Describe The Pull Request. Please be sure every change is
documented or this can delay review and even discourage maintainers from
merging your PR! -->
## Why It's Good For The Game
Fixes are good for the game
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
## Changelog
🆑
fix: fixed the prox sensor
/🆑
* Fixes halloween races.
- Fixes a race condition involve checking for holidays befores SSevents is instantiated. Now, holiday checking is done through a helper, which will ensure the holidays list is created and filled before checked.
* Converts mice and rats to basic mobs
* Update paths
* Fixes
* Tweaks
* .
* Use helpers
* Unit test
* Correct the targeting
* Fixes the unit test?
* Fixes the unit test
* Docs
* update the path script with pr id
* Faction check tweak
* Review
* AHH
* Being protected by Shoes or Gloves against a mousetrap will now give you a message in chat telling you such, removing a surprise for those caught off-guard by it.
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Fixes#70377
Stobe shield has been broken for.... hell I don't even know how long lmao
cl ShizCalev
fix: Fixed some missing shield inhand icons.
fix: The strobe shield's inhand icon now plays the flashing animation when triggered again.
fix: The strobe shield will no longer blind the person holding it when it deflects a blow.
fix: The light from the strobe shield's flash no longer appears in your held inventory slot.
fix: Fixed the east facing left-handed strobe shield sprite being misaligned by two pixels.
/cl
* 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
Fixes#69043 assemblies not providing a UI when part of a one-tank bomb. (This doesn't count voice analyzers, which don't have UI)
Fixes#68139 assemblies triggering themselves (and often turning themselves off).
Fixes timers ceasing to loop if the timer is set to less than the 3-second anti-spam threshold.
#69335, #68733 signalers occasionally runtiming due to qdel'd weak reference datums. Already addressed by another PR
Proximity sensors and mousetraps work on more wire datums, but proximity sensors are still buggy.
Igniter-sensor pairs can detonate fuel tanks properly, including plumbed fuel tanks. Fuel tank explosions scale with how much fuel is in them; this is slightly nerfed from existing values.
The fuel tank detonation code has been made generic, but other reagent dispensers have rigging turned off. If turned on with a varedit, you can rig and detonate water and other reagent tanks. Reagent tanks can theoretically both explode and spread reagents if it should happen to contain both welding fuel and other stuff. I have not actually tested this part of it, but I have detonated both water tanks and fuel tanks and each works correctly.
In making mousetraps work on wire datums, I had the opportunity to make it so that you could place a mousetrap in a door's wire and it would activate when someone passed through the door (useful to bolt a door open when someone authorized goes through, for example). This is a fun mechanic but does not make sense for a simple mousetrap to be so powerful, so it is disabled. Ideally, you could put the laser tripwire in a door's wires to do the same thing, but that would be a massive rework. Mousetraps still work in on-found mode for all wire datums, and will work on items with wiring datums (like C4 and chem bombs) when stepped on.
The signaler runtimes were a result of weak_ref datums being deleted, and the communications system not handling that. It's probably not ideal to run null checks in the post_signal loop, but I am not going to worry about it.
Many of the assemblies were not properly registering when the assembly holder was attached to an item. This was most important for proximity sensors, but that also has other problems that I haven't been able to track down.
The problem with UI not appearing was a result of the transition to TGUI however long ago that was; the proc that assures TGUI that you have the right item needed to be aware of one-tank bombs and similar, or else when you pass along an interact request it says "but you can't see it" and ignores you.
Why It's Good For The Game
Bugfixen.
The thing with the reagent dispensers only got this complicated when I realized that the plumbed fuel tank variant wasn't a subtype and therefore couldn't be rigged. And then... I basically just scaled it because the flat scale no matter the contents of the tank offended me. You could wrench open tanks, drain them entirely of fuel, rig them, and they would still go off like a pile of dynamite.
I used to have code in my branch that turned chem bombs into variants depending on the trigger, with mousetraps being mines for example. That's honestly the main reason I went out of my way to make mousetraps work better as assemblies. I could wish it were better supported, but mousetraps on grenade wiring will have to do for now.
Changelog
cl
balance: Welding fuel tank explosions have been scaled slightly down and require the fuel tanks to actually be full of welding fuel
fix: You can detonate welding fuel tanks with an igniter-sensor assembly
fix: You can reach your one-tank bomb's assembly controls by activating the item in your hand.
fix: Certain assemblies should no longer turn themselves off.
fix: Clumsy fools handling a mousetrap-based multi-part assembly may set it off by accident
/cl
* Adds the installed message phrase for voice analyzers to logging
Hey there,
Sometimes, it's CBT to figure out what exactly made a bomb go off, especially when a voice analyzer is involved. Now, when a voice analyzer is involved in TTV Bomb/Grenade explosions (already logged), it will also output the recorded phrase when present.
To do this, I just span up a quick `isvoice()` macro define to ensure that we would get the variable, and it would just append the message that we were already spitting out into logs. I rewrote how grenade logs currently operate a bit, let me know if I accidentally omitted something critical.
Moves singulo and supermatter dmis into obj/engine, renamed from obj/tesla_engine
Moves Halloween, Christmas, and misc holiday items to obj/holiday
Moves lollipops to obj/food
Moves crates, closets, and storage to obj/storage
Moves assemblies to obj/assemblies
Renames decals.dmi to signs.dmi ...because they're signs and not decals
Moves statues, cutouts, instruments, art supplies, and crayons to obj/art
Moves balloons, plushes, toys, cards, dice, the hourglass, and TCG to obj/toys
Moves guns, swords, shields to obj/weapons
* Elevators are a bit more friendly part 1
- Emaggable elevator buttons / support for emaggable device assemblies
- Delayed travel between floors
- Elevators can now show a warning sign to areas below while travelling
- Elevators can now optionally wound heavily instead of gibbing
* Adds supoprt for "lift doors"
* Comment tweak
* Splitting these variables
* Functional prototype
* multiz debug
* Elevator button framework
* Unifies these behaviors
* Emergency doors
* Lift button framework
* UI closes on floor change
* Testing changes
* Fix
* UI Tweaks
* Panel works pretty swell
* Minor tweaks
* Move to static
* Bonus tram change
* User experience
* Slight tweak to mapload stuff
* This is silly
* Some UI tweaks, need to update css
* CSS and ui overhaul
* Documentation updates.
* Multi-z lift support
* Multitile lift fix
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
* Fuck you (refactors ur tails)
* Errors
* Wow. Pain.
* Fixes up probably everything
* finish up here
* Fixes hard del maybe
* original owner hard del
* garbage collection runtime
* suck my peen byond
* Mapped tails
* motherfucker.
* motherrfucker. again.
* Whooopppppsie
* yeah bad idea
* Turns out external organs literally just sat in nullspace forever if their parent was deleted, and didnt Remove() themselves, causing harddels.
* So anyways I repathed all organs
* Fixes
* really.
* unit test... test
* unit test-test but it passes linters this time because im a moh-ron
* I've lost track of what im doing at this point
* Hopefully fixes hard del?
* meh
* Update code/datums/dna.dm
* things n stuff
* repath from master pull
Refactors the confusion status effect. Removes "confusion strength" and replaces it with duration, which is measured in seconds.
This also allows them to use the adjust_timed_status_effect procs instead of their own.
Fun fact! 2 years ago when confusion was refactored into status effects, all confusion effects in the game were halved in duration. They were changed to status effects, which tick every 1 second by default, from life, which tick every 2 seconds by default, without any values changing.
This PR refactors firestacks into two status effects: fire_stacks, which behave like normal firestacks you have right now, and wet_stacks, which are your negative fire stacks right now. This allows for custom fires with custom behaviors and icons to be made.
Some fire related is moved away from species(what the fuck was it even doing there) into these as well.
Oh and I fixed the bug where monkeys on fire had a human fire overlay, why wasn't this fixed already, it's like ancient.
Also changed some related proc names to be snake_case like everything should be.
This allows for custom fire types with custom behaviours, like freezing freon fire or radioactive tritium fire. Removing vars from living and moving them to status effects for modularity is also good.
Nothing to argue about since there's nothing player-facing
* Refactors dizziness into a status effect
* Refactors the dizziness setter to use the new kind
* Drunkness.
- Should drunk continue to work off of a magic value or be swapped to duration? I've not yet decided: For understandability it's preferabale for "drunk" to use a timer (they are drunk for 3 more minutes), but both adding drunk and decreasing drunk currently use weird calculations which would be difficult to carry over.
- Ballmer is a liver trait
* Dizzy was a setter, not an adjuster
* Does all the drunk effects over
- refactors examine text fully
- refactors stabilized blacks because of this
* Removed
* repaths, fixes some issues
* Minor fixes
* Some erroneous changes
* Fixes some dizziness errors
* Consistency thing
* Warning
* Undoes this change, I dont like its implementation
* max_duration
* Max amount
* Should be a negative
* max duration
* drunk doesn't tick on death
* Rework dizziness strength
* Erroneous dizzy change
* Fixes return type
* reworks hilbert's hotel ruin
* warooio
* you can now run multiple trams on the same z at the same time, trams are linked by id
* fuck
* sure
* you are a simulacra
* FUG
* dock
This PR changes how assemblies and assembly holders work, and allows you to connect more than just a signaler and an igniter together. You could have a signaler, a repeating timer, and an igniter together to constantly produce sparks. Making the assembly holder is the same as before, but now you can add assemblies to it. This also allows signalers to be triggered via right clicking them while holding them in your active hand.
