Replaces GLOB.poi_list |= src and GLOB.poi_list -= src with an element that handles it directly.
More consistent code, especially when a lot of code couldn't decide how to add/remove (some |=, some -=, some .Remove, etc).
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.)
This is an alternative to the PR Ryll made, it does some things similar e.g. the default limit of 1 interaction per target for a person, however, it refactors do_afters to support overrides for max interaction counts and unique sources.
For example, stripping uses the item being stripped as the source, allowing you to strip multiple items, but not the same item multiple times.
I've also fixed most other edge-cases this could cause where balance would be affected, but feel free to point out any I might've missed, this'll probably require some longer-term testmerging.
Mech code now does a basic check for the amount of remaining ammo to adjust the amount of custom materials of an ammo container based on the remaining ammo against the original amount of ammo.
When the ammo runs out, it's hard-set to 2000 iron as that's the value of the sheet of iron that it gets set to by the end.
Grenades have, for the longest time, used the proc name preprime() to refer to arming a timed grenade so that it will boom in a few seconds, and prime() to refer to the grenade actually going boom (or releasing foam or anything else grenades do when they go off). This was very confusing, so now these two procs are called arm_grenade() and detonate().
For whatever reason we hardcoded the health value for drills at 200 brute damage before they can gib. 200 brute damage was picked as it was double the max health of /mob/living/carbon/whatever and double the max health was like, the cap on brute damage when someone is really, really, really, really dead.
Enter simplemobs. Their max health is regularly under 100, which means a hardcoded value of 200 brute damage to trigger gibbing effects is bad. Not that it matters anyway, because simplemobs also brute damage cap at maxHealth instead of maxHealth * 2 so the only simplemobs that could be gibbed by mech drills are those with 200 or more health.
This has been changed. Simplemobs now cap out at maxHealth * 2 damage, in line with all other /mob/living while drill code has been changed to check for maxHealth * 2 when gibbing instead of a hardcoded 200.
This changes how carbon/humans stabilize body temperature, and changes how damage and wounds are applied based on temperature.
Humans now have a core body temperature along with body temperature. The core temperature is used for natural stabilization and what viruses like fever and shivers target by raising or lowing the core temperature of the mob.
The standard body temperature still exists and acts exactly the same for most items at this time but is now treated as surface temperature in humans.
Damage from body temperature for humans is now based on the core temperature instead of body temperature now.
Humans will now receive burn wounds when the body (surface) temperature is to high for to long.
This causes you to see alerts for the area temperature before you take damage in most cases improving visibility of dangerous situations.
My original intention was just fixing an issue with the Mk-honk banana shoes but, considering I didn't want to add two new variables to a component with already lot of args and lengthy AddComponent() calls in term of text, I had to merge some TRUE/FALSE variable/args into the breakdown_flags bitfield (now named mat_container_flags) in the process.
Ridden vehicles now pass any objects that normally pass tables. This includes bullets, thrown objects, and probably dwarves?
Ridden vehicles check for the various incapacitation traits instead of just usable hands for whether you fall off. Doesn't fix corpses buckled to these objects but that'll require more work to fix because it's all tied into relay_move.
This doesn't affect any ridden object that doesn't checks for hand availability. Like skateboards and wheelchairs (although how exactly your wheelchair is moving without hands or mechanical parts is beyond me).
Vehicle objects now call bumpopen() rather than Bumped() when moving into an airlock, and thus will once again open any door the pilot has access to. Closes#54480
Fixes Ripley MK-I to MK-II conversions destroying equipment.
MK-I to MK-II conversions now sets the MK-II's integrity to be same percentage as the MK-I's integrity. Thus, upgrading a full-health MK-I will no longer result in a damaged MK-II.
Both Ripley types no longer start with an orebox, that function has been moved to the Clarke.
Originally I wanted to fix an issue where the `get_up()` `do_after()` would ignore the callback checks, because it was `uninterruptible`, so that made me refactor these procs to allow for higher granularity on checks and standardize behavior a bit more.
There's more work to be done for them, but one thing at a time.
* Removes the `uninterruptible` check in favor of the more granular `timed_action_flags`
* Cleans code on the `do_atom`, `do_after_mob`, `do_mob` and `do_after` procs to standardize them a little better.
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.
This is a pretty big change all around. The gist of it is that it moves the mobility_flags into traits or variables that can track the sources, and to which we can append code to react to the events, be it via signals or via on_event-like procs.
For example, MOBILITY_STAND could mean, depending on context, that the mob is either already standing or that it may be able to stand, and thus is lying down.
There was a lot of snowflakery and redefinitions on top of redefinitions, so this is bound to create bugs I'm willing to fix as I learn them.
The end-goal is for every living mob to use the same mobility system, for the traits to mean the same among them, and for no place to just mass-change settings without a way to trace it, such as with mobility_flags = NONE and mobility_flags = ALL
Fixes AIs being able to strip nearby people. They've lost their hands usage.
Adds and implements alloy materials
Takes several materials that were mostly fluff and converts them into actual usable materials.
Messes with material code a bit to make alloys recycle back into their component materials.
Adds the alloy materials to their in-game stacks.
Materials added:
Plasteel
Plastitanium
Plasmaglass
Titaniumglass
Plastitanium Glass
Alien Alloy
Makes plasteel/plastitanium/plasmaglass and the rest able to have separate properties from their component materials. It doesn't make much sense that the materials used to seal off the supermatter chamber from the rest of the station would be prone to exploding when heated.
Allows for further expansion of materials, possibly including actual functional metallurgy and smelting at some point in the very distant future.
(Lemons note: Adds a regeneration component, used for alien alloy)
overrides weren't detected by should not sleep, i think i've mostly
fixed that with SpaceManiac/SpacemanDMM#214
Some of these are wacky but overall this pr is harmless
signals shouldnt sleep even in weird 1 in a million situations or due
to other people adding bad code
overrides of changeling can_sting() use alert() and input() and that's
just too fucked for me to fix in this pr
Yellow slime extract can no longer turn into a self-charging yellow slime core. This functionality has been completely removed.
Hypercharged yellow slime cores no longer self-charge.
They now have a capacity of 50,000 (up from their previous 20,000). This is 10,000 more than a bluespace power cell.
Their recharge rate is 2500. This is relatively slow for the power capacity, as hyper and bluespace cells charge at 10% of their capacity respectively and this is 5%.
Motorised wheelchairs have had their power usage reduced to 5% of their previous value since they were basically only usable with rechargable cells before
Splits the restrained() proc into component traits: TRAIT_HANDS_BLOCKED for the general inability to use hands and TRAIT_RESTRAINED for the more specific condition that permits arrests.
Code moved away from the update_mobility() proc so it doesn't have to wait for an update, instead changing based on events. The idea is to eventually kill that proc.
Wrapper proc added for setting the handcuffed value so we can react to the event of it changing.
Kills the RestrainedClickOn() proc. That is now just an UnarmedAttack(), in where the ability to use hands can be checked. Monkeys keep their bite attack and humans their self-examine.
All ui_act procs should call parent by default. All procs should preserve the value of the parent proc when it's TRUTHY and pass it down the call stack. No UI should be interactible when its flags or state indicate it should not be, except when explicity overriden by child procs intentionally disregarding parent return values to achieve a specific goal.
First, this removes 'The Whip' wheelchair as it doesn't show up anywhere or really do anything so it's kind of bloat. The other thing this does is make the metal and gold wheelchairs foldable into an item, like the rollerbeds. Motorized wheelchairs are not foldable. The metal wheelchair item does as much damage as a chair, and the gold one packs an extra oomph. Hiynastrike helped me with the sprites.
- Backtick-escape code samples which contain `[]` syntax.
- Fix all crosslinks to nonexistent symbols.
- Somewhat improve docs for qdel defines, research defines, dynamic mode, and others.
- Remove unused bloodcrawling defines.
Some crosslinks to defined but undocumented symbols remain. For BYOND builtins, a future dmdoc version may link those symbols to their entries in the DM reference. Other symbols could be documented by a future PR.
New "file" crosslinks as used in `research.dm` are slated for release in a future dmdoc version.
Fixes these issues with mechs:
Mechs aren't using power to move (broken in #52902)
Gygax leg actuator button is opposite of what it should be (off when it should be on) (broken in #52902)
Mechpads don't actually send mechs
None of the error messages for failing to move work
Jared-Fogle
silicons
Qustinnus
TiviPlus
ArcaneMusic
Ryll Ryll
Timberpoes
Ghom
NightRed
TemporalOroboros
ShizCalev
InvalidArgument3
necromanceranne
Rohesie
zxaber
ZeWaka
spookydonut
Coffee
Tad Hardesty
Mickyan
msgerbs