* Object Window Niceties (#69825)
* Object Window Niceties
Alright. I got bored and polished up the object/alt click window.
It had a few issues:
First, we generated all our images in bulk, as soon as requested
Second, the caching was global, despite only working on a client to
client basis
Third, we only generated up to 10 images. This could be fine, but the
javascript code will continuiously rerender assuming unrendered images
will come eventually, and they well, weren't. This caused MASSIVE
clientside lag
Fourth and finally, I did not like how moving away from the viewed turf
lagged behind, in sync with the stat tab update. Looked bad.
I've resolved all these.
I solved the first three issues by reworking how obj images were
generatated and managed.
Rather then storing a basic cache on the subsystem, and doing all the
image generation at once, we queue up image generation as we like, and
generate images inside a new processing subsystem fire.
This isn't the best solution, since it still eats cpu somewhat, but it's
a whole lot better then the other options, outside either removing the
need to getflat, or somehow predicting what items a client will want to
see
I've started storing three bits of info. First, a list of all the
objects we currently want to display.
Second, a list of atom -> image html
Third, a list of atoms to imageify.
This information is stored on a datum on /client, since I want this to
have a lifetime linked to well, clients.
I've used this datum to solve that fourth bit, using a component I made
for parallax a bit back. This lets me react to our client's mob, and
update the tab linked to that, rather then on a subsystem call by call
basis.
That's about it.
Co-authored-by: san7890 <the@ san7890.com>
* Object Window Niceties
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: san7890 <the@ san7890.com>
* Fixes a couple simple issues with interactability (#69762)
first things first, back when LemonInTheDark changed the interact_range code he did a slight modification that broke the AI cards, namely, he did this (not saying its a bad change, it is actually a good change, just mentioning what change caused the issue im fixing now):
now, his change does make sense, since he changed the range default to 0 instead of 1, however "null" is also used as a range, specifically for AIs, now this normally isnt an issue for the AI itself, as the AI generally gets a TRUE in its interaction checks before it gets down this deep (machines have a bypass specifically for AI), but there is one situation in which it does go this deep: AI Cards, when in an AI card the AIs interaction range is set to 0 and their interaction is disabled, thereby making it impossible for them to interact with anything, now when a player opens the card UI and enables the AIs ability to interact, this sets their range back to null, aka unlimited, the issue now however, is that since "null" is treated the same as "0", and AIs in cards dont hit the same bypasses an AI core does, Lemons change to submit a false return for 0, is also submitting false for null, meaning the AI card cannot interact with anything except the tile its on, despite having null/unlimited range....
fixed by changing the null value to infinity where it is used
additionally my fix of can_interact() code apparently had the unintended side effect of not allowing rotations of machines if theres no power, i missed this entirely because thats such a specific situation, since you try rotating with APC power in most cases, it also didnt affect most machines, that said the fix was simple, just changed the proc being called to only check distance, not power. fixes#61852
and last but not least, fixes some code with the syndie bombs interactability, namely removes a redudant section, and adds a check for range, turns out there were no checks for range so you could in theory open the UI and walk away and then activate it from another location, so added a quick check to ensure you actually CAN interact with it before letting you push buttons in the UI
* Fixes a couple simple issues with interactability
Co-authored-by: 小月猫 <alina.r.starkova@gmail.com>
* 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>
* 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
* (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>
* 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>
* Fixes aiming at the click catcher. (#64147)
My PR to fix pixel aiming broke aiming when you were aiming at obscured turfs.
The click catcher was properly modifying the click target to be the turf under the click location,
but it was passing the `ICON_X` and `ICON_Y` variables on unmodified.
This means that instead of being measured from the bottom left corner of the turf you clicked on they were being measured from
roughly the bottom left corner of your screen.
This makes the click relevant click parsing proc also update the ICON_X and ICON_Y values of the click modifiers.
* Fixes aiming at the click catcher making you shoot up and right of your target.
* Update fullauto.dm
Co-authored-by: TemporalOroboros <TemporalOroboros@gmail.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
* Dullahan Partial Refactor: They Work Again Edition (#63696)
So, a few months ago I was like "hmm there's something weird going on with party pods...", which got me looking into important_recursive_hearers or something like that. I spoke about it in the coding channel and Kyler actually fixed it before I did. But I also caught a similar glitch with Dullahans, so I decided to investigate...
Two months later...
I present to you a partial unfuckening of the Dullahans, in that I made them fully functional once again:
They only hear speech through their head (not sounds, sadly, someone else would have to tell me how to do that because I otherwise really wouldn't know how to do it in a sane way), they speak through their head, runechat-included.
When you spawn a Dullahan, you're set to look through the Dullahan's eyes (so from their head), and that doesn't reset when you log off and back in, or admin-ghost and come back in your body.
When you're looking through your head, your view will no longer be reset to your body upon entering a locker, which is nice to avoid not being blind while looking through your body.
Dullahan heads no longer look completely lifeless and without organs. They have eyes that don't look dead and that even match the player's intended eye color.
Dullahan can now properly examine things from their head, which was intended and 100% not functional.
Dullahan heads now speak with the proper name of their owner, instead of having a random name attached to it at round-start.
Dullahan heads are also now properly named too.
Dullahans can now properly whisper, sing and do all these funny things that they were unable to do before.
Dullahan whispers will now properly respect the range of the whisper.
Dullahans can now succumb in hardcrit by whispering, as intended. This potentially fixes other species that worked similarly not being able to succumb, like abductors, although I didn't test if they normally could, I just know they absolutely will be able to now.
When switching from Dullahans to a different species, your old head will no longer stay behind.
I also added a proc for species to do some code when we get a ckey login in our mob, which could potentially be useful for other stuff in the future, but it was necessary here as the view is reliant on the client, which we want to ensure doesn't get weird view glitches like having their head's vision overlay while actually being centered on their body.
I also made it so say() now takes a range argument, which is 7 by default, just so things that aren't humans can also whisper and do all those kinds of things. Going with that, there's probably a few more things that will be able to be done better thanks to this, although I haven't tested every edge case with this, but I doubt it will make much of a difference in the future.
* Dullahan Partial Refactor: They Work Again Edition
Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com>
* Updated interactions
* Update interaction_menu.dm
* Colors
* Update interaction_menu.dm
* Update interaction_menu.dm
* Update interaction_menu.dm
* Better code for all.
* Update interaction_component.dm
* Removes support for TARGET SPEAK and USER SPEAK due to instability.
* Update interactions.dm
* Update interaction_component.dm
* Enables you to interact from a distance again.
* Revert "clickon now includes attack_secondary (#61848)" (#61900)
This reverts commit a7c69aa341.
* Revert "ClickOn now actually calls ranged right click attacks"
Co-authored-by: oranges <email@oranges.net.nz>
* clickon now includes attack_secondary (#61848)
I... don't know how this was missed. Ranged right clicks only called post secondary attacks, which is hilarious and mysterious. How did NOBODY notice you could only hold someone up in MELEE range?
I also named the vars in the proc to be more readable, and added a few early returns. I didn't touch much about the top part of the proc so it may still look gross.
* ClickOn now actually calls ranged right click attacks
Co-authored-by: tralezab <40974010+tralezab@users.noreply.github.com>
* small refactor to can_interact() so that borg range is fully respected (#60693)
Its a relatively small refactor that changes the previous machinery "can_interact()" proc that literally did a full override despite half of their checks already existing in not one, but TWO parent procs, so i removed the redundant checks, added callbacks to its parents and then added the cyborg range check on the can_interact_with() itself. in doing so i also moved the interaction range var from silicons only, to mobs as a whole and defaulted it to a single tile, silicons override it to 7 (so pAIs and borgs like before) but then set AI and AI.eye to "null", because i have a check in can_interact that if there is no range set, then the range is effectively unlimited. and i even added code for when AI is carded and their wireless transmission is disabled it sets their range to "0" aka, it has no range to do anything even if it could
this was really complicated for me so despite my extensive testing it probably would be a bad thing if any of you want to test my code yourself to ensure there isnt a bug with this (theres no runtimes ive come across)
note: i did a lot of searching and going through machinery to ensure i caught all the little snowflake overrides and added can_interact() checks to them, but i may have missed one or two things, especially maybe a altclick or ctrlclick somewhere, however i believe i caught most of them
one nice side effect of this refactor is that you can actually set another mobs range to something other than 1 tile and they can interact at range, rather than only silicons getting this ability, an admin could VV a human to have a 3 tile arm reach as a meme if they want
* small refactor to can_interact() so that borg range is fully respected
Co-authored-by: 小月猫 <alina.r.starkova@gmail.com>
* Modifies right click logic so that it is not the same priority as modifier keys. (#59656)
Strips out the existing right click code - Due to the myriad of ways right clicking has been implemented, dedicated signals and procs for right clicking without modifiers are fundamentally incompatible with our system of primary and secondary attacks.
Adds additional signals to attacking code. These signals allow atoms to cancel the attack chain early on secondary attacks, or override the standard procs and not send signals to prevent any undesired behaviour from signal handlers.
Items that used RightClick procs have been converted to attack_hand_secondary.
The slaughter demon, having its own set of snowflake code as poor OOP principles have been applied in UnarmedAttack() procs with lacking calls to parent procs and arbitrary redefinition of behaviour, checks for a right click in its own UnarmedAttack() and performs a bodyslam off that.
Storage components now hijack the secondary attackby stage via signals to handle their opening and closing shortcuts on right click. When you right click a storage component equipped item with an object in your active hand, the object has an opportunity to perform its logic in pre secondary attack code and cancel the attack chain. If it does not cancel the attack chain in pre-attack, then the storage component takes over for attackby and, if possible, opens the relevant inventory and ends the attack chain.
The forensic scanner is a proof-of-concept of this working in action. With its scan logic moved from afterattack code to pre attack code for right clicking, right clicking with the scanner will now perform a scan where previously one was impossible. Left clicking still does what it always does - Scans at the very end of the attack chain.
The logic still isn't perfect - For example, you still can't attack containers in melee even in combat mode (you'll either open them or put your weapon into them regardless of which option you choose) - But this is a better setup overall which allows for items to at least override this behaviour in pre-attack if needed.
* Modifies right click logic so that it is not the same priority as modifier keys.
* a
Co-authored-by: Timberpoes <silent_insomnia_pp@hotmail.co.uk>
Co-authored-by: Gandalf <jzo123@hotmail.com>
Right-clicking a reagent container in your active hand will pick the previous transfer amount instead of the next one
Adds an attack_self_secondary proc which allows for different interactions when right-clicking things in your active hand
Co-authored-by: cacogen <25089914+cacogen@users.noreply.github.com>
* Fermichem 2.6 - Adds the HPLC: a new roundstart method of detecting purity, as well as a method of partially purifying reagents (#57858)
Adds the High-performance liquid chromatography machine - a new roundstart method of detecting purity, as well as a method of partially purifying reagents.
A single machine has been added to each of the 4(5) maps - this lets people determine their purity based off the size of the green (pure portion) to the orange (impure portion) of a reagent's peak shown on the mas spectroscopy display. If a reagent is impure - it will be displayed as red.
In addition to this function, the HPLC can purify reagents by selecting a range of them and pressing the purify button. This will cost some time depending on the mass of the reagent and will purify it up it's default purity (in the tweaked reagent cases - 75%, for the reagents I've yet to get to - 100%). It will also reduce the volume accordingly (so in essence you are reducing the volume of the impure parts).
The sprite itself will indicate when it's running, so you don't need to be nearby it or use the UI to know when it's done
* Fermichem 2.6 - Adds the HPLC: a new roundstart method of detecting purity, as well as a method of partially purifying reagents
Co-authored-by: Thalpy <33956696+Thalpy@users.noreply.github.com>
* Refactors /mob/living/CtrlClick(mob/user) and fixes pulling issues. (#57617)
Refactors the whole /mob/living/CtrlClick(mob/user) proc to be better and fixes some issues around grabbing failing due to poor logic. Closes#57618
* Refactors /mob/living/CtrlClick(mob/user) and fixes pulling issues.
Co-authored-by: Cimika/Lessie/KathyRyals <65850818+KathyRyals@users.noreply.github.com>
* Adds a hotkey that puts you in throw mode aslong as you hold it (#57331)
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Adds a hotkey that puts you in throw mode aslong as you hold it
* a
Co-authored-by: Qustinnus <Floydje123@hotmail.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
Co-authored-by: Gandalf2k15 <jzo123@hotmail.com>
* Dog AI 2.0 (#57186)
Now that JPS and AI movement datums are fully merged, I'm here to take another (my third actually) crack at giving dogs fun AI. Here's a video demonstration (somewhat WIP), and a quick rundown of everything dogs will be able to do. Basically all of these behaviors are generic and can be extended to other simple mobs,
Commands and Friendship
Fetching
Attack/Harass
Heel
Play Dead
* Dog AI 2.0
Co-authored-by: Ryll Ryll <3589655+Ryll-Ryll@users.noreply.github.com>
* adds a bitflag for no random pixel shift on dropping, adds turf_flags var to replace usage of flags_1 on turfs (#57263)
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* adds a bitflag for no random pixel shift on dropping, adds turf_flags var to replace usage of flags_1 on turfs
Co-authored-by: Fikou <piotrbryla@onet.pl>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* right clicking on a ranged attack now calls afterattack when it's supposed to (#56829)
Makes right-click ranged attacks run afterattack, if afterattack_secondary returns SECONDARY_ATTACK_CALL_NORMAL, as it's supposed to.
Fixes#56795 and #56810
* right clicking on a ranged attack now calls afterattack when it's supposed to
Co-authored-by: TJatPBnJ <69724863+TJatPBnJ@users.noreply.github.com>
* M90 changes (#56667)
The m90 is now 14tc instead of 18. Its grenades can be bought from the uplink in boxes for 6tc, instead of individual grenades for 2tc each. You can also fire the m90's grenade launcher with right click.
* M90 changes
Co-authored-by: TJatPBnJ <69724863+TJatPBnJ@users.noreply.github.com>
Co-authored-by: Gandalf2k15 <jzo123@hotmail.com>
