## About The Pull Request
Melee attack chain now has a list passed along with it,
`attack_modifiers`, which you can stick force modifiers to change the
resulting attack
This is basically a soft implementation of damage packets until a more
definitive pr, but one that only applies to item attack chain, and not
unarmed attacks.
This change was done to facilitate a baton refactor - batons no longer
hack together their own attack chain, and are now integrated straight
into the real attack chain. This refactor itself was done because batons
don't send any attack signals, which has been annoying in the past (for
swing combat).
## Changelog
🆑 Melbert
refactor: Batons have been refactored again. Baton stuns now properly
count as an attack, when before it was a nothing. Report any oddities,
particularly in regards to harmbatonning vs normal batonning.
refactor: The method of adjusting item damage mid-attack has been
refactored - some affected items include the Nullblade and knives.
Report any strange happenings with damage numbers.
refactor: A few objects have been moved to the new interaction chain -
records consoles, mawed crucible, alien weeds and space vines, hedges,
restaurant portals, and some mobs - to name a few.
fix: Spears only deal bonus damage against secure lockers, not all
closet types (including crates)
/🆑
## About The Pull Request
People can now pet held mothroaches and pugs if they want to, or use
items on them, hopefully without causing many issues. After all, it only
took about a couple dozen lines of code to make...
...Oh, did the 527 files changed or the 850~ lines added/removed perhaps
catch your eye? Made you wonder if I accidentally pushed the wrong
branch? or skewed something up big time? Well, nuh uh. I just happen to
be fed up with the melee attack chain still using stringized params
instead of an array/list. It was frankly revolting to see how I'd have
had to otherwise call `list2params` for what I'm trying to accomplish
here, and make this PR another tessera to the immense stupidity of our
attack chain procs calling `params2list` over and over and over instead
of just using that one call instance from `ClickOn` as an argument. It's
2025, honey, wake up!
I also tried to replace some of those single letter vars/args but there
are just way too many of them.
## Why It's Good For The Game
Improving old code. And I want to be able to pet mobroaches while
holding them too.
## Changelog
🆑
qol: You can now interact with held mobs in more ways beside wearing
them.
/🆑
## About The Pull Request
Fixes#85980
- Pixel adjustments are now sourced
When tweaking a mob's pixel w, x, y, z, is is now done via `add_offsets`
and must have a source string associated
- Refactors riding
Refactors how riding component selects the offsets to use. It's now all
done via the getter rather than a weird mix of a var, a cache, and a
getter.
- Moves a bunch of animations to use `pixel_w` / `pixel_z`
Largely to prevent conflicts with adjustments to a mob's pixel position,
but also as many animations are not actual movements, but visual
movements. Floating is one such example.
## Why It's Good For The Game
It just works
## Changelog
🆑 Melbert
fix: Fixed grab offsets not showing for anything but passive grab
fix: Fix jank with mob offsets when riding things
refactor: Refactored riding component, particularly how it selects layer
and offsets. Report any oddities
refactor: Refactored pixel offsets of mobs. Report any oddities
/🆑
## About The Pull Request
Lighters now have welding fuel which can be filled/extracted by hand,
giving a small but consistent source of welding fuel for non-chemists.
Welding fuel is now required for these lighters to work, they'll close
automatically once they're out of fuel.
They last for a minute, zippo lasts 2 minutes, before they need to be
refuelled. It can have other reagents put into it but it only checks for
welding fuel, so it won't work at all unless its got some.
They can be used as welding tools in minor cases, mostly fixing things
and welding doors shut, but can't do big things like deconstruction,
except the xenobio one because it's a lot hotter than the normal
lighter.
Also added a baseline support to check for heat to perform certain
welds, before heat is just this binary "has or doesnt have heat", which
made its value useless.
## Why It's Good For The Game
Adds a ghetto way of getting welding fuel, hiding reagents, and a ghetto
welding tool without being something that prisoners could break out of
prison with. They could weld the doors shut which is a little funny,
security still has proper welding tools to counter it.
It also currently is kinda lame that lighters could just be open 24/7,
unlike matches which has a lifespan of 10 seconds each or something.
## Changelog
🆑
add: Lighters now use and require welding fuel to work, but can be used
as a welding tool for tasks that don't require much heat.
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
Issue brought some missed hidden actions to my attention.
I left cogbars in for _breaking_ handcuffs because resisting is sort of
a gray area. On one hand, you don't want someone to see you doing it; on
the other, there is a visible warning that you started doing it. So,
meet in the the middle, breaking handcuffs is still visible while
resisting isn't.
## Why It's Good For The Game
Closes#82583
Cogbars are not intended to ruin stealth
## Changelog
🆑
fix: Deviants buffed: Rogue shoelacing, pickpocketing and restraint
resisting no longer give cogbar icons.
/🆑
## About The Pull Request
When it comes to deconstructing an object we have `proc/deconstruct()` &
`NO_DECONSTRUCT`
Lets talk about the flag first.
**Problems with `NO_DECONSTRUCTION`**
I know what the comment says on what it should do
b5593bc693/code/__DEFINES/obj_flags.dm (L18)
But everywhere people have decided to give their own meaning/definition
to this flag. Here are some examples on how this flag is used
**1. Make the object just disappear(not drop anything) when
deconstructed**
This is by far the largest use case everywhere. If an object is
deconstructed(either via tools or smashed apart) then if it has this
flag it should not drop any of its contents but just disappear. You have
seen this code pattern used everywhere
b5593bc693/code/game/machinery/constructable_frame.dm (L26-L31)
This behaviour is then leveraged by 2 important components.
When an object is frozen, if it is deconstructed it should just
disappear without leaving any traces behind
b5593bc693/code/datums/elements/frozen.dm (L66-L67)
By hologram objects. Obviously if you destroy an hologram nothing real
should drop out
b5593bc693/code/modules/holodeck/computer.dm (L301-L304)
And there are other use cases as well but we won't go into them as they
aren't as significant as these.
**2. To stop an object from being wrenched ??**
Yeah this one is weird. Like why? I understand in some instances (chair,
table, rack etc) a wrench can be used to deconstruct a object so using
the flag there to stop it from happening makes sense but why can't we
even anchor an object just because of this flag?
b5593bc693/code/game/objects/objs.dm (L368-L369)
This is one of those instances where somebody just decided this
behaviour for their own convenience just like the above example with no
explanation as to why
**3. To stop using tools to deconstruct the object**
This was the original intent of the flag but it is enforced in few
places far & between. One example is when deconstructing the a machine
via crowbar.
b5593bc693/code/game/machinery/_machinery.dm (L811)
But machines are a special dual use case for this flag. Because if you
look at its deconstruct proc the flag also prevents the machine from
spawning a frame.
b5593bc693/code/game/machinery/_machinery.dm (L820-L822)
How can 1 flag serve 2 purposes within the same type?
**4. Simply forget to check for this flag altogether**
Yup if you find this flag not doing its job for some objects don't be
surprised. People & sometimes even maintainers just forget that it even
exists
b5593bc693/code/game/objects/items/piggy_bank.dm (L66-L67)
**Solution**
These are the main examples i found. As you can see the same flag can
perform 2 different functions within the same type and do something else
in a different object & in some instances don't even work cause people
just forget, etc.
In order to bring consistency to this flag we need to move it to the
atom level where it means the same thing everywhere. Where in the atom
you may ask? .Well, I'll just post what MrMelbert said in
https://github.com/tgstation/tgstation/pull/81656#discussion_r1503086862
> ...Ideally the .deconstruct call would handle NO_DECONSTRUCTION
handling as it wants,
Yup that's the ideal case now. This flag is checked directly in
`deconstruct()`. Now like i said we want to give a universal definition
to this flag and as you have seen from my examples it is used in 3 cases
1) Make an object disappear(doesn't dropping anything) when
deconstructed
2) Stop it from being wrenched
3) Stop it from being deconstructed via tools
We can't enforce points 2 & 3 inside `deconstruct()` which leaves us
with only case 1) i.e. make the object disappear. And that's what i have
done. Therefore after more than a decade or since this flag got
introduced `NO_DECONSTRUCT` now has a new definition as of 2024
_"Make an object disappear(don't dropping anything) when deconstructed
either via tools or forcefully smashed apart"_
Now i very well understand this will open up bugs in places where cases
2 & 3 are required but its worth it. In fact they could even be qol
changes for all we know so who knows it might even benefit us but for
now we need to give a universal definition to this flag to bring some
consistency & that's what this PR does.
**Problem with deconstruct()**
This proc actually sends out a signal which is currently used by the
material container but could be used by other objects later on.
3e84c3e6da/code/game/objects/obj_defense.dm (L160)
So objects that override this proc should call its parent. Sadly that
isn't the case in many instances like such
3e84c3e6da/code/game/machinery/deployable.dm (L20-L23)
Instead of `return ..()` which would delete the object & send the signal
it deletes the object directly thus the signal never gets sent.
**Solution**
Make this proc non overridable. For objects to add their own custom
deconstruction behaviour a new proc has been introduced
`atom_deconstruct()` Subtypes should now override this proc to handle
object deconstruction.
If objects have certain important stuff inside them (like mobs in
machines for example) they want to drop by handling `NO_DECONSTRUCT`
flag in a more carefully customized way they can do this by overriding
`handle_deconstruct()` which by default delegates to
`atom_deconstruct()` if the `NO_DECONSTRUCT` flag is absent. This proc
will allow you to handle the flag in a more customized way if you ever
need to.
## Why It's Good For The Game
1) I'm goanna post the full comment from MrMelbert
https://github.com/tgstation/tgstation/pull/81656#discussion_r1503086862
> ...Ideally the .deconstruct call would handle NO_DECONSTRUCTION
handling as it wants, but there's a shocking lack of consistency around
NO_DECONSTRUCTION, where some objects treat it as "allow deconstruction,
but make it drop no parts" and others simply "disallow deconstruction at
all"
This PR now makes `NO_DECONSTRUCTION` handled by `deconstruct()` & gives
this flag the consistency it deserves. Not to mention as shown in case 4
there are objects that simply forgot to check for this flag. Now it
applies for those missing instances as well.
2) No more copying pasting the most overused code pattern in this code
base history `if(obj_flags & NO_DECONSTRUCTION)`. Just makes code
cleaner everywhere
3) All objects now send the `COMSIG_OBJ_DECONSTRUCT` signal on object
deconstruction which is now available for use should you need it
## Changelog
🆑
refactor: refactors how objects are deconstructed in relation to the
`NO_DECONSTRUCTION` flag. Certain objects & machinery may display
different tool interactions & behaviours when destroyed/deconstructed.
Report these changes if you feel like they are bugs
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
Fixes#79764
I was going to tackle this issue by slamming `TRAIT_NO_SLIP_ALL` on
Atrocinator users and calling it a day, but like, that didn't feel
proper.
So I thought hey, we could just give them the flying movetype, even
though they technically aren't flying it means they're unaffected by
things that flying would make you unaffected by.
Nope, this means the mob technically "negates gravity", so no falling
and no feetsteps.
Let's try floating - this give us feetsteps but no falling upwards.
So instead of going back to square one, with `TRAIT_NO_SLIP_ALL`, I
decided to go for the more complex route of just adding a movetype.
Hence, move type `UPSIDE_DOWN`. This covers situations where a mob would
be "floating" above the ground, but still walking. ...Negative gravity.
This means overall the Atrociator acts more as you'd expect - you don't
slip on ice, you don't trigger bear traps or mouse traps, you can walk
over railings, unaffected by conveyor belts, etc.
## Why It's Good For The Game
Makes the Atrocinator a lot more consistent with how you'd expect for it
to work.
Admittedly it is a bit niche use of movetypes, but it can possibly be
expanded to more things in the future, who knows? I applied it to mobs
on meat spikes (even though they don't move), just for proof of concept.
## Changelog
🆑 Melbert
fix: Atrocinating mobs will now behave more as you'd expect. Meaning
they don't slip on wet patches, can't trigger bear traps / landmines /
mouse traps, ignore conveyors, and can walk over tables and railings.
fix: Floating mobs are unaffected by conveyor belts, acid (on the
ground), glass tables
fix: Floating mobs won't squish stuff like roaches anymore
fix: Fixes bear traps triggering on floating / flying mobs
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
Further continous organizing and cleaning the Icons folder. There are
still some minior nitpicks left to do, but I reached my daily sanity
expenses limit again, and the faster these get in the less issues for
both me and others later. Also cleans some mess I caused by my blindness
last PR.
## Why It's Good For The Game
Saner spriters = better sprites
## About The Pull Request
`held_item` does not always exist, hovering over spikes with empty hands
caused a runtime error
## Changelog
🆑 Melbert
fix: Fixed a runtime from hovering over a meat spike / kitchen spike
with an empty hand
/🆑
## About The Pull Request
- Examining a meat spike frame will tell how you can either deconstruct
it with an welding tool or add spikes to it with iron rods
- Examining a meat spike will tell you how to remove its spikes and how
to basically use it
- A balloon alert will pop up if you don't have enough iron rods to add
spikes to a meat spike frame
- Screen tips when holding the correct tool are displayed
## Why It's Good For The Game
New players don't have to wiki this and honestly i got confused the
first time i used it so there is that. More information basically
## Changelog
🆑
qol: examining a meat spike frame & meat spike will tell you about
itself
/🆑
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
This is a remake of #70242
Replaces all instances of ``do_mob`` and ``do_after_mob`` with
``do_after``.
## Why It's Good For The Game
All 3 of these are just copy pastes of eachother but some miss some
features (like do_after not checking for target loc change, which helps
towards fixing https://github.com/tgstation/tgstation/issues/66874
though it doesn't because mechs are setting ``do_after`` on the mob in
the mech) and signals only being used on ``do_after``.
## Changelog
🆑
fix: Mechs should now cancel out of drilling when they move.
/🆑
So i left over some basic `/whatever/proc/format` uses in the original
PR this fixes it.
Notable exceptions to the rule:
- Paths in add_verb/remove_verb, we need full path instead of a name
there to access verb metadata so we can't use proc ref macros there.
- regex.Replace, found out that it does not accept call by name. Instead
i added new REGEX_REPLACE_HANDLER so we can at least try to mark these.
There's still leftover global procs that do not use GLOBAL_PROC_REF but
they functionally equivalent so that's for later.
I don't see any reasonable way to grep for this. But if you got any
ideas please share.
* improves meatspike code, makes it use default buckle
* small edit to make checks run again
trying to see if somehow this is my fault?? i doubt it.
* lets simpleanimals get buckled again
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)
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
Fixed a bug where royal aliens would have their base pixel offset applied twice, making them off-center (https://i.imgur.com/BtspaM0.png)
Changed the mob/living procs get_standard_pixel_x_offset() and get_standard_pixel_y_offset() to variables (body_position_pixel_x_offset and body_position_pixel_y_offset), to match the contribution guidelines.
Also corrected a few random things that weren't using base pixels but should have been.
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.
* Reverts italics-span back to no color.
* Cleans up many extra spaces and indents.
* Adds 'hear' span class.
* Replaces all 'italics' used in heard messages with 'hear'.
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.
Aiming to implement the framework oranges has detailed in https://tgstation13.org/phpBB/viewtopic.php?f=10&t=19102
Moves canmove to a bitflag in a new variable called mobility_flags, that will allow finer grain control of what someone can do codewise, for example, letting them move but not stand up, or stand up but not move.
Adds Immobilize()d status effect that freezes movement but does not prevent anything else.
Adds Paralyze()d which is oldstun "You can't do anything at all and knock down).
Stun() will now prevent any item/UI usage and movement (which is similar to before).
Knockdown() will now only knockdown without preventing item usage/movement.
People knocked down will be able to crawl at softcrit-speeds
Refactors some /mob variables and procs to /mob/living.
update_canmove() refactored to update_mobility() and will handle mobility_flags instead of the removed canmove
cl
rscadd: Crawling is now possible if you are down but not stunned. Obviously, you will be slower.
/cl
Refactors are done. I'd rather get this merged faster than try to fine tune stuff like slips. The most obvious gameplay effect this pr has will be crawling, and I believe I made tiny tweaks but I can't find it Anything I missed or weird behavior should be reported.
* 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
All uses of "the [src]" have been fixed, as well as other bad string
interpolation directly adjacent to such uses.
In addition to its message, the circumstances under which the tracking
implant locator fails have been updated to use the correct define,
malfunctioning on CentCom rather than on the station.
* Grammar fixes to atom descriptions
- Capitalization and punctuation on most descriptions
- CentCom instead of centcom where appropriate
- Earth instead of earth where appropriate
* Remove spaces before newlines and oneline some strings
This means they're included into the rsc and sent out althogh almost all of these files were already included elsewhere. Also DM will yell if the file couldn't be found for whatever reason like if someone moves or renames it.
I left out some file types for various reasons
dmis used in overlays: I have another pr I'll do later which will fix all of them and I don't want to conflict with myself
text files: they would get included in the rsc, which is completely unnecessary. However they're small, so they might be worth including anyway
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
