Whatever you do, if it warrants the use of something like
`handle_atom_del`, chances are `Exited` can do it better, as most of
these cases involve movables that shouldn't be moved out of their loc
(`Destroy` forcefully moves movables to nullspace) without calling
specific procs, and for the remaining few, `handle_atom_del` doesn't
even cover the eventuality of a movable being deleted outside the source
atom, so it's quite garbage.
Beside, I feel confident in saying `handle_atom_del()` is older than the
DCS, an echo on the workarounds done at the time.
## About The Pull Request
Spiritual successor to #76716
- Some spells can now be cast while the mob is within the contents of
certain atoms.
- PAIs can now cast if within a PAI card
- AIs can now cast if within an AI card
- People within vehicles (mechas and cars) can now cast their spells
- Repulse and Knock now have unique interactions for being cast within a
locker
## Why It's Good For The Game
Carlac's PR gave me an idea for how to tackle this in a relatively clean
way so I went ahead and adapted the suggestion to something that works
for the cast chain.
This isn't perfect, some spells will need to be updated, but they can be
done piecemeal.
This is something that, IN THEORY, should have already been wholesale
supported by the spell refactor - any atom you pass into the cast chain
should "just work ™️ ", either rejecting if it fails the valid target
check or doing the spell effects as if the atom passed was the caster.
## Changelog
🆑 Melbert
add: PAIs can now cast wizard spells should they have any.
add: AIs located in intellicards can now cast wizard spells should they
have any.
add: Some spells, such as AoE or conjure spells, are now castable from
within Mechas or Clown Cars. To varying degrees of success.
add: Knock will now unlock and open closets you are hiding within.
add: Repulse will now throw open closets you are hiding within.
/🆑
## About The Pull Request
New emagged pAIs improvements:
- Disables the range restriction
- Renamed the `Malicious Software Detected` button to `Reset Software`
since it resets the software to default state
- Added a new law notification and flavor texts
## Why It's Good For The Game
More unique emag effects are good. Plus this adds some polish to the
current emag effects so the UI is smoother.
## Changelog
🆑
add: Add pAI movement freedom when emagged.
qol: The "Malicious Software Detected" button has been appropriately
renamed to "Reset Software" for when pAIs are emagged
qol: Add a new law notification popup and flavor texts when pAI is
emagged
/🆑
## About The Pull Request
Fixes#77285
This code block was written to eject pAIs from things when they were
carrying their card around with them. Now that that isn't true, we
shouldn't be doing it.
## Why It's Good For The Game
Reduces ability to accidentally leave your friend on the floor.
## Changelog
🆑
fix: Your pAI card won't pop out of your PDA onto the floor alongside
its hologram if it enters hologram form while inside a PDA.
/🆑
## About The Pull Request
Tries to keep pAIs in range of their owner by moving them closer when
the owner moves, rather than jarringly teleporting every time the owner
gets out of range. Does this by calculating the closest path a nearby
tile and forcefully moving you there. Still a bit janky at times but is
better than teleporting directly onto the owner 100% of the time I feel.
Also prevents you from moving out of range, rather than forcefully
teleporting you back.
Increases the default pAI range to the maximum (9 tiles)
## Why It's Good For The Game
New leashing makes being a leashed pAI significantly less jarring and
obvious. Ideally we would also have a visible max range too.
Default pAI range was pretty small in my testing and I think it's not
unreasonable to think a lot of people won't bother changing it. That
they are leashed at all is the important part.
## Changelog
🆑
qol: pAIs now try to stay within range of their owner, and teleport back
only when necessary
qol: Default max pAI range has been changed to the maximum range you can
choose (9 tiles)
/🆑
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
## About The Pull Request
We're starting to get to have enough components that people don't
realise that what they want already exists but doesn't have the name
they expect 🙃
I recently added `track_hierarchical_movement` which is similar enough
to `connect_containers` that it shouldn't independently exist, even if I
like sending a new signal more than the ugly setup pattern for
`connect_loc`.
`trait_loc` is actually older than `give_turf_traits` but
`give_turf_traits` covers more edge cases than `turf_loc` so seems like
the better one to maintain.
HOWEVER `give_turf_traits` held a list of references to atoms in it,
which isn't great in an element. I couldn't think of a way to completely
eliminate the list, but it isn't a list of references any more so it
shouldn't cause any hard deletions.
## Why It's Good For The Game
Having two components which do the same thing but marginally differently
is confusing and going to cause us trouble down the line.
## Changelog
Not player facing
## About The Pull Request
WHAT HAS CHANGED MECHANICALLY
You can now lean up against walls.
https://github.com/tgstation/tgstation/assets/55666666/bf81b7b5-6cab-4fc3-9887-075351511505
To lean against a wall, simply face opposite to it and drag your sprite
onto it.
Doing so makes you non-dense, just like if you were laying down. This
means people can walk through you, but you are still susceptible to
melee and ranged attacks. Leaning up against a wall also mitigates your
FOV loss by 30 degrees, as you can have a better look at your
surrounding when you put more of your surroundings infront of you.
Because it seemed thematic to lean up against the wall while smoking and
then flick a cigarette away, cigarettes will now say they where
"flicked" instead of thrown when you toss them, I also took the time to
add a bit of variation into the throw text.
A few bugs where you could become non dense and then run straight
through people has been patched.
NOT PLAYER FACING
So basically I've implemented a system that keeps effects that manage a
mob's density consistent with eachother.
An example of some of the situations that could occur
Effect A would render a spaceman undense and turn the player dense again
once it was concluded
Effect B would render a spaceman undense and then after a timer revert
the spaceman to whatever state the spaceman was in before effect B
started.
Thus if you enabled effect A and then Effect B, setting your previous
state of denseness to undense, and then concluded effect A, when Effect
B would finish it would put you back into the state of density you were
in when you started. This would render the spaceman permanently undense.
To solve this, the system has been updated so that all instances of
density adjustment to mobs are handled by traits from unique sources
(with the exception undensity gained by laying down due to its
prevalence.) All effects that handle density will no longer step on each
others toes and can now be rain simultaneously without fear.
## Why It's Good For The Game
Leaning is cool. Bugs are bad.
## Changelog
🆑 itseasytosee
add: You can now lean against walls! Simply turn your back to the wall
and clickdrag yourself onto it.
fix: There should no longer be any instances of spacemen being able to
run straight through eachother as if they weren't even there.
spellcheck: Added more variance to item throwing text.
refactor: Mob density has been refactored
/🆑
## About The Pull Request
Adds an arg in huds' screens to add the hud owner in the Initialize,
instead of manually setting it every time we need to.
This is already done in ``New()`` for lobby screens, which I left intact
as lobby screens are used for new players, and are given out before
atoms are Initialized. Everything else, however, uses Initialize, so it
does not mess with any other args in their own Initializes (like the
Escape menu).
This also allows us to set the screens' HUDs as a private var, to ensure
this won't be messed with in the future.
Lastly I replaced instances of ``client`` with ``cannon_client`` to be
consistent with a lot of other parts of hud code.
## Why It's Good For The Game
Huds are easy to break when they do not have a hud owner, and for
something as important as that I believe it should be something you
opt-out of when you don't want it, rather than something you opt-into by
manually setting hud owner every time.
This cuts down on a lot of copy paste in hud code for humans, aliens,
etc.
## Changelog
🆑
refactor: Huds now have their hud owner set in Initialize
/🆑
## About The Pull Request
New malf AI upgrade
Remote safety overrides: Mid-cost, Mid-supply. Allows the AI to remotely
emag things it can see and can access.
1. Very useful for psychological warfare (Emagging APCs to throw the
crew off their trail)
2. Logically makes sense - why, of all things, can the AI not emag
anything when it's fundumentally integrated with the station's
electronics?
3. Generally speaking can only access things that make sense for it to
access - it cannot emag ethereals, sadly
In order for this to work, emag_act now returns a boolean, designating
if the emag had any effect.
While I was in there, I also added args to every single emag_act I could
find and added far more feedback/converted a lot of things to balloon
alerts to allow the AI to see if its emag had any effect.
## Why It's Good For The Game
It just makes sense that the AI, the most electronically-sensitive
entity in the game, would be able to emag things. Plus, more options
given to malf that aren't strictly MURDER KILL MURDER are always a plus,
especially if they allow for fancier plays.
## Changelog
🆑
add: New malf ability: Remote safety overrides. Allows the AI to
remotely emag things it has access to.
code: emag_act() now returns a boolean designating it's success in
emagging
code: All instances of emag_act() now have the proper arguments
qol: Most usecases of emagging now have some kind of feedback, and
existing feedback has been sanity checked and converted to balloon
alerts.
/🆑
## About The Pull Request
This change restricts PAI holograms to an area around their assigned PAI
card. If you leave this area, you are teleported back to the card's
location (but not automatically put back into the card).
https://www.youtube.com/watch?v=L2ThEVa4nx8
This setting can be configured from the PAI menu, it's set pretty short
in the video because otherwise it wouldn't teleport when I threw the
card and I like doing that.
To accomodate this I set up a component to deal with a reasonably common
problem I have had, "what if I want to track the movement of something
in a box in a bag in someone's inventory". Please tell me if the
solution I came up with is stupid and we already have a better one that
I forgot about.
Also now you can put pAIs inside bots again, by popular request.
## Why It's Good For The Game
Personal AIs are intended to be personal assistants to their owner.
rather than fully independent entities which can pick up their own card
and leave as soon as they spawn.
As "aimless wanderer" players can now possess station bots, pAIs can be
limited to an area around the bearer of their card.
Because the holoform now doesn't contain the card, this also means that
a PAI cannot run off and then be impossible to retrieve. You are always
in control of where it can go.
Also it's funny to throw the card and watch the chicken get teleported
to it.
## Changelog
🆑
add: Personal AI holograms are now limited to an area around their PAI
card. The size of this are can be configured via the PAI card.
add: pAI cards can now be placed inside bots in order to grant them
control of the bot.
/🆑
## About The Pull Request
This PR refactors mind language holders into non-existence
As a result, `update_atom_languages` is no longer necessary
Mind-bound languages are transferred via `/mind/proc/transfer_to`
Species changing no longer deletes and re-creates the mob's language
holder, allowing them to keep any languages they have.
Species languages are sourced from `LANGUAGE_SPECIES` now, meaning they
are removed when they change species. If the mob is not a human with a
species datum, these are effectively just atom level languages.
Makes a bunch of unit tests to ensure language transfer over certain
events works as intended
## Why It's Good For The Game
Mobs with minds having two independent language holders results in a
good few bugs, and simply doesn't make sense when we have sources
(`LANGUAGE_MIND`).
Instead of tracking two language holders, we can simply use sources
better and only track one.
This means that the language holder you start with is your language
holder, period. It doesn't get deleted or re-instantiated or whatever.
## Changelog
🆑 Melbert
refactor: Refactored language holders, making species changes not delete
all of your known languages
/🆑
## About The Pull Request
Before:
<img src="https://i.ibb.co/MSXky10/PAISuicide-Before.png"
alt="PAISuicide-Before" border="0">
After:
<img src="https://i.ibb.co/HhN4kp7/PAISuicide-After.png"
alt="PAISuicide-After" border="0">
Exclamation mark means new sentence which needs a capital letter. This
changes the pronoun helper in the 2nd sentence to be capitalised.
## Why It's Good For The Game
Minor grammar issues getting fixed is good.
## Changelog
Too small a change for a CL entry
basically ex_act's implementation on basic mobs would call parent and
then react to it's value, this is presumably to do the first check about
space vine mutations and whatever. the problem is that the `/mob/living`
implementation would itself also call parent, and that would always
return null because `/atom/proc/ex_act` doesn't have a set return value.
So, this simply would _always_ early return, with ex_act presumably
*never* working on basic mobs for at least four months now.
I decided to then change up the return values for pretty much all
implementations of `ex_act()` since there was no rhyme or reason to
returning null/FALSE/TRUE, and documenting why it's like that.
Just to make sure I wasn't breaking anything doing this (at least on
base implementations), I wrote a unit test for all of the three major
physical types in game (objs, mobs, turfs) because i am a paranoid
fuckar. we should be good to go now though.
## Why It's Good For The Game
i noticed this because placing c4's on sargeant araneus wouldn't
actually damage it whatsoever. now it actually does the stated 30
damage, but araneus has like 250 health so it doesn't actually matter in
the long run. whatever at least it does the damn 30 now.
also adds a unit test for this specific case as well as a range of other
cases to ensure this stuff doesn't silently break in this way anymore
## About The Pull Request
Corrects `record_feedback()`'s copy/paste comment.
## Pointless history
Originally being added in e2a8a5e, it kept its name and args for quite a
few years, that was until #32188 which had it renamed to
`record_feedback` and its args pretty much doubled. In between these
times the known copy/paste comment was already around, but that wasn't
updated, until now apparently.
This tracks the seconds per tick of a subsystem, however note that it is
not completely accurate, as subsystems can be delayed, however it's
useful to have this number as a multiplier or ratio, so that if in
future someone changes the subsystem wait time code correctly adjusts
how fast it applies effects
regexes used
git grep --files-with-matches --name-only 'DT_PROB' | xargs -l sed -i
's/DT_PROB/SPT_PROB/g'
git grep --files-with-matches --name-only 'delta_time' | xargs -l sed -i
's/delta_time/seconds_per_tick/g'
The check queue is 5 minutes long because that's the longest a client
can hold onto a reference. Without clients, we can drastically decrease
the time we have to wait. This lowers the time down to 10 seconds
(though everything right now deletes in 5).
This will represent a 5 minute decrease in CI across the board, freeing
up runners.
Makes a few changes to stuff that was being held for more than 10
seconds.
- `VARSET_CALLBACK` now works through weakrefs, to allow for pAIs to
have their holochassis init timers.
- Nar'Sie cleans herself up in GLOB.cult_narsie if she's deleted.
- "Spooky portals" no longer hold onto a reference for 2 minutes.
- `poll_candidates` short circuits to an empty list if there are no
candidates, to avoid several 30 second+ long timers
Originally this was going to be a more clever hack from @MrStonedOne
about short circuiting if everything deletes before the wait, but we
realized that basically nothing actually holds onto references for that
long without clients, and that nothing really should anyway
On the tin, doing it like this means we can reduce our overall line
fingerprint whenever we have to add two or more traits from the same
source on the same target. Especially helps when we get to the 4+ range
of traits, a breath of fresh air even.
Doesn't mean we have to do for loops, as that's already handled within
the define as well. I replaced some of the checks with `length()`
checks, let me know if I should switch it over to something else (maybe
`islist()`)? We stack_trace whenever we're not passed a list reference
on purpose, and sometimes var/lists are null by default (or just empty,
making this redundant).
## Why It's Good For The Game
I commonly feel the urge to write "use `AddTraits()`" or something in
reviews, then am sad when I remember it doesn't exist. I will no longer
be sad.
Can ensure a lot more trait safety as well by using static lists- when
both ADD_TRAIT_LIST and REMOVE_TRAIT_LIST re-use the same list, you are
confident (from a static point of view) that everything that you want to
be adding/removing works.
I may have missed a few things where this could be used, but both macros
implemented in this PR still use the same framework that was being used
in the last four years- so stuff won't break if left untouched. Just a
nifty new tool for developers.
also fixed up some code in the area, numerous bugs were found and
exploded
This builds on what #69790 did and improved the code even further.
Notable things:
- `Topic()` is a deprecated proc in our codebase (replaced with
Javascript tgui) so it makes sense to rename `canUseTopic` to
`can_perform_action` which is more straightforward in what it does.
- Positional and named arguments have been converted into a easier to
use `action_bitflag`
- The bitflags adds some new checks you can use like: `NEED_GRAVITY |
NEED_LITERACY | NEED_LIGHT` when you want to perform an action.
- Redundant, duplicate, or dead code has been removed.
- Fixes several runtimes where `canUseTopic` was being called without a
proper target (IV drips, gibber, food processor)
- Better documentation for the proc and bitflags with examples
## About The Pull Request
We track the pai aswell as the cable to check for the pai moving away
from the user
But we never clear that tracking
Also adds a check for the check proc to not run if there isn't even a
hacking cable
## Why It's Good For The Game
resolves#73222
## Changelog
🆑
fix: Using a hacking cable will no longer permanently spam you with
balloon messages
/🆑
🆑 ShizCalev
fix: Fixed some duplicated and incorrect messages being presented when
infected with a virus that has the spontaneous combustion symptom.
/🆑
## About The Pull Request
Basically all of the heavy lifting was done in #72919, but we do a few
key things here that I wasn't able to do then because it was just
fucking massive.
Player Facing Changes:
* hear_blind arg is now a default state and must be specifically
overridden. Pretty much every mob that wasn't a pAI or alien was lacking
this, so let's toss it in as a default now. Let me know if the generic
message I put in for /mob/living sucks and we can go from there.
Code Side Changes:
* suicide.dm now only contains code pertinent to the suicide verb, and
all subtype proc-overrides have been moved to an appropriate file
pertinent to that subtype.
* suicide.dm has also been organized a bit more to aid the previous
change.
* There is only one suicide verb now, implemented on /mob/living. All
the verb does is invoke the handle_suicide() proc, which does all of the
lifting.
* Leaning into *mumble mumble* object-oriented philosophy, the message
we send to the world on suicide is handled on subtype procs, rather than
be in the huge fuck-off message tree I implemented in the earlier PR. It
definitely makes the visible_message() proc not hard to read IMO. This
also means that we can take up a less footprint when we re-use certain
suicide messages (i.e. Silicon), which is nifty too.
i'm probably forgetting something but that's all of the big ones
## Why It's Good For The Game
There is now a very, very common framework for how suicide works across
all living mobs, and it's much easier to override how suicide is
handled. Certain subtypes do their own bullshit thing, but it's quite
easy to account for this on that case-by-case basis. The overall code
takes up a much less footprint that just makes it look nicer.
## Changelog
🆑
qol: Some mob suicides now have a message that shows to blind people or
people that didn't actually witness the suicide, pretty cool.
/🆑
Adds lints for `balloon_alert(span_xxx(...))` (which is always wrong),
and balloon alert where the first letter is a capital (which is usually
wrong). Fixes everything that failed them. As a reminder, abbreviations
like "AI" and "GPS" shouldn't be capitalized in a balloon alert.
In cases where this is intentional for flavor (there was one case), you
can `UNLINT` like so:
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
## About The Pull Request
Adds `EXPERIMENT_515_QDEL_HARD_REFERENCE`, which will queue to the GC
subsystem using hard references rather than `\ref`. This is only
possible in 515 because of the new `refcount` proc. `\ref` is very very
slow and has some nasty knock on effects, so removing its usages where
possible is good.
This is an explicit opt in define because I want to give us the ability
to test 515 on live while only testing 515 itself, not our experimental
changes. We have a few more of these we want to do so I made a separate
file for them. They're auto-defined in unit tests so we see them with
the alternate test runner. In a perfect world we'd test both on and off,
but eh.
Closes https://github.com/tgstation/dev-cycles-initiative/issues/10
## About The Pull Request
That's right I'm still atomising #71421, some day I might even post
something related to carp.
This PR adds various behaviours to basic mobs allowing them to run away,
in a couple of variations.
Mice will flee from anyone who doesn't share their factions, at all
times (so they will scatter from most humans, but not regal rats).
Rabbits and Sheep will flee from anyone who has attacked them.
Pigs will run away from people who have attacked them, but only if
they're below half health.
https://user-images.githubusercontent.com/7483112/207127135-d1737f91-d3f7-468a-ac60-7c7ae5d6623d.mp4
Mice are still plenty catchable because they don't run _very far_ (or
very fast) but I think the chase will be good enrichment.
To achieve this I had to change the signal COMSIG_CARBON_HEALTH_UPDATE
into COMSIG_LIVING_HEALTH_UPDATE but frankly the latter seems more
sensible anyway.
## Why It's Good For The Game
More behaviours to use later when designing mobs, gradually gives mobs
more things to do rather than just sort of moving aimlessly around the
area you left them in.
It'll give people hunting rats in maintenance some exercise.
## Changelog
🆑
add: Mice will now run away from you, you have to catch them if you want
to eat them. Use those traps!
add: Rabbits, Sheep, and Pigs likewise won't just sit there and let you
pulverise them if they can see an escape route.
/🆑
## About The Pull Request
This PR is a continuing refactor of and fixes bugs introduced by my
prior PR #71864
Due to many functions in reagents having been implemented on top of
prior buggy code, their new behaviors are not as expected in-game, and
as a result reagents damage/heal robotic/cybernetic bodyparts/organs
when not appropriate; bugs like healing robotic arms with Libital is
currently possible.
To fix the errant behaviors in the newly debugged code, I have added
three variables to `datum/reagent` which are used throughout reagent
code, mainly inside of `on_mob_life` etc:
- `affected_bodytype = BODYTYPE_ORGANIC` - Used if the reagent
damages/heals bodyparts (Brute/Fire) of an affected mob.
- `affected_biotype = MOB_ORGANIC` - Used if the reagent damages/heals
generic damage (Toxin/Oxygen) of an affected mob.
- `affected_organtype = ORGAN_ORGANIC` - Used if the reagent
damages/heals organ damage of an affected mob.
The diff is large, and I have refactored the readability/maintainability
around the sections of code I was modifying. At one point I chose to
perform a quality pass on reagents because I found it quite hard to
maintain reagents code in its current state. This PR also replaces many
single-letter variables with more descriptive and readable variable
names. I also found and fixed a stray tab which was located in the
flavortext of `proc/item_heal_robotic`
## Why It's Good For The Game
Due to an old bug being fixed recently by PR #71864 a lot of
healing/damaging reagents now have an effect on robotic bodyparts. This
PR corrects the issue and changes reagents to explicitly define the body
type, bio type, and organ type which they can affect with
helaing/damage. This PR replaces a lot of single-letter variable names
with more descriptive names. I also fixed a small typo in
`item_heal_robotic` which was inserting an extra tab.
## Changelog
🆑
fix: Fixed a stray-tab typo in "item_heal_robotic"
fix: Fixed reagents and other effects which were inappropriately
affecting robotic limbs.
code: Refactored all of reagents code to be more readable and
maintainable.
/🆑
Co-authored-by: Time-Green <timkoster1@hotmail.com>
# About The Pull Request
Around 4 years ago an overriding proc in carbons, `take_overall_damage`,
dropped a positional argument for stamina, but the calls to it were not
adjusted. This PR fixes a 4 year old bug wherein the `adjustBruteLoss`
and `adjustFireLoss` functions were not working as expected for robotic
bodyparts, and in most cases leads to robotic limbs being invulnerable
to spread damage/healing. The bug also affected the Var Viewer and any
admin-heals. In downstream repositories such as Skyrat-tg, where there
are fully robotic characters, some severe impact was seen such as the
inability to revive/heal players without fully respawning them.
The bug was caused by out-of-order positional arguments in the calls to
`/mob/living/carbon/take_overall_damage` and
`/obj/item/bodypart/proc/receive_damage` within `adjustBruteLoss` and
`adjustFireLoss`, which caused its `updating_health` argument to wind up
in the wrong position, occupying the same position as `required_status`
which is then interpreted by the proc to mean bitflag
`BODYTYPE_ORGANIC`. Furthermore, the default argument for
`required_status` and `heal_overall_damage` is currently also
`BODYTYPE_ORGANIC`, which would cause the issue to persist and prevent
most forms of spread-healing and spread-damage to robotic/surplus limbs.
I also found that, after fixing the bug, robotic limbs were suddenly
vulnerable to space/pressure damage. @Fikou has requested that I re-add
this mechanic, as it is now a feature of the game. To implement it, I
made a small change to `/datum/species/proc/handle_environment_pressure`
so pressure damage only damages organic bodyparts.
I also found that any limbs which do not set a `max_damage` simply do
not show up in the list returned by `get_damageable_bodyparts`, which
could stop them from being damaged/healed, which I think may be
intentional. I didn't think this was a bug, but I can change this too if
it's asked of me.
## Why It's Good For The Game
The PR includes a bugfix which allows non-organic bodyparts to be
damaged by spread damage again. An out-of-order argument to the
ubiquitous `take_overall_damage` and `receive_damage` functions was
causing an argument to shift one position over to the right, and those
functions receive a default `required_status` argument of
`BODYTYPE_ORGANIC`; both issues combined caused the functions to almost
completely ignore non-organic bodyparts, and only deal/heal damage to
organic bodyparts.
The PR should allow more admin-heals to work as expected, and more
sources of damage will now work as expected for non-organic bodyparts.
## Changelog
🆑 A.C.M.O.
fix: Fixed robotic/surplus limbs not taking damage/healing as expected;
including via the Var Viewer, Player Panel, and from sources of
spread-damage.
/🆑
Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com>
## About The Pull Request
This changes stamina damage from a damage that affects limbs (like brute
and burn) to a damage that affects the body at whole (such as tox or
oxy)
Stamina being run like brute or burn is rooted all the way back to when
it was halloss, and used exclusively for holodeck items and
hallucinations.
Most coders probably didn't even know that stamina worked like this, and
most implimentatiosn of stmaina mechanics use a generic "adjust stamina"
or a "apply_damage(type = stamina zone - body_zone_chest)" to avoid the
issues that come when stamina is evenly distributed among limbs (and
some limbs only count as a fraction to stamina damage total)
The only thing that is truly lost here, is disabling limbs (arms and
legs) with stamina damage, by aiming specifically at them with disablers
(batons always apply their stamina damage to the chest, no matter where
they hit) our through smashing limbs on tables.
The idea of making an opponent drop a weapon out of pain is fun, but
stamina doesn't support it, or make sense in context.
A depth filled limb-based pain system that has interactions with
painkillers and replaces damage based move slowdown would be fun, and
maybe something that could be implemented in the future.
## Why It's Good For The Game
The biggest draw here, is that it will make stamina easier to maintain
## Changelog
🆑 itseasytosee
code: Stamina no longer affects individual limbs.
/🆑
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
## About The Pull Request
- Rewrites how action button icons are generated.
- Prior, generated an action button icon was fairly simplistic and
didn't allow for many changes. Someone recently added the option for
overlays to be generated over action buttons, but the framework was very
weak.
- Now, action button icon generation is split across multiple procs,
like atom icon updates.
- The background of action buttons are underlays
- The actual icon of the action button is the icon and icon state of the
action button movable
- The rim / border of the button is an overlay, layered overtop the
button.
- Allows observers to see what action buttons a mob has. They even
update in real time! And no, the observers cannot click on them.
## Why It's Good For The Game
- Runechat text of action buttons are no longer hidden behind the actual
icon. This was very ugly with cooldown actions, as the cooldown text was
hidden behind a lot of spell icons.
- Cuts down on a lot of icon duplication.
- Gives much finer control over action button icons
- Saves a bit of processing from generating full action button icons
when not necessary. Not implemented in many places, but is in some.
## Changelog
🆑 Melbert
add: Observers can now see what action buttons an observed mob has. No,
you can't click them. And no it doesn't show EVERY action.
refactor: Refactored how action button icons are generated. Some actions
will now use a colored border when active instead of just turning green.
Cooldown text will also appear on the top layer of actions too. If you
see any funky lookin' icons (namely their borders), let me know.
refactor: Bluespace Golem's teleport action is now a cooldown action.
fix: Construct actions go to the middle of the screen like expected.
/🆑
## About The Pull Request
A case inconsistency when the pAIs rework was done (#68241) broke the
HUD toggle button used to display the Crew Manifest. While the software
was installed by the pAi, it falsely displayed that it was not the case.
> You must download the required software to use this.
## Why It's Good For The Game
Toggle button didn't work. Now, it works.
## Changelog
🆑
spellcheck: The pAI toggle button to quickly display the Crew Manifest
works again.
/🆑
Makes the code compatible with 515.1594+
Few simple changes and one very painful one.
Let's start with the easy:
* puts call behind `LIBCALL` define, so call_ext is properly used in 515
* Adds `NAMEOF_STATIC(_,X)` macro for nameof in static definitions since
src is now invalid there.
* Fixes tgui and devserver. From 515 onward the tmp3333{procid} cache
directory is not appened to base path in browser controls so we don't
check for it in base js and put the dev server dummy window file in
actual directory not the byond root.
* Renames the few things that had /final/ in typepath to ultimate since
final is a new keyword
And the very painful change:
`.proc/whatever` format is no longer valid, so we're replacing it with
new nameof() function. All this wrapped in three new macros.
`PROC_REF(X)`,`TYPE_PROC_REF(TYPE,X)`,`GLOBAL_PROC_REF(X)`. Global is
not actually necessary but if we get nameof that does not allow globals
it would be nice validation.
This is pretty unwieldy but there's no real alternative.
If you notice anything weird in the commits let me know because majority
was done with regex replace.
@tgstation/commit-access Since the .proc/stuff is pretty big change.
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Splits head dmi into separate files for both mob and obj icons. Kept similar to suit split categorization + some more. New files include beanie, bio, chaplain, costume, cowboy, default, hats(softcaps, fedoras, head caps, generic hats), helmet(helmets and other armored headgear/hoods), spacehelm, utility(hardhats, mostly work related hats), wizard.
Moves animal/pet head sitting icons to 1 folder, pets_head.dmi
Renames PAI head sitting icon file to pai_head.dmi
About The Pull Request
I've reworked multiz. This was done because our current implementation of multiz flattens planes down into just the openspace plane. This breaks any effects we attach to plane masters (including lighting), but it also totally kills the SIDE_MAP map format, which we NEED for wallening (A major 3/4ths resprite of all wall and wall adjacent things, making them more then one tile high. Without sidemap we would be unable to display things both in from of and behind objects on map. Stupid.)
This required MASSIVE changes. Both to all uses of the plane var for reasons I'll discuss later, and to a ton of different systems that interact with rendering.
I'll do my best to keep this compact, but there's only so much I can do. Sorry brother.
Core idea
OK: first thing.
vis_contents as it works now squishes the planes of everything inside it down into the plane of the vis_loc.
This is bad. But how to do better?
It's trivially easy to make copies of our existing plane masters but offset, and relay them to the bottom of the plane above. Not a problem. The issue is how to get the actual atoms on the map to "land" on them properly.
We could use FLOAT_PLANE to offset planes based off how they're being seen, in theory this would allow us to create lens for how objects are viewed.
But that's not a stable thing to do, because properly "landing" a plane on a desired plane master would require taking into account every bit of how it's being seen, would inherently break this effect.
Ok so we need to manually edit planes based off "z layer" (IE: what layer of a z stack are you on).
That's the key conceit of this pr. Implementing the plane cube, and ensuring planes are always offset properly.
Everything else is just gravy.
About the Plane Cube
Each plane master (except ones that opt out) is copied down by some constant value equal to the max absolute change between the first and the last plane.
We do this based off the max z stack size detected by SSmapping. This is also where updates come from, and where all our updating logic will live.
As mentioned, plane masters can choose to opt out of being mirrored down. In this case, anything that interacts with them assuming that they'll be offset will instead just get back the valid plane value. This works for render targets too, since I had to work them into the system as well.
Plane masters can also be temporarily hidden from the client's screen. This is done as an attempt at optimization, and applies to anything used in niche cases, or planes only used if there's a z layer below you.
About Plane Master Groups
BYOND supports having different "maps" on screen at once (IE: groups of items/turfs/etc)
Plane masters cannot cover 2 maps at once, since their location is determined by their screen_loc.
So we need to maintain a mirror of each plane for every map we have open.
This was quite messy, so I've refactored it (and maps too) to be a bit more modular.
Rather then storing a list of plane masters, we store a list of plane master group datums.
Each datum is in charge of the plane masters for its particular map, both creating them, and managing them.
Like I mentioned, I also refactored map views. Adding a new mapview is now as simple as newing a /atom/movable/screen/map_view, calling generate_view with the appropriate map id, setting things you want to display in its vis_contents, and then calling display_to on it, passing in the mob to show ourselves to.
Much better then the hardcoded pattern we used to use. So much duplicated code man.
Oh and plane master controllers, that system we have that allows for applying filters to sets of plane masters? I've made it use lookups on plane master groups now, rather then hanging references to all impacted planes. This makes logic easier, and prevents the need to manage references and update the controllers.
image
In addition, I've added a debug ui for plane masters.
It allows you to view all of your own plane masters and short descriptions of what they do, alongside tools for editing them and their relays.
It ALSO supports editing someone elses plane masters, AND it supports (in a very fragile and incomplete manner) viewing literally through someone else's eyes, including their plane masters. This is very useful, because it means you can debug "hey my X is yorked" issues yourself, on live.
In order to accomplish this I have needed to add setters for an ungodly amount of visual impacting vars. Sight flags, eye, see_invis, see_in_dark, etc.
It also comes with an info dump about the ui, and plane masters/relays in general.
Sort of on that note. I've documented everything I know that's niche/useful about our visual effects and rendering system. My hope is this will serve to bring people up to speed on what can be done more quickly, alongside making my sin here less horrible.
See https://github.com/LemonInTheDark/tgstation/blob/multiz-hell/.github/guides/VISUALS.md.
"Landing" planes
Ok so I've explained the backend, but how do we actually land planes properly?
Most of the time this is really simple. When a plane var is set, we need to provide some spokesperson for the appearance's z level. We can use this to derive their z layer, and thus what offset to use.
This is just a lot of gruntwork, but it's occasionally more complex.
Sometimes we need to cache a list of z layer -> effect, and then use that.
Also a LOT of updating on z move. So much z move shit.
Oh. and in order to make byond darkness work properly, I needed to add SEE_BLACKNESS to all sight flags.
This draws darkness to plane 0, which means I'm able to relay it around and draw it on different z layers as is possible. fun darkness ripple effects incoming someday
I also need to update mob overlays on move.
I do this by realiizing their appearances, mutating their plane, and then readding the overlay in the correct order.
The cost of this is currently 3N. I'm convinced this could be improved, but I've not got to it yet.
It can also occasionally cause overlays to corrupt. This is fixed by laying a protective ward of overlays.Copy in the sand, but that spell makes the compiler confused, so I'll have to bully lummy about fixing it at some point.
Behavior changes
We've had to give up on the already broken gateway "see through" effect. Won't work without managing gateway plane masters or something stupid. Not worth it.
So instead we display the other side as a ui element. It's worse, but not that bad.
Because vis_contents no longer flattens planes (most of the time), some uses of it now have interesting behavior.
The main thing that comes to mind is alert popups that display mobs. They can impact the lighting plane.
I don't really care, but it should be fixable, I think, given elbow grease.
Ah and I've cleaned up layers and plane defines to make them a bit easier to read/reason about, at least I think.
Why It's Good For The Game
<visual candy>
Fixes#65800Fixes#68461
Changelog
cl
refactor: Refactored... well a lot really. Map views, anything to do with planes, multiz, a shit ton of rendering stuff. Basically if you see anything off visually report it
admin: VV a mob, and hit View/Edit Planes in the dropdown to steal their view, and modify it as you like. You can do the same to yourself using the Edit/Debug Planes verb
/cl
Adds a chicken holochassis as one of the selection choices for pAI players. Updated so that merge conflicts should be easier to resolve, as well as match with the current master.
About The Pull Request
Reorganizes the entire icons/mob folder.
Added the following new subfolders:
nonhuman-player (this was initially just called "antag", but then I realized guardians aren't technically antags)
simplemob
silicon
effects (for bloodstains, fire, etc)
simplemob/held-pets (for exactly that -- I wasn't sure if this should go in inhands instead)
species/monkey
Moves the following stuff:
All human parts moved into species, with moth, lizard, monkey, etc parts moved to corresponding subfolders. Previously, there were some moth parts in mob/species/moth, and others just loose in mob. Other species were similar.
icemoon, lavaland, and jungle folders made into subfolders of simplemob
All AI and silicon stuff, as well as Beepsky et al. into the silicon folder, simplemobs into the simplemob folder, aliens into the nonhuman-player folder, etc.
Split up animal_parts.dmi into two bodyparts.dmi which were put in their respective folders (species/alien and species/monkey)
Code changes:
Filepath changes to account for all of this
Adds a check when performing surgery on monkeys and xenos, because we can no longer assume their limbs are in the same file
Turns some hardcoded statues and showcases that were built into maps into objects instead
Things I'd like to do in the future but cant be assed right now:
Remove primarily-antag sprites from simplemob/mob.dmi (Revenant, Morph, etc.) and put them in the nonhuman-player folder
Split up mutant_bodyparts.dmi into different files for Tizirans, Felinids, monkeys, etc and put them in their own folders. Those may have once been meant primarily for mutated humans but that's now how they're being used right now.
About The Pull Request
Deletes /obj/shapeshift_holder, replaces it with /datum/status_effect/shapechange_mob
Refactors Heretic worm form into a shapeshift spell
Refactors Wabbajack, and associated code
Fixes#69117Fixes#65653Fixes#59127Fixes#52786
Why It's Good For The Game
/obj/shapeshift_holder was one of the worst remaining abuses of /obj direct subtypes, so I replaced it with a cool fancy datum.
This also decouples the shapeshifting behavior entirely from the shapeshifting spell. So we have support for shapeshifted mobs not sourced from a spell. Which is neat, we could technically swap Wabbajack to use this in the future.
Changelog
cl Melbert
fix: Wabbajacking a shapeshifted mob no longer runtimes horribly. When a shapeshifted mob is wabbajacked, they'll now be removed from their shapeshift and stunned.
fix: Transforming via a shapeshift should no longer rob you of your hearing / runechat awareness.
fix: Shapeshifting plays nicer with holoparasites.
fix: Being polymorphed from a xeno to a non-xeno correctly makes you a non-xeno
refactor: Refactored shapeshifting, the shapeshift holder is now a status effect instead of an object.
refactor: Heretic worm form is a shapeshift spell now, this might have some minor behavioral changes but should overall be the same.
refactor: Refactored Wabbajack (+ cursed pool). Overall a bit more clean / consistent behavior.
/cl
A pretty heavy refactor for pAIs that just spilled into a rework.
Attempts to fully document and organize backend code.
Fixes a large number of bugs left untouched for a decade.
Breaks down the frontend into subcomponents.
Rebalances their software modules.
(should) fix pAI faces get removed if you activate them during alert #68242
