Makes it so that the RCD attack chain stops after pre_attack
where the RCD for example replaces an lattice in in pre_attack which then causes a runtime in the attackby code.
It seems like all of the RCD stuff is handled pre_attack so it should be fine to stop the chain here.
The RCD also has the NOBLUDGEON flag meaning you can't attack with it anyways.
Sometime ago I cleaned a slice of the winter coats to cut on copy pasta in their allowed list and important items being missed there but I misunderstood how the global list of allowed security items work, which ended up with the global list overwriting my base list.
So this fix that, also thanks Athath for bullying me about this issue a few months ago before I went on coding hiatus...
Also since I was here I decided to fix the allowed list for the janitor winter coat, it had some odd items without a worn_icon so we had the annoying bugged sprites with it.
Refractors the cyborg reboot module to be an independent item rather than a subtype of cyborg upgrades. The new item is no longer consumed during use.
Rebooting now makes a different sound when rebooting an AI shell or ghostless borg, rather than no sound at all.
A recent PR fixed a longstanding apparent bug that allowed reboot boards to be resused. A bug it may have been, but the reboot board being a single-use item is kinda terrible, and doesn't make a lot of sense that the board is somehow destroyed when used. Mothblocks, who merged the bugfix PR, has given me permission to PR this change.
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
If you wear the french beret you get the garlic breath trait added.
This also happens if you consume garlic reagent containing items
This trait makes your kisses become french and causes your breath to
smell of garlic
Preventing the creation of stub pipes involved adding a lot of checks to ensure a pipe could never be created with only one or no directions connectable. This PR adds feedback for when this happens, rather than appearing to silently fail - yet still generating the "I did something!" sparks.
Slightly better UX and feedback hopefully makes dealing with a fairly complicated system slightly easier
Changes tank explosions to take tank volume into account and use sqrt scaling when calculating explosion range.
This basically means that they scale faster at lower pressures and slower at high pressures.
Rebalances tank explosion scaling so that maxcap TTVs are where they used to be pressure-wise.
Rebalances the research doppler arrays cash generation algorithm so it maxes out at the same TTV pressure. This does however mean that the doppler array will grant more points at lower explosion pressures.
Rebalances blastcannon shot range calculation so it scales as it used to with normal TTVs.
The comparatively tiny emergency tanks no longer produce the same size explosion as a TTV at the same pressure.
It is much more difficult to carry around 70 maxcaps in a single duffle bag. (I don't think it renders this completely impossible but it does kill oxy-trit emergency tank singlecaps as far as I know.)
Lemon posting past this line.
How it works:
Change assumes maxcaps should be just as easy with the standard ttv setup of 2 70L tanks.
So it divides the bomb's strength by 14, then scales it using dyn_explosion's (x*2)^0.5.
If you graph it the strength is exactly the same with a 140L reaction vessel, but as volume goes down, strength falls off very quickly because of that division, and the use of dyn_explosion.
Hopefully this will effectively disincentivize singlecapping, and remove the everpresent threat of someone leaking the station leveling method.
Reasoning for when github blows up:
I don't think single caps are on the same level as typical atmos antag threats. They're a hell problem
1: tanks should explode when someone hyper pressurizes them
2: we want all tank explosions to act the same, for the sake of a believable world
3: really well put together tank explosions (ttvs), should be really powerful
4: reaction code is a son of a bitch
I do think knowledge gating has some place. Knowing how to do something well should have a benefit. but that isn't like, an ultimate truth.
I've seen what proper, full on atmos autism single capping looks like. I don't like that level of absolute destruction at speed being feasible full stop.
I consider single caps to be a necessary side effect of how explosion code works. I think it's really cool that people have gotten so deep into this game and the systems around it that they've started optimizing this side effect into a tool/bragging rights thing.
But I'm still not a huge fan. If big booms are gated only by knowledge, then as soon as that knowledge spreads we're fucked. I've seen this happen before with things like rad batteries (cue crit being cringe).
It's not just single caps mind, the destruction you can make with em scales with knowledge.
I'm not in love with this pr mind, because it means I need to worry about bomb code when someone makes some silly tank volume balance pr. but it's a good solution. better then what's been tried in the past. still leaves space for things just blowing up in your face without maxcaps coming into the equation easily.
About The Pull Request
Rewrites the entire preferences menu in tgui. Rewrites the entire backend to be built upon datumized preferences, rather than constant additions to the preferences base datum.
Splits game preferences into its own window.
Antagonists are now split into their individual rulesets. You can now be a roundstart heretic without signing up for latejoin heretic, as an example.
This iteration matches parity, and provides very little new functionality, but adding anything new will be much easier.
Fixes#60823Fixes#28907Fixes#44887Fixes#59912Fixes#58458Fixes#59181
Major TODOs
Quirk icons, from @Fikou (with some slight adjustments from me)
Lore text, from @EOBGames (4/6, need moths and then ethereal lore from @AMonkeyThatCodes)
Heavy documentation on how one would add new preferences, species, jobs, etc
A lot of specialized testing so that people's real data don't get corrupted
Changelog
cl Mothblocks, Floyd on lots of the design
refactor: The preferences menu has been completely rewritten in tgui.
refactor: The "Stop Sounds" verb has been moved to OOC.
/cl
Just this, small QoL because having to build a full autolathe to get a gas analyzer is annoying.
You can now search for gas when looking for the analyzer on the autolathe or protolathe, way more intuitive.
I would rename it from /obj/item/analyzer to /obj/item/gas_analyzer but it would change so many files... another day perhaps...
Radiation collectors and tesla coils being able to create research points was removed in 92209dd. This stops references to power-based research point generation from appearing.
Research by power is long gone
Restore flavor to power collecting circuitboards
H/T EricZilla
Merged the item/melee/classic_baton and item/melee/baton families in this unholy matrimony.
Bad jokes aside. I have refactored the underlying code of both items with the scope of reducing potential copypasta,inconsistencies, logging, renewing some old code (like teleprods) and extending the anti-dual batoning and TRAIT_STUNRESISTANCE code** to all batons and not just security ones. Otherwise, I have tried to maintain the gameplay functionality of these items intact. They work just like they did for the most part.
** A badly designed feature that only considers one source of knockdowns - stunbatons - out of a multitude of different devices with corresponding purposes present in the game. The only thing it does is reduce the knockdown from them by 90%. The stamina damage and confusion are fully applied. The knockdown from batons is 5 seconds, standing up takes an extra 1 second and the baton cooldown is about 2.5. Doing the math, you'll have the grand advantage of one puny second of not lying horizontal on the floor with this trait before getting batoned again by the same guy because the stamina damage and the confusion have really hampered your chances of getting some distance. I wish to make the trait suck less in the future, but for now I'm including a slight gameplay change here, more for consistency than anything because as I already told you, it'll still be disappointingly bad per se.
The abductor baton is also no more a subtype of stun batons but batons, which don't use power cells to work. Its power cell is effectively infinite and can't be removed, and It overrides functions such as toggling the baton on/off. It hinders maintainability to keep it a subtype of stun batons.
Replaced the anchored check for mobs in teleprods with one for overwhelming move resistance and removed its clumsy_check copypasta (it was stunning clowns twices).
* Immediately connect on smart pipe reprogram
Previously, a smart pipe reprogrammed to permit a new direction would
connect to a device or pipe that was added later, but not to any
existing device or pipe.
* Dishonor for my ancestors and shame to my family
* Die alone and unloved
it turns out that admins use the removed information in #61179 for faster live in-round logging, I've restored that information under a LOG_VICTIM category that should not interfere with mind-reading and ling absorb text
Implements a helper proc for generating emissive blockers.
Makes everything that generates an emissive blocker overlay use the new helper.
Grants all emissive blockers and emissive overlays KEEP_APART, RESET_COLOR, and RESET_TRANSFORM.
Also fixes the jack-o-lantern worn overlays so that they actually glow while they are active.
Title, please say hello to the element "chemical_transfer" and the component "faction_granter"
Componentized behavior is easier for admins to make events out of, more modular for code maintainability, lowers the possibility of future copy and paste, set me up with my wife, and more
One of the things I personally like the most about it is the ability for each behavior to properly be described on examine, which I loooooove!
Also, these should be fantasy affixes after the freeze is done
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
One final change I wanted to make to ants was to rework their rather low damage values. While they by no means were ever intended to be a kill-chem, the fact that they only did 25 brute after being injected with 200u was just far too low.
To change this, I've reworked their damage formula, so now you do roughly 32 brute damage with 100u of ants. This scales significantly once you add more ants after that point.
This is still a rather low amount of damage for the amount of u it takes, so to balance that I made the chance for one to vomit out the ants also stun the user, however to balance that balance it will purge anywhere from 5-10u of ants upon doing so.
I have also changed how the debuff works somewhat. While it still does its normal damage over time, I have increased the damage done by the user scratching at themselves, which yielded an average of 100 brute when dumped with 200u ants during testing.
Finally, you can pour ants back onto the ground now, with the amount of ants being poured being directly proportional to the amount of damage they will do. You must pour more than 10 ants for it to appear, and the amount of ants will only change the maximum damage that the resulting caltrop will do, not the minimum damage. There is a hard-cap at a 10 damage maximum, with the minimum always being 0.5. The amount of damage this caltrop does is equal to `ant_volume * 0.2`
Finally to balance this a little more, breeding ants has gone from requiring 6u sugar to 8u sugar, making farming take a little longer.
New default color is green, also grey has been renamed to omni to ease new players without code diving (or changelog reading)
Moved the colors so that green is the first and the omni is the last
Made all say()s deal with encoding, audited all uses of say() to prevent double encoding or like, manually inserting span().
I left some stuff without sanitize that only draws from the code, since it's hell to clean up otherwise. That
and I let admins do whatever the fuck they want
stored_card.GetAccess() eventually leads to /obj/item/card/id/GetAccess() being called. This proc returns the actual access list associated with the ID card rather than a .Copy() of it.
As a result, the line total_access = stored_card.GetAccess() is storing a reference to the stored_card's actual access list.
total_access |= card_slot2.stored_card.GetAccess() is then mutating the first ID card's access list via the reference.
The result? When /obj/item/computer_hardware/card_slot/GetAccess() is called with 2 ID cards in a modular computer, the second ID card gives all of its accesses to the first ID card thanks to the |= operation.
There are a number of ways around this. Some pieces of code do var/list/thing = list() and then |= every GetAccess() since it's guaranteed to return a list. This creates new lists instead.
However, I feel GetAccess() for ID cards really shouldn't be returning a ref to the list. Instead, it now returns a Copy() of the list and code implementing behaviour using GetAccess() doesn't need to worry about list mutation at all.
In remembrance of all those people who used jump boots to cross lava unaware of an issue c*ders wouldn't fix....
EDIT: This is now a lava and weather immunities refactor:
Weather immunities are now status traits since they have a multitude of sources (especially for lava) which might conflict with one another otherwise.
The lava burn_stuff proc has also been been refactored in different procs, mostly because of that snowdin subtype with inconsistent, old checks.
Weather datums should now use can_weather_act instead of weather_act to check if something can be affected by weather or not, as they should.
All movables can protect contained mobs if they have the relative weather immunity traits. This works at any contents depth.
No more snowflake weather_protection variable for closets.
Removed the weather_immunities list from living mobs (simple animals still have it but it's only for traits assignment on init because way too many child types lack the immunities of their parents).
Removed some unused defines.
Renamed some variables as per guidelines.
It has been tested.
And yea, jump boots fixed because that's the original scope of this PR.
(Initially just made throwing make you fire immune, that was blocked because it breaks perma stuff, instead it ended up be a refactor to make jumpboots usable with weather immumnity stuff
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
Meat steaks now have the material flag to un-link from from material effects, meaning that monkey meat will now have the proper nutrients and reagents it was intended to, primarily that monkey meat will have protein for cytology purposes.
(Basically, the meat mat was not adding a food component, but then trying to remove "any" food component regardless of a material_no_effects flag. Kinda a mess, and maybe this could be done in an event based way, but this is a real sane fix. The hard part was tracking down the error anyway. Kudos fictional arcane who will read this commit message)
Simple_animals / mobs are the biggest lie in this code-base. They're far from simple and have an extreme god-object problem. Especially when you get to /hostile, where there is so many procs, vars, and what not, that you can't make any interesting additions without snowflaking the hell out of the code.
This PR hopes to help kill this problem by introducing a new /living subtype, /living/basic. The idea of this refactor is to slowly start moving all old simple_animals to this new system, moving over behaviors like charging and more extravagant mobs like megafauna over bit by bit similar to how newfood was implemented.
One of the other big goals of this refactor is to move many of the fringe simple animal behaviors into either AI datums, or components/elements. (Some of which still needs to be done in this PR).
As a proof of concept, I created the base mob/living/basic, and moved cockroaches over to the system. Since cockroaches have both a passive, melee and ranged mob.
This PR does slightly affect balance as the behavior isn't 1-on-1 due to it no longer running on the janky /hostile behavior, but I tried to keep the effects to a minimum, and the glockroach and hauberoach are not spawnable through many means as far as I know.
* Smart pipes now actually go over smart pipes
This was ostensibly the main feature of smart pipes, so should be
fairly important
Parentheses are technically not required around the |, but I think
it's important to emphasise the importance of parentheses around
bitwise operators as this was apparently broken since 3e8407c471
Also purge var/connections and var/connection_num, since it's
literally only used for a `machine.connection_num < 3` check
which is completely redundant, and we already build a bitfield
tracking active directions.
* Smart pipes bridge over straight pipe types
This improves bridging to now go over most devices where possible,
letting you, for example, bridge over a perpindicular layer adapter.
* Pipe construction: Better documentation
Cleans up smart pipe documentation to match what's actually happening.
No functional changes.
* Skip pipes on different layers earlier
This prevents a pipe being made into a bridge perpindicular to a pipe
on a completely different layer, then failing to turn into a bridge
perpindicular to a relevant pipe.
* Pop superfluous parentheses
* Prevent creation of stub pipes
Setting the RPD to create a smart pipe that can only connect in one
direction would cause it to create invisible pipes that would still
block the placement of other pipes.
* The RPD can now reprogram smart pipes
The RPD can only affect smart pipes in directions that they are not
currently connected to.
This makes it easier to adjust designs after the fact, including
prevening round-start pipes from eagerly linking to a grey layer
adapter.
* Even smarter pipes
No more turning into bridge pipes. We now only try to be smart if
placement would fail, and we do our best to find a solution
whenever there is at least one smart pipe involved, regardless
of whether we're currently placing a smart pipe or not.
We never reconfigure any directions that a smart pipe is currently
connected, and we never reconfigure a smart pipe to have one or less
usable directions.
* Smartly go across perpindicular layer adapters
Also works when we're placing a layer adapter perpindicular to a
promiscuous smart pipe
* Pipes: Factor out loops and some bitfiddling
Create and use helpers with documented purposes over inline bitfiddling,
when it makes sense.
Many loops and switch statements were recreating information that was
already there.
Some relationships between pipe bitfield states were already assumed.
This centralises the functionality that relies upon these assumptions,
places them where the bits are defined, and documents them.
Rewrite some bitwise operations to be more idiomatic.
* Smart pipes: Debugging output
I normally clean history before pushing changes to any project,
but I feel like this should be saved.
* Revert "Smart pipes: Debugging output"
This reverts commit bb3aa76cf6d08e4d0951113a26fc9d48b6bc1735.
* Add trailing comma
The lack of this was making the linter sad
Makes stack code support merging two different stacks with the same mats, but different mats_per_unit numbers by implementing averages.
It's in an attempt to support the stupid efficiency shit that protolathes do. It's not great, but it ought to work alright for now. Kinda a bandaid
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
This PR kills off the transforming subtype of /obj/item/melee and replaces it with a component to handle the transforming behavior, /datum/component/transforming.
The transforming component handles updating the variables of an item when it's transformed. Things like force, sharpness, whetstone force bonus, and attack verbs. Similar to the two-handed component, but instead of transforming into a two-hander it remains a one handed weapon.
The "nemesis" behavior (dealing addition damage to certain factions) of the transforming subtype was moved to the cleaving saw only, since it was the only transforming item that used it. In the future, this can be made into a bespoke element/component as well.
The following weapons and items have been updated to use this component:
Energy Swords / Sabers / Bananium Energy Sword
Energy Circular Saw
Energy Dagger
Energy Axe
Toy Energy Sword
Holographic Energy Sword
Switchblade
Advanced Medical Tools (Laser scalpel, Mechanical Pinches, Searing Tool)
Advanced Engineering Tools (Hand Drill, Jaws of Life / Syndicate Jaws of Life)
Combat Wrench
Cleaving Saw
Telescopic Batons / Contractor Batons
Roasting Stick
Telescopic Riot Shield
Energy Shield / Bananium Energy Shield
This PR also touches up the code around the various above items.
Gamer025