About The Pull Request
Wall items mostly use the direction from the floor to the wall in the named mapping helper. Wall items mostly use the direction from the wall to the floor for the internal dir variable.
This leads to a headache when it comes to working out what conflicts with what, and what needs placing where.
Wall frames provided a member, inverse, which specified whether or not to invert the direction of the item when looking for conflicts. It was also used to specify whether to look for conflicts outside of the wall (cameras and lights appear external to the wall) or inside the wall (most wall items). This flag was set for Intercoms, APCs, and Lights. Since APCs and Lights expect a floor-to-wall direction, and Intercoms expect a wall-to-floor direction, this means that APCs and Lights were getting the correct direction, and Intercoms were getting the wrong direction.
Some implications of this setup were:
You could build an APC on top of another wall item, provided there was nothing external attached to the wall and the area didn't have an APC.
You could stack Intercoms indefinitely on top of the same wall, provided you weren't in a one-tile wide corridor with something on the opposite wall.
Or both! Here's twenty Intercoms placed on the wall, and a freshly placed APC frame after placing all Intercoms and deconstructing the old APC:
endless-stack-of-intercoms
Not everything used this inverse variable to adjust to the correct direction. For example, /obj/machinery/defibrillator_mount just used a negative pixel_offset to be visually placed in the correct direction, even though the internal direction was wrong, and never set! This also let you stack an indefinite number of defib mounts on the same wall, provided it wasn't a northern wall... except you could do this to northern walls too, since defibs weren't considered a wall item for the purposes of checking collisions at all!
Ultimately, every constructable interior wall item either used this inverse variable to adjust to the correct placement, set a negative pixel_offset variable to have its offset adjusted to the correct placement, or overrode New or Initialize to run its own checks and assignment to pixel_x and pixel_y!
Inventory: Table of various paths, related paths, and the adjustments they used
Unfortunately, untangling /obj/structure/sign is going to be another major headache, and this has already exploded in scope enough already, so we can't get rid of the get_turf_pixel call just yet. This also doesn't fix problems with the special 2x1 /obj/structure/sign/barsign.
Some non-wall items have been made to use the new MAPPING_DIRECTIONAL_HELPERS as part of the directional cleanup.
tl;dr: All wall mounted items and some directional objects now use the same direction that they were labelled as. More consistent directional types everywhere.
Why It's Good For The Game
fml
Changelog
cl
refactor: Wall mounted and directional objects have undergone major internal simplification. Please report anything unusual!
fix: You can no longer stack an indefinite amount of Intercoms on the same wall.
fix: Defibrillator Mounts, Bluespace Gas Vendors, Turret Controlers, and Ticket Machines are now considered wall items.
fix: Wall mounted items on top of the wall now consistently check against other items on top of the wall, and items coming out of the wall now consistently check against other items coming out of the wall.
fix: The various directional pixel offsets within an APC, Fire Extinguisher Cabinet, Intercom, or Newscaster have been made consistent with each other.
fix: The pixel offsets of Intercoms, Fire Alarms, Fire Extinguisher Cabinets, Flashers, and Newscasters have been made consistent between roundstart and constructed instances.
fix: Constructed Turret Controls will no longer oddly overhang the wall they were placed on.
qol: Defibrillator mounts now better indicate which side of the wall they are on.
fix: Some instances where there were multiple identical lights on the same tile have been fixed to only have one.
/cl
Implements the Modernizing radiation design document ( https://hackmd.io/@tgstation/rJNIyeBHt ) and replaces the current radiation sources with the new system, as well as replacing/removing a bunch of old consumers of radiation that either had no reason to exist, or could be replaced by something else.
Diverges from the doc in that items radiation don't go up like explained. I was going to, but items get irradiated so easily that it just feels pretty lame. Items still get irradiated, but it's mostly just so that radiation sources look cooler (wow, lots of stuff around going green), and for things like the geiger counter.
Instead of the complicated radiation_wave system, radiation now just checks everything between the radiation source and the potential target, losing power along the way based on the radiation insulation of whats in between. If this reaches too low a point (specified by radiation_pulse consumers), then the radiation will not pass. Otherwise, will roll a chance to irradiate. Uranium structures allow a delay before irradiating, so stay away!
## About The Pull Request
stop forgetting to include mapload, if you don't include it then every single subtype past it by default doesn't include it
for example, `obj/item` didn't include mapload so every single item by default didn't fill in mapload
## Regex used:
procs without args, not even regex
`/Initialize()`
procs with args
`\/Initialize\((?!mapload)((.)*\w)?`
cleanup of things i didn't want to mapload:
`\/datum\/(.)*\/Initialize\(mapload`
Converts most spans into span procs. Mostly used regex for this and sorted out any compile time errors afterwards so there could be some bugs.
Was initially going to do defines, but ninja said to make it into a proc, and if there's any overhead, they can easily be changed to defines.
Makes it easier to control the formatting and prevents typos when creating spans as it'll runtime if you misspell instead of silently failing.
Reduces the code you need to write when writing spans, as you don't need to close the span as that's automatically handled by the proc.
(Note from Lemon: This should be converted to defines once we update the minimum version to 514. Didn't do it now because byond pain and such)
I want to use this behavior on some other things so into a component and element it goes. Gas leaking is handled by a component so it can process whereas the object breaking and causing an explosion is handled by an element. Some minor changes were made so canisters were more consistent in leaking.
Creates update_name and update_desc
Creates the wrapper proc update_appearance to batch update_name, update_desc, and update_icon together
Less non-icon handling code in update_icon and friends
Signal hooks for things that want to change names and descriptions
99%+ of the changes in this are just from switching everything over to update_appearance from update_icon
Converts many proc overrides to properly use list/modifiers, fixes some spots where modifiers should have been passed, calls modifiers what it is, a lazy list, and cleans up some improper arg names like L, M, C, and N. Oh and I think there was a spot where someone was trying to pass M.name in as a string, but forgot to wrap it in []. I fixed that too.
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
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.
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.
Replaces like 70-80% of 0 and such, as a side effect cleaned up a bunch of returns
Edit: Most left out ones are in mecha which should be done in mecha refactor already
Oh my look how clean it is
Co-authored-by: TiviPlus <TiviPlus>
Co-authored-by: Couls <coul422@gmail.com>
About The Pull Request
For an item to be two handed just add this handy component.
All existing two handed items have been converted to use this component.
Why It's Good For The Game
It has components and signals, and now you can make items two handed so simply.
/obj/item/shockpaddles/ComponentInitialize()
. = ..()
AddComponent(/datum/component/two_handed)
removes materials list from items, uses custom_materials instead. This might introduce some bugs so we should testmerge this for a while (and Ill test stuff locally as much as I can)
this also adds material crafting to sheets. Test case being chairs. In the future we can add stuff like tables, walls, doors etc.
also applies materials to everything, with fixes, which can close#46299
About The Pull Request
Converts every single usage of playsound's vary parameter to use the boolean define instead of 1 or 0. I'm tired of people copypasting the incorrect usage.
Also changes a couple of places where a list was picked from instead of using get_sfx internal calls
This was done via regex:
(playsound\(.+,.+,.+, ?)1( ?\)| ?,.+\)) to match 1
(playsound\(.+,.+,.+, ?)0( ?\)| ?,.+\)) to match 0
full sed commands:
/(playsound\(.+,.+,.+, ?)1( ?\)| ?,.+\))/\1TRUE\2/ 1 to TRUE
/(playsound\(.+,.+,.+, ?)0( ?\)| ?,.+\))/\1FALSE\2/ 0 to FALSE
I'm not very good with regex and these could probably be optimized, but they worked.
Why It's Good For The Game
Code usability
About The Pull Request
Adds 'notice' span class to all visible_messages which had no span class, making all those black messages blue.
Why It's Good For The Game
This should help differentiate action-messages from talking-messages in the chat. More actions will be blue, thus black talking-messages should pop out more.
* small changes
* Adds a use_tool helper and changes some tools to use it
* Ports most tool operations to use_tool
* Converts more tool operations to use_tool and tool_act
* Changes some things to default_unfasten_wrench
* Improves tool_behavior support in mech construction
* Code review memes
* Fixes all instant use_tool calls failing
* Code improvements
* merge fixes
* Fixes#20747.
You may now use your ID to unlock the display case.
Fireaxe cabinet and display case may now be repaired with the welder.
* Welder amount.
* Fire axe welder amount.
* Adds comments to the display case
* Captains display case now requires specops access
Please refer to #20867 and #20870 for a easier view of the changes. Those two PRs show all meaningful changes (hopefully) and doesn't show the files changed with just 3 lines changed.
This PR does three things:
It makes all children of /obj/ use the same damage system.
Previously to make your new machine/structure be destroyable you needed to give it a var/health, and its own version of many damage related proc such as bullet_act(), take_damage(), attacked_by(), attack_animal(), attack_hulk(), ex_act(), etc... But now, all /obj/ use the same version of those procs at the /obj/ level in code/game/obj_defense.dm. All these obj share the same necessary vars: obj_integrity (health), max_integrity, integrity_failure (optional, below that health level failure happens), and the armor list var which was previously only for items, as well as the resistance_flags bitfield. When you want your new object to be destroyable, you only have to give it a value for those vars and maybe override one proc if you want a special behavior but that's it. This reorganization removes a lot of copypasta (most bullet_act() version for each obj were nearly identical). Two new elements are added to the armor list var: fire and acid armor values.
How much damage an obj take depends on the armor value for each damage category. But some objects are INDESTRUCTIBLE and simply never take any damage no matter the type.
The armor categories are:
-melee(punches, item attacks, xeno/animal/hulk attacks, blob attacks, thrown weapons)
-bullet
-laser
-energy (used by projectiles like ionrifle, taser, and also by EMPs)
-bio (unused for this, only here because clothes use them when worn)
-rad (same)
-bomb (self-explanatory)
-fire (for fire damage, not for heat damage though)
-acid
For machines and structures, when their health reaches zero the object is not just deleted but gets somewhat forcedeconstructed (the proc used is shared with the actual deconstruction system) which can drops things. To not frustrates players most of these objects drop most of the elements necessary to rebuild them (think window dropping shards). Machines drop a machine frame and all components for example (but the frame can then be itself smashed to pieces).
For clothes, when they are damaged, they get a "damaged" overlay, which can also be seen when worn, similar to the "bloody" overlay.
It refactors acid. See #20537.
Some objects are ACID_PROOF and take no damage from acid, while others take varying amounts
of damage depending on their acid armor value. Some objects are even UNACIDABLE, no acid effect can even land on them. Acid on objects can be washed off using water.
It changes some aspect of damage from fires.
All /obj/ can now take fire damage and be flammable, instead of just items. And instead of having just FLAMMABLE objs that become ON_FIRE as soon as some fire touch them (paper), we now have objects that are non flammable but do take damage from fire and become ashes if their health reaches zero (only for items). The damage taken varies depending on the obj's fire armor value and total health. There's also still obj and items that are FIRE_PROOF (although some might still be melted by lava if they're not LAVA_PROOF).
When a mob is on fire, its clothes now take fire damage and can turn to ashes. Similarly, when a mob takes melee damages, its clothes gets damaged a bit and can turn to shreds. You can repair clothes with cloth that is produceable by botany's biogenerator.
It also does many minor things:
Clicking a structure/machine with an item on help intent never results in an attack (so you don't destroy a structure while trying to figure out which tool to use).
I moved a lot of objects away from /obj/effect, it should only be used for visual effects, decals and stuff, not for things you can hit and destroy.
I tweaked a bit how clothes shredding from bombs work.
I made a machine or structure un/anchorable with the wrench, I don't remember which object...
Since I changed the meaning of the FIRE_PROOF bitflag to actually mean fire immune, I'm buffing the slime extract that you apply on items to make them fire proof. well now they're really 100% fire proof!
animals with environment_smash = 1 no longer one-hit destroy tables and stuff, we give them a decent obj_damage value so they can destroy most obj relatively fast depending on the animal.
Probably a million things I forgot.
If you want to know how the damage system works all you need is the three obj vars "obj_integrity", "max_integrity", "integrity_failure", as well as the armor list var and the resistance_flags bitfield, and read the file obj_defense.dm
* a very calming act
when the world is too much, too fast
* i'm tired
but i have to be efficient, infinite
* lick your lips at the sight of me
a fantasy made reality
