Makes right-click ranged attacks run afterattack, if afterattack_secondary returns SECONDARY_ATTACK_CALL_NORMAL, as it's supposed to.
Fixes#56795 and #56810
Fixes two runtimes, one caused by status effects always expecting a return from throw_alert, and another caused by holding yourself up (which you shouldn't even be able to do). Also fixes an issue caused by multiple people holding up the same person, when one of the perpetrators stopped holding up the victim, all of the victim's related alerts disappeared.
I had accidentally tested this with a medkit in my hand (I'm a CMO on my test server).
Now correctly uses an attack_hand adjacent proc, rather than attackby.
Health analyzer is now left click for health (or wounds, if you toggle
it) and right click for chemical scans.
Ever since the tgchat combine-previous-chats-in-one thing, knowing what
mode you're on has been a pain for me, as well as needing to cycle
through all of them. Furthermore, this is just a sane right-click
action to have.
Refactors hand tele code with better variable names, splitting procs, fixing C&P code, etc.
Adds pre_attack_secondary, the right click version of pre_attack.
Adds a new alternate function to hand teles, which will reopen the last location you opened. Works based off locations, not turfs. For example, right clicking after locking in "None (Dangerous)" will not teleport you to the same place.
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.
pAIs are now a useful space travelling companion, they can help you
navigate if lost (although only the pAI has the GPS view, so they'll
need to communicate the information). If you're holding a GPS, then the
pAI can find you even if you get separated.
Adds alternate attack procs for right-clicking. Updates the gunpoint code to use this new proc as an example (though I suspect this is being changed soon, so oops).
This makes it easier to add new behavior to right click, which we should be doing.
About The Pull Request
This PR removes intents and replaces them with a combat mode. An explanation of what this means can be found below
Major changes:
Disarm and Grab intents have been removed.
Harm/Help is now combat mode, toggled by F or 4 by default
The context/verb/popup menu now only works when you do shift+right-click
Right click is now disarm, both in and out of combat mode.
Grabbing is now on ctrl-click.
If you're in combat mode, and are currently grabbing/pulling someone, and ctrl-click somewhere else, it will not release the grab (To prevent misclicks)
Minor interaction changes:
Right click to dissasemble tables, racks, filing cabinets (When holding the right tool to do so)
Left click to stunbaton, right click to harmbaton
Right click to tip cows
Right click to malpractice surgery
Right click to hold people at gunpoint (if youre holding a gun)
Why It's Good For The Game
Intents heavily cripple both the code and the UI design of interactions. While I understand that a lot of people will dislike this PR as they are used to intents, they are one of our weakest links in terms of explaining to players how to do specific things, and require a lot more keypresses to do compared to this.
As an example, martial arts can now be done without having to juggle 1 2 3 and 4 to switch intents quickly.
As some of you who saw the first combat mode PR, the context menu used to be disabled in combat mode. In this version it is instead on shift-right click ensuring that you can always use it in the same way.
In this version, combat mode also no longer prevents you from attacking with items when you would so before, as this was something that was commonly complained about.
The full intention of this shift in control scheme is that right click will become "secondary interaction" for items, which prevents some of the awkward juggling we have now with item modes etcetera.
Changelog
cl Qustinnus
add: Intents have been replaced with a combat mode. For more info find the PR here: #56601
/cl
Cleaned up, commented on, and (hopefully) improves a lot of blob code.
Put pretty much everything balance-related (except for the strains themselves) into a define file, for easier viewing, changing, and balancing.
Added a bunch of new functionality that new strains (some of which I plan to add in the future) could use: from increased expansion range to more spores per factory.
* Adds emissive carpet, adds plane support to decal element
- Adds a basic abstract/debugging emissive carpet
- Makes decals capable of supporting plane
- Adds auto-smoothing decals
* Adds simple neon carpet variations
* Adds neon carpet reagents and recipes
* Refactors emissive blockers to allow multiple layers of emissive / emissive blocking objects
- Splits the emissive and emissive blocker plane masters into several plane masters which handle different layers of emissiveness.
* Makes neon carpet tile stacks emissive
* Rearranges and docs some emissive plane masters
- Folds the overlay lighting plane master into the emissive planes since it is also used to mask the lighting plane
* Fixes null mats_per_unit stack recombining after splitting
- I think I broke this a while ago when I reworked how stacks handle materials. Whoops.
- This basically only effects carpet at the moment. Good thing I did this when I did!
* Adds neon carpets to cargo
- Adds a cargo supply crate containing a _lot_ of neon carpets for 3000 credits
* Fixes neon carpet highlights leaking through vending machines and such
- Turns out vending machines axed their own emissive blockers whenever they updated their icon because they cleared their managed_vis_overlays...
- Generic emissive blocking has been elementized and some update_overlays procs have been straightened out.
* Fixes id_arg_index for the emissive blocker element
* Commits @Rohsie's suggestions
Changes the references of borg module (type) to model, adds a file for robot declarations and one for model declarations. Basically trying to make the code layout a little more sane.
Initially changed them to 'configurations' but I prefer model; its meaning is closer to module than configuration and avoids confusion with actual config.
When observing someone without client (because they for example disconnected) a runtime happened:
This was because update_parallax didn't take a mob as parameter but instead always updated the parallax of the mob to which the HUD datum belonged (which was the HUD of the person who you tried to observe)
If that mob had no client this caused a runtime.
If you observe someone now the game updates parallax for your client and not the client of the person you tried to observe.
Adds a signal listener on mechs that listens for middle clicks, and calls a proc that will, in turn, call the normal click proc if the user is an AI.
Middle clicks now pass through params just like left clicks.
I suppose for bots there's a certain level of abstraction involved, but it makes sense within the context.
There's a pretty bad bug associated with shades here that this fixes.
Also provides a generic, forward proof way to provide information to radial menu choices.
Why It's Good For The Game
input is old and crummy.
Blob is a very wiki reliant mechanic. This moves a bit of it into the game itself to fix that.
Provides a real cancel option, whereas the old one had none. This is not a balance change, but a QoL one--everyone just moved the input window off to the side.
Filter refactor + In Game Filter Editor
Accessed via VV in the dropdown of atoms. "Edit Filters.
Makes filters actually usable.
Co-authored-by: ghgh <hghgh>
This PR essentialy moves away from the extremely microwave dependent cooking we have for meat right now, and making it a bit more sensical by making you use a grill to grill meat. The grill takes a different time (with variation) for different grilled things. Once finished it will turn that food into something else.
Yes, this does mean creating burgers takes longer, but in return you can make more patties at once, and you are not required to stay at the grill while its going. This lets you cook as much as you want at once, just make sure your meat doesn't burn!
In the future, I hope to move more things like this to machines similar to this (Pasta boiling, putting eggs on the griddle, soup making, etcetera) to create for a more interesting cooking experience.
Adds a MAPTEXT macro that wraps the given text in the maptext class, the thing we use for Runechat to make it so you can actually read it. Everything that sets maptext now uses this.
Yeah uhh this'll probably need testmerging even after it's done because yeah it's a bit big.
If y'all want me to atomize this into two PRs (pass flags vs projectiles) tell me please. Pass flags would have to go in first though, in that case, as new projectile hit handling will rely on pass_flags_self.
Pass flags:
Pass flags handling now uses an atom variable named pass_flags_self.
If any of these match a pass_flag on a thing trying to pass through, it's allowed through by default.
This makes overriding CanAllowThrough unnecessary for the majority of things. I've however not removed overrides for very.. weird cases, like plastic flaps which uses a prob(60) for letting PASSGLASS things through for god knows why.
LETPASSTHROW is now on pass_flags_self
Projectiles:
Not finalized yet, need to do something to make the system I have in mind have less unneeded overhead + snowflake
Basically, for piercing/phasing/otherwise projectiles that go through things instead of hitting the first dense object, I have them use pass_flags flags for two new variables, projectile_phasing and projectile_piercing. Anything with pass_flags_self in the former gets phased through entirely. Anything in the latter gets hit, and the projectile then goes through. on_hit will also register a piercing hit vs a normal hit (so things like missiles can only explode on a normal hit or otherwise, instead of exploding multiple times. Not needed as missiles qdel(src) right now but it's nice to have for the future).
I still need to decide what to do for hit handling proper, as Bump() is still preferred due to it not being as high-overhead as something like scanning on Moved(). I'm thinking I'll make Moved() only scan for cases where it needs to hit a non-dense object - a prone human the user clicked on, anything special like that. Don't know the exact specifics yet, which is why this is still WIP.
Projectiles now use check_pierce() to determine if it goes through something and hits it, doesn't hit it, or doesn't go through something at all (should delete self after hitting). Will likely make an on_pierce proc to be called post-piercing something so you can have !fun! things like projectiles that go down in damage after piercing something. This will likely deprecate the process_hit proc, or at least make it less awful.
scan_for_hit() is now used to attempt to hit something and will return whether the projectile got deleted or not. It will delete the projectile if the projectile does hit something and fails to pierce through it.
scan_moved_turf() (WIP) will be used for handling moving onto a turf.
permutated has been renamed to impacted. Ricocheting projectiles get it reset, allowing projectiles to pierce and potentially hit something again if it goes back around.
A new unit test has been added checking for projectiles with movement type of PHASING. This is because PHASING completely causes projectiles to break down as projectiles mainly sense collisions through Bump. The small boost in performance from using PHASING instead of having all pass flags active/overriding check_pierce is in my opinion not worth the extra snowflake in scan_moved_turf() I'd have to do to deal with having to check for hits manually rather than Bump()ing things.
Movement types
UNSTOPPABLE renamed to PHASING to better describe what it is, going through and crossing everything but not actually bumping.
Why It's Good For The Game
Better pass flags handling allows for less proc overrides, bitflag checks are far less expensive in general.
Fixes penetrating projectiles like sniper penetrators
This system also allows for better handling of piercing projectiles (see above) without too much snowflake code, as you'd only need to modify on_pierce() if you needed to do special handling like dampening damage per target pierced, and otherwise you could just use the standardized system and just set pass flags to what's needed. If you really need a projectile that pierces almost everything, override check_pierce(), which is still going to be easier than what was done before (even with snowflake handling of UNSTOPPABLE flag process_hit() was extremely ugly, now we don't rely on movement types at all.)
## About The Pull Request
Namely, this means that a simplemob's immunity to melee attacks of force X or lower now accounts for that simplemobs damage multipliers to various damage types. It also means that simplemobs with a force_threshold of X are now immune to melee attacks of force X or lower, not melee attacks with a force less than X (<= vs. <).
## Why It's Good For The Game
**tldr;
This make the code for simplemob "your stick must be this strong to deal damage" thresholds more consistent.**
Xenomorphs, xenomorph larvae, barehanded monkeys, slimes, and simplemobs in general all multiply the damage of their attacks by the relevant damage resistance multiplier BEFORE checking it against the force_threshold of the simplemob they're attacking, and also check to see if their damage is <= the force_threshold of the simplemob they're attacking (instead of requiring it to be strictly < the force_threshold of the simplemob they're attacking).
As for balance concerns, while this will affect juggernauts *slightly* (as they'll now be immune to force <= 10 melee weapons instead of just force < 10 melee weapons), I'm not too worried about that. What I _am_ worried about is blobbernauts, who, after this change, will be immune to brute melee weapons of force 20 or lower (due to their 0.5 brute damage multiplier). You will, of course, still be able to welder them just as effectively as you could before, but I'm worried that this could make blob-aligned blobbernauts even stronger than they already are.
The mood /atom/movable/screen, instead of having a Click() override, instead has its COMSIG_ATOM_CLICK registered in the mood component. This has the side effect of normal attack chain protocol being ran on it, meaning that if you click it with TK you will get a message saying "Your mind won't reach that far". This fixes that by overriding attack_tk into a noop.
The PR aims to allow advanced tool users to be defined by traits rather than a hardcoded proc.
Also necessary for the CanUseTopic refactor I'm working on, which will be PRed separately for atomization purposes.
This PR also fixes an inconsistency with can_hold_items (since monkeys can actually hold items).
This PR lets you post up for high-fives with your buds so you can slap some skin and show off how well you vibe together. To initiate a high-five, simply stand next to another person with a slapper (the *slap emote one) in hand, and hit the offer item button (default G) to let the people adjacent to you know you're available. They'll get an alert that you're offering a high-five, and clicking it will follow through and award you both a small positive moodlet, or they can just walk away and leave you hanging, earning you a negative moodlet.
Is a high-five not enough to show the world how tight your crew is? Double the fun! If whoever initiates the high-five has a slapper in both hands, and the taker has two hands free, you'll go for the mythical high-ten for a louder slap and extra emphasis! Woo!
Previously your chat messages would be obstructed by the blackness of blocked turfs, aswell as dark lighting and some other effects. This fixes that
It still has backdrop ambient occlusion like it used to.
The attack chain is a bit of a mess, and the introduction of signals hasn't helped in simplifying it.
In order to take a step into untangling this, I re-ordered the attack signals to no longer be by source type and instead to be grouped more modularly, as they are all members of the attack chain and function similarly. They all share the trait of potentially ending the attack chain via a return, but had several different names for it. I joined it into one.
Additionally, fixed a tk bug reported by @Timberpoes by adding a signal return check at the base of /mob/proc/RangedAttack
Lastly, removed the async call of /datum/mutation/human/telekinesis/proc/on_ranged_attack, which was added as a lazy patch to appease the linter complaining about a sleep on a signal handler (namely in /obj/singularity/attack_tk). Fixed the problem using timers.
Also cleaned some code here and there.
imo; the ss13 audio-scape is quite barren, you can only hear most things if you can see them, which in my opinion doesn't make much sense. This changes that so you can hear further away, but falloff is much higher, so in reality you will only hear things relatively quietly when they're out of sight.
This PR increases the hearing distance of most sound by 9, excluding sounds such as antag items that are meant to be used stealthily
This PR also replaces Byond's inbuilt falloff system with something I made, (And thanks to potato for helping me throw together a formula for it). This fall-off system makes sound fall off more naturally, with sounds being full volume within a certain range, and then softly falling off until they are completely quiet. This makes for a smoother transition between "This sound is full volume" and "I dont hear this sound".
Co-authored-by: ff <ff>
Implements the ?. operator, replacing code like A && A.B with A?.B
BYOND Ref:
When reading A?.B, it's equivalent to A && A.B except that A is only evaluated once, even if it's a complex expression like a proc call.
