* Biddle Verbs: Queues the Most Expensive Verbs for the Next Tick if the Server Is Overloaded (#65589)
This pr goes through: /client/Click(), /client/Topic(), /mob/living/verb/resist(), /mob/verb/quick_equip(), /mob/verb/examinate(), and /mob/verb/mode() and makes them queue their functionality to a subsystem to execute in the next tick if the server is overloaded. To do this a new subsystem is made to handle most verbs called SSverb_manager, if the server is overloaded the verb queues itself in the subsystem and returns, then near the start of the next tick that verb is resumed with the provided callback. The verbs are called directly after SSinput, and the subsystem does not yield until its queue is completely finished.
The exception are clicks from player input since they are extremely important for the feeling of responsiveness. I considered not queuing them but theyre too expensive not to, suffering from a death of a thousand cuts performance wise from many many things in the process adding up. Instead clicks are executed at the very start of the next tick, as the first action that SSinput completes, before player movement is processed even.
A few months ago, before I died I was trying to figure out why games at midpop (40-50 people) had non zero and consistent time dilation without maptick being consistently above 28% (which is when the MC stops yielding for maptick if its overloaded). I found it out, started working on this pr, then promptly died. luckily im a bit less dead now
the current MC has a problem: the cost of verbs is completely and totally invisible to it, it cannot account for them. Why is this bad? because verbs are the last thing to execute in the tick, after the MC and SendMaps have finished executing.
tick diagram2
If the MC is overloaded and uses 100% of the time it allots itself this means that if SendMaps uses the amount its expected to take, verbs have at most 2% of the tick to execute in before they are overtiming and thus delaying the start of the next tick. This is bad, and im 99% sure this is the majority of our overtime.
Take Click() for example. Click isnt listed as a verb but since its called as a result of client commands its executed at the end of the tick like other verbs. in this random 80 pop sybil round profile i had saved on my computer sybil 80 pop (2).txt /client/Click() has an overtime of only 1.8 seconds, which isnt that bad. however it has a self cpu of 2.5 seconds meaning 1.8/2.5 = 72% of its time is overtiming, and it also is calling 80.2 seconds worth of total cpu, which means that more than 57.7 seconds of overtime is attributed to just /client/Click() executing at the very end of a tick. the reason why this isnt obvious is just because the verbs themselves typically dont have high enough self cpu to get high enough on the rankings of overtiming procs to be noticed, all of their overtime is distributed among a ton of procs they call in the chain.
Since i cant guarantee the MC resumes at the very start of the next tick due to other sleeping procs almost always resuming first: I time the duration between clicks being queued up for the next tick and when theyre actually executed. if it exceeds 20 milliseconds of added latency (less than one tenth the average human reaction time) clicks will execute immediately instead of queuing, this should make instances where a player can notice the added latency a vanishingly small minority of cases. still, this should be tm'd
* Biddle Verbs: Queues the Most Expensive Verbs for the Next Tick if the Server Is Overloaded
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
* Ladders take left/right clicks to go up or down (+ extra balance and QOL) (#67913)
You now left click to climb up and right click to climb down a ladder. A delay of 1 second has also been added, since otherwise it'd take only one click to immediately move vertically and would be much more spammable.
Ghosts still use the old radials, because their right clicks are bound to the default byond popup menu.
* Ladders take left/right clicks to go up or down (+ extra balance and QOL)
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
* Fix: #41250 You can't use a tablet while inside a locker (#68171)
* Fix: #41250 You can't use a tablet while inside a locker
Co-authored-by: Matt <gavxn@zanidrak.com>
* Tsu's Brand Spanking New Storage: or, How I Learned To Pass Github Copilot As My Own Code
* Delete storage.dm
* yippee
* shit
* holy shit i am stupid
* more fixes
* fuck
* woops
* Mild plane tweaks, thermomachine dropshadow (#68185)
Adds the area plane to the game and colorblind plane master controllers
Mostly because it's actually used now, for weather, and should be
blurred/recolored
Sets the thermomachine on the game plane
I want it to have a dropshadow, and right now it's on the floor plane,
just from atmospherics, which I think is stupid
* Mild plane tweaks, thermomachine dropshadow
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* (code bounty) The tram is now unstoppably powerful. it cannot be stopped, it cannot be slowed, it cannot be reasoned with. YOU HAVE NO IDEA HOW READY YOU ARE
* fex
* fex
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
* Implements a Demolition Modifier variable to items, affects damage vs structures and robots. (#66967)
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)
* Fixes attacks on mech equipment ignoring armor / melee damage, also fixes mech equipment not being disabled at 0% health, also also unit tests mech armor (#67411)
Co-authored-by: itseasytosee <55666666+itseasytosee@users.noreply.github.com>
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* replaces some slot names with proper names (#67481)
replaces o_clothing, i_clothing, storage1, and storage2 with suit, uniform, left pocket, and right pocket respectively
* replaces some slot names with proper names
Co-authored-by: magatsuchi <88991542+magatsuchi@users.noreply.github.com>
* Reimplements breathedeep's scan into atmozphere. (#67438)
* 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.
* Reimplements breathedeep's scan into atmozphere.
Co-authored-by: vincentiusvin <54709710+vincentiusvin@users.noreply.github.com>
* Fixes initial floating action buttons failing to properly position (#67068)
Also cleans up artificer stuff a bit, their rune button should align
with their spells.
Basically, when we grant someone a button, it gets positioned in its
default location. If the button's floating, their location var becomes
an invalid arg to position_action. Then we called position action with
their location var.
Big fucky.
I've cleaned up the logic a bit, and ensured that you can never position
to FLOATING directly, since it's a marker rather then a real position on
the screen
* Fixes initial floating action buttons failing to properly position
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Ventcrawling improvements, performance and visual (#66709)
* Initial pipecrawl work
Ok so pipecrawl images were updating EVERY TIME YOU MOVED
This was not good mojo
What I've done here is twofold
First, I ensured pipecrawl updates only when the net changes. This
breaks the current implementation, but I intend on fixing that
Second, I moved our method of getting pipes to the spatial grid
This isn't that great at the moment, but I intend on adding support for
tracking entered/exited cells, which should make this much better
* Much faster pipecrawling processing, niceties
Adds a concept called a cell tracker datum.
It manages a list of cells a passed in bound is "inside", and when
queried will return a list of new cells, and old cells.
Because we only really care about maintaining an absolute window of
"CELLS WE ARE IN" and less about always removing cells we're not in, we
can manage a second window to prevent moving up and down on a cell line
causing a ton of updates.
Uses this concept to optimize pipecrawling significantly, from 3ms per
call before to roughly 0.03ms per call.
Also moves pipecrawl images to their own plane, so they don't overlap ui
elements
* Pipecrawling effects niceties, direction help
You can now move in more then one direction when pipecrawling
This works as expected, if you hold up and left, move up for a while,
and come to a fork, you'll go left
Added some effects to pipecrawling. It'll darken the lighting plane
slightly, so you get a nice effect instead of just fullbright.
Also added a color matrix and drop shadow to the pipe images, this way
they stand out a bit more.
You now glide between pipe moves, rather then moving instantly. This
doesn't effect your actual move rate, but it no longer feels jittery
with say, 60fps
* Bounds
* Fixes runtimes, cache something somethign sonic speed
* Reworks how being interested in the spatial grid is tracked
Rather then checking multiple variables on the atom to consider, we
instead check for the existence of a string key.
This key is used by a list on the spatial grid subsystem to retrive a
cached list of all of the atoms "types"
Doing this requires doing a bit of extra work in
important_recursive_contents code, but it allows us to separate being a
part of the spatial grid from using important recursive contents, which
is very nice.
As a consequence, I've had to unroll some lazylist macros in important
recursive contents logic. It's not ""that"" bad but it's not great
either.
Oh and this adds a slight cost to enter/exit cell, but it's minimal.
Basically, rather then checking for different features of a grid member,
we just iterate the list their string key points to. Very handy
So there's an added cost of a list copy and all, but we save the
headache of more types technically increasing the cost of
addition/removal.
I also made adding/removing from the grid into one "pulbic" proc rather then two
different ones for each operation, because it was starting to get silly
* waaa waa it doesn't compile
* chord -> coord
* Ensures important_recursive_contents is actually emptied on removal
* Removes soul
* Kyler's review
Co-authored-by: Kylerace <kylerlumpkin1@ gmail.com>
* Kyler's review 2
Co-authored-by: Kylerace <kylerlumpkin1@ gmail.com>
* Kyler's review 3
Moves some procs around, improves some documentation, catches a few
small issues
Co-authored-by: Kylerace <kylerlumpkin1@ gmail.com>
* Ventcrawling improvements, performance and visual
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: Kylerace <kylerlumpkin1@ gmail.com>
* Converts drunkness and dizziness to status effects. Refactors status effect examine text (and, subsequently, stabilized black extracts). (#66340)
* 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
* this should do it?
* well, one more
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* Changes stripped_input to behave like tgui_text (#66757)
After a little bit of EVEN MORE misunderstanding, it's apparent that tgui text handles null differently, which meant fixing last whisper for tgui inputs users (chads) would mean that it would be broken for byond input users (lizards).
All jokes aside, this changes it so that text inputs will return null when you hit cancel or X for BOTH tgui and stripped_input.
* Changes stripped_input to behave like tgui_text
Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com>
* Parallax but better: Smooth movement cleanup (#66567)
* Alright, so I'm optimizing parallax code so I can justify making it do a
bit more work
To that end, lets make the checks it does each process event based.
There's two. One is for a difference in view, which is an easy fix since
I added a view setter like a year back now.
The second is something planets do when you change your z level.
This gets more complicated, because we're "owned" by a client.
So the only real pattern we can use to hook into the client's mob's
movement is something like connect_loc_behalf.
So, I've made connect_mob_behalf. Fuck you.
This saves a proc call and some redundant logic
* Fixes random parallax stuttering
Ok so this is kinda a weird one but hear me out.
Parallax has this concept of "direction" that some areas use, mostly
the shuttle transit ones. Set when you move into a new area.
So of course it has a setter. If you pass it a direction that it doesn't
already have, it'll start up the movement animation, and disable normal
parallax for a bit to give it some time to get going.
This var is typically set to 0.
The problem is we were setting /area/space's direction to null in
shuttle movement code, because of a forgotten proc arg.
Null is of course different then 0, so this would trigger a halt in
parallax processing.
This causes a lot of strange stutters in parallax, mostly when you're
moving between nearspace and space. It looks really bad, and I'm a bit
suprised none noticed.
I've fixed it, and added a default arg to the setter to prevent this
class of issue in future. Things look a good bit nicer this way
* Adds animation back to parallax
Ok so like, I know this was removed and "none could tell" and whatever,
and in fairness this animation method is a bit crummy.
What we really want to do is eliminate "halts" and "jumps" in the
parallax moveemnt. So it should be smooth.
As it is on live now, this just isn't what happens, you get jumping
between offsets. Looks frankly, horrible. Especially on the station.
Just what I've done won't be enough however, because what we need to do
is match our parallax scroll speed with our current glide speed. I need
to figure out how to do this well, and I have a feeling it will involve
some system of managing glide sources.
Anyway for now the animation looks really nice for ghosts with default
(high) settings, since they share the same delay.
I've done some refactoring to how old animation code worked pre (4b04f9012d). Two major
changes tho.
First, instead of doing all the animate checks each time we loop over a
layer, we only do the layer dependant ones. This saves a good bit of
time.
Second, we animate movement on absolute layers too. They're staying in
the same position, but they still move on the screen, so we do the same
gental leaning. This has a very nice visual effect.
Oh and I cleaned up some of the code slightly.
* Parallax but better: Smooth movement cleanup
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
I'm not sure who tested #65379 (a58c8b7fa4) or if this was only a downstream issue,
But it is not true that TGUI inputs can't return null. It returns null if you cancel or hit X.
By changing the isnull check to only look for a falsy value, you can no longer enter a blank text to succumb without last words.
Meaning you MUST enter something to succumb.
This is unintended.
Fixes a bug again. Please allow blank text last words, some people would rather the silent treatment.
I believe this was the result of merge skew, the two prs that proported to fix this issue went through at close to the same time, was likely just a mixup -Lemon
Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com>
- Mechs now have a weapons_safety toggle. If set to true, clicking does not use equipment. This is mostly intended to allow users to keep from accidentally firing. Weapon safety defaults to off, but will keep the same state it was in between pilot exit/entry events.
- All mechs now use the green reticle mouse icon. If weapons_safety is enabled, the mouse is reverted to normal. The reticle (if shown) still turns red during an EMP-related weapons fault.
- AIs can use mech weapons if the safety is off, and use AI clicks if the safety is on.
Co-authored-by: zxaber <37497534+zxaber@users.noreply.github.com>
* Converts drugginess to status effect, striking another var processed on life() (#66331)
* Changes drugginess to an effect
* Missed some changes
* Removed
* Converts drugginess to status effect, striking another var processed on life()
* wew
* 0
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
* Auto-docs + code improvements + splits up status_effect.dm (#66362)
* Code improvements for status effects in general
* Does this for now
* Throws in a qdeleted check
* A return
* comment tweak
* Missed some ref()s
* Wrong var
* Comment clarifications
* Some more comment clarifications
* Auto-docs + code improvements + splits up status_effect.dm
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* Can secondary attack (right-click) and fire guns with TK (#65473)
* Can fire guns and secondary attack (right-click) with TK
Co-authored-by: cacogen <25089914+cacogen@users.noreply.github.com>
* Painting improvement: Added a palette component for spraycans and palette items. (#65577)
* Painting improvement: Added a palette component for spraycans and palettes.
* Painting improvement: Added a palette component for spraycans and palette items.
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
* Allows you to offer an item to only one person with Shift+Ctrl+Click (#65441)
You can click someone directly with shift+ctrl+click to offer an item only to them. This is in contrast with pressing G, which offers the item to every adjacent carbon mob.
Also fixes a runtime where the Give screen alert on a potential recipient was trying to remove itself on proximity loss after the Offering status effect had already done it.
Removes duplicate range check on Give screen alert that was causing the runtime as Offering status effect takes care of it.
Also adds a check after clicking the screen alert to take something to make sure we're not dead or incapacitated, so dead people can no longer take things.
Also adds a screentip for this functionality.
Also adds some more checks to give() to make sure we can do it before sending the message to players that we're offering something.
* Allows you to offer an item to only one person with Shift+Ctrl+Click
Co-authored-by: cacogen <25089914+cacogen@users.noreply.github.com>
* Low/no power screen alert tooltips tell you where the recharging stations actually are (#65467)
* Low/no power screen alert tooltips tell you where the recharging stations actually are
Co-authored-by: cacogen <25089914+cacogen@users.noreply.github.com>
* Fixes hud objects being hidden by blindness (#65385)
They have a higher plane then fullscreen overlays, but unfortunately for
me, they were rendering to the game plane, which is below
RENDER_PLANE_NON_GAME. I was therefore getting hit in the nuts.
Hate this timeline
* Fixes hud objects being hidden by blindness
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Adds a colorblind accessability testing tool (#65217)
* Adds a colorblind accessability testing tool
I keep finding myself worrying about if things I create will be parsable
for colorblind people. So I've made a debug tool for approximating
different extreme forms of colorblindness.
It's very very much a hack. We can't do the proper correction required
to actually deal directly with long medium and short wavelengths of
light, so we need to rely on approximations. Part of that means say,
bright things being brighter then they ought to be. S not how people
actually experience things, but it's not something we can do anything
about in byond.
Anyway uh, it works by taking color matrixes, and using the plane master
grouping system floyd added to apply them to most all parts of the game
you would want to color correct.
There's some slight fragility here, but I couldn't think of a better way
of handling it.
We also need to deal with planes that have BLEND_MULTIPLY as their
blendmode, since that fucks up the filter. I've come up with a hack for
it, since I wanted to avoid breaking anything.
Oh and since I want it to apply to huds too I added plane masters to
represent them. I think that's about it.
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Adds a colorblind accessability testing tool
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Machinery attack_paw() gives feedback for no damage attacks (#65306)
* Machinery attack_paw gives feedback for no damage attacks
* I am growing stronger
* Makes messages consistent and read better
- Cleans up shitty code
* hmm
* Adds it to hulk object attack message
* Machinery attack_paw() gives feedback for no damage attacks
Co-authored-by: cacogen <25089914+cacogen@users.noreply.github.com>
