## About The Pull Request
Closes#93635
`unique_reskin` is no longer a list on `/item`, now `/datum/atom_skin`
The actual reskinning behavior has been moved out to
`/datum/component/reskinable_item`
PKC reskinning is now handled via alt-click reskin, rather than via the
retooling kit. The retooling kit has been removed.
There's no limit on how many times you can reskin your PKC (though
perhaps we limit it to one reskin and keep the retooling kit as a way to
allow a miner to reskin it a second time?)
The Ashen Skull unique reskin is still a trophy, and instead unlocks its
unique reskin option in the alt-click radial.
## Why It's Good For The Game
I'm unsure why the retooling kit exists on its own, when it's relatively
cheap and just performs the behavior of alt-click reskinning.
So to keep it consistent with all other forms of reskinning I've just
made it baseline. To accomplish that I refactored reskinning.
The new form of reskinning allows for greater potential in adding
reskins, allowing far more than just an icon state change. Also we can
put it on turfs and mobs and structures now which is cool I guess
There's also the added benefit of being able to see an item's reskins
without needing to instantiate it, which the loadout menu uses to great
effect.
## Changelog
🆑 Melbert
refactor: Refactored item reskinning (the alt-click way), report any
oddities with that
del: Deleted the crusher retool kit, now you can just reskin your
crusher with alt-click. The Skull skin is still locked behind having the
Ashen Skull trophy applied.
fix: Stunswords no longer have an incorrect lore blurb
fix: Fixed loadout item reskinning's UI
/🆑
## About The Pull Request
This 1st has to be PR'd so the integration tests can point out all
wallmounts that could not find a support structure to mount on. I then
will do many map edits to align them onto the closest atom
Yes we no longer use wall mount but atom mounted component. All objects
that are mounted on windows/tables & fences now also fall off when
destroyed
It'll probably be a WHILE before I can fix all wall mounts. Long day.
Expect me to misalign many stuff to fix failing CI so make sure to
provide suggestions when possible
Improved wallmount code overall
- Fixes#93793
## Changelog
🆑
fix: fixes all incorrectly maploded wall mounts that aren't actually
hanging on any support structure
fix: objects mounted on tables, windows & fences also fall off now when
destoryed
qol: lights can be mounted on windows
qol: cameras can be mounted on windows
qol: buttons can be mounted on tables
refactor: improved how wall mounts interact with objects as a whole
report bugs on github
/🆑
## About The Pull Request
Should fix https://github.com/tgstation/tgstation/issues/93897
This implements a restock blacklist for SSwardrobe. If an item type is
in the blacklist, then SSwardrobe will never try to restock that item,
instead just deleting them.
## Why It's Good For The Game
Fixes ever-expanding pile of modsuits in nullspace, and lets modsuits
actually be wardrobed properly
## Changelog
🆑
fix: fixes an where modsuits would accumulate in nullspace over the
course of a round
/🆑
## About The Pull Request
title
## Why It's Good For The Game
Envirosuits get damaged easily, 1 shredded limb means whole body on
fire.
It is a feedback loop that will result in more damage to the victim and
their gear, life-supporting & the suit itself included.
It is hard to notice by others & needs to be held/worn for fixing.
<img width="127" height="78" alt="image"
src="https://github.com/user-attachments/assets/6645a6c8-27aa-48f2-a1e4-1696b1359f01"
/>
## Changelog
🆑
balance: Plasmamen not catching in fire anymore from the slightest wind
blow on their envirosuits.
/🆑
## About The Pull Request
These object flags were not appearing in the code IDE due to not having
the appropriate code comment markers which is a triple slash `///`
instead of the double slash `//`. Although I'm not sure why some had the
`//!` but I'm going to standardize them all. Also added a missing one
for `EMAGGED`.
## Why It's Good For The Game
Better code clarity and formatting.
## Changelog
🆑
code: Add correct code documentation for object flags
/🆑
## About The Pull Request
If you have an outfit with a modsuit control, and are equipping it to a
dummy for previews, when you unequip it SSwardrobe tries to delete the
individual parts when stashing the mod control since they are in the
suit's `contents`.
The control is then stashed, and the parts all cause hard deletes after
a while since the suit itself is still holding a ref to all of them.
Since there is currently no good fast way of checking all the modsuit
parts outside of a nest of istypes I added an item flag for it.
## Why It's Good For The Game
Fixes an oversight, should not have any performance impact.
## Changelog
🆑
fix: fixes an oversight where the wardrobe system tries to delete
modsuit parts when stashing the modsuit
/🆑
## About The Pull Request
Reworks Sleeping Carp significantly.
### Returning Moves: Stomach Knee and Wrist Wrench
Stomach Knee, much like the previous incarnation, causes the victim to
be winded and stunned, though this version only briefly stuns the
victim. It also deals stamina damage and silences the victim for five
seconds. It is performed by a Grab Punch combo. Named Kraken Wrack.
Wrist Wrench, much like the previous incarnation, disarms the victim of
their held items. It also potentially dislocates or breaks their arm, as
it rolls with a very high wound chance. It is performed by a Harm Grab
combo. Stole Gnashing Teeth's name.
### Gnashing Teeth (as it was) is gone
This move didn't do very much at all other than being a harmful punch
with more damage. Throwing a bunch of normal punches won't result in
anything now.
### Harm Punches are no longer have special overrides, but Sleeping Carp
does grant perfect accuracy.
Rather than use a bespoke override, Sleeping Carp now merely uses your
normal unarmed punch for its standard normal punch. However, rather than
leave things to chance, Sleeping Carp grants you perfect accuracy with
those standard punches.
### Grabs are treated as one stage higher
Now that martial arts can directly interact with grab state, as well as
some prior changes to how effective compared to actual grab state is
determined, I've reintroduced Sleeping Carp's stickier grabbing by
making it so that they elevate the effective grab state by one stage.
This is not instant aggro-grabbing like they used to have. This just
makes it so that if they try to resist out of a passive grab, they may
fail as though it was an aggressive grab, but it won't stun them until
it is elevated to a proper aggressive grab.
### What you wear is important for determining the effectiveness of your
Attack Dodging (and attack dodging is broader)
Sleeping Carp's projectile dodging and now attack dodging is based on
whether or not you're 'on theme'. That is, if you are wearing nautical
themed clothing and other factors.
At a baseline, Sleeping Carp has perfect projectile dodging and no
melee/unarmed avoidance.
To improve your chances, you need to;
- Wear martial arts or carp themed clothing on your head. (20% if one is
present, but it only counts one)
- Wear martial arts or carp themed clothing on your chest (20% if one is
present, but only counts one)
- Wear appropriate footwear, like sandals. (20%)
- Be a literal carp. (75% flat)
- Mutate yourself into a carp person. (20%)
However, your chances of avoidance diminishes if:
- You wear armored clothing on your head and chest. (based on Melee
armor)
- While lying on the floor (30%)
Holding objects diminishes your chances as well, This is based on the
weight of the object, and whether or not the object is wielded. Normal
sized objects, for instance, are -30%, and would be -60% if wielded.
It will not diminish your chances if:
- The object is Small or smaller.
- The object is an abstract object or hand grafted object and it doesn't
have block chance.
- The object is in the exceptions list.
- **The exception list is as follows:**
- Nunchaku (this is spies exclusive)
- Bo Staff (the unobtainable one)
- Monk's Staff (the chaplain's null rod)
- Bamboo staff
- Cane (like, walking cane)
- Knives
- Bolas
- Toolboxes
- Spears
- Shortswords (the ones from the medieval pirates)
- Nullblade (it's a shortsword)
- Extendohands (because lol)
- Mops
- Push Brooms
- Baseball Bats
- Claw Hammers
- Carp plushies.
<details>
<summary>A list of appropriate clothing</summary>
Headwear
- Strange Bandana (which come in the kit)
- Maid headband
- Fancy Hairpin
- Carp Mask
- Carp-skinned Fedora
- Carp Costume Hood (this comes with the costume)
- Carp Costume Spacesuit Helmet (as above)
Chestwear
- Martial Gi (which come in the kit)
- Carpskin Suit
- Carp Costume
- Carp Spacesuit
- Maid Outfit
- Kimono
- Yakuta
- Trenchcoats
- Geisha Outfit
- [Swag Outfit](https://www.youtube.com/watch?v=l6DmoPlq3S4)
- Eastern Monk's Outfit (the chaplain outfit)
- Buttoned down line of clothes
- Blazer jacket
- Lawyer jackets
Footwear
- Sandals (which come in the kit)
- Swag Shoes
- Laceup Shoes
</details>
As an example of being OFF theme, being in a full security outfit would
reduce your avoidance chance by a whopping 80%.
You avoid attacks while in combat mode, much like projectile deflection
does on live. You can only get up to a 75% chance melee/unarmed
avoidance.
## Why It's Good For The Game
> Returning Moves
People quite liked some of the older moves, and there weren't as many
dials around at the time to make them particularly more interesting when
I first removed them. We were aiming for an out and out stun removal as
a whole codebase, but largely we're ended up still being comfortable
with minor stuns here and there. Stomach Knee can be one of them.
Wrist Wrench was something I realized I could reintroduce with literal
limb breaking thanks to wound changes. Arm dislocations/breakages are
surprisingly rare as a wound type, and since it is an attack on a
specific arm, not quite as good for bringing someone to death, but quite
good for leaving someone with a maiming wound they now need to fix to
keep pursuing you. Highly useful for those stubborn stun immune targets,
who Sleeping Carp struggles to fight. As in, they can't really fight
them.
> Grab Stage
A bit of my work and a bit of Melbert's has resulted in this being a lot
more reasonable to reintroduce as a benefit. The original instant
aggro-grabbing was definitely very oppressive, since it was a
pseudo-hardstun that lead into a hardstun. Now this is a bit softer by
comparison, and surprisingly quite important. I think the loss of good
grabbing ended up filtering a lot of folk somewhat hard.
> Removal of the override
I was really taken with Spider Bite using baseline punches as the
groundwork for the martial art and I wanted to work into that. Not only
does it mean becoming a carp person is actually a great idea beyond the
avoidance mechanic, but also for your actual basic punches improving. It
just in general feels like it opens up possibilities in the game world
to experiment and the design of martial arts in general. We should make
more martial arts work like this.
> Avoidance
My original rework had one glaring flaw that continues to haunt it to
this day. Defense stacking on Sleeping Carp is ridiculous. Layering
defense upon defense makes the one particular immunity it grants,
projectile immunity, all the more oppressive. Hiding behind high block
and high armor makes you a menace.
The end result is that more people utilize Sleeping Carp not for the
martial art part, but for the projectile immunity part, usually using
something else instead like a baton.
This rubs me the wrong way. You would think and hope that the reason
people take the martial art is to be a goofy martial artist in space.
So, I'm implementing an idea I knew I could never pull off in the
framework at the time.
I'm implementing Unarmored Defense, bitch.
(I was totally also not inspired by Payday 2 in any fashion, nope, not
at all)
I like the idea of forcing a choice between the goofy outfit that gives
you bonuses over just getting the biggest armor you can find and
turtling like a motherfucker. And I want people to focus on the martial
arts and benefit from the martial arts when you're specifically unarmed.
Maybe right now some of the restrictions are a little severe, so if
anyone has any opinions, lemme know.
## Changelog
🆑
balance: Completely reworks Sleeping Carp, again.
balance: The return of Stomach Knee (Kraken Wrack) and Wrist Wrench
(Gnashing Teeth). Time is a flat circle.
balance: Sleeping Carp has better grabs (no instant aggro grabs)
balance: Sleeping Carp integrates normal unarmed punch by not overriding
your normal punches.
balance: Sleeping Carp's deflection weakens if you wear armored headwear
and body armor, or while carrying objects. However, by wearing martial
arts (or carp) themed outfits, you can improve your defenses instead,
allowing you to not just dodge bullets, but also incoming melee attacks.
balance: Some objects are exempt, like staff weapons (such as mops or
the monk's staff), short blades (like knives and shortswords), club-like
(baseball bats and toolboxes), or thematic (like extendo hands and carp
plushies)
balance: You can also get these improvements by being a literal carp or
being a carp person.
/🆑
---------
Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com>
Co-authored-by: _0Steven <42909981+00-Steven@users.noreply.github.com>
## About The Pull Request
This is me picking up #93077 but with code changes relative to the two
new flags that Krysonism added in his PR, which unfortunately he never
finished.
## Why It's Good For The Game
Monkeys should be able to ventcrawl even if their left or right arm is
actually a chainsaw or armblade or whatever. See #93077
## Changelog
🆑 Krysonism
balance: prosthetic item limbs are no longer considered equipped items
for some purposes such as ventcrawling.
/🆑
---------
Co-authored-by: Krysonism <robustness13@hotmail.com>
## About The Pull Request
Moves a lot of the unique renaming implementations described in #82664
to the functions given by the `obj_flag` `UNIQUE_RENAME`.
`UNIQUE_RENAME` has been given new properties to account for
non-standard renaming, these being the `RENAME_NO_DESC` flag that
prevents changing the description, the `nameformat()` and `descformat()`
procs that, when modified, allow for applying naming formats(i.e. "Body
Bag - [input]"), as well as other post-renaming handling such as
changing the name of the output plant of a renamed seed, the
`rename_checks()` proc that allows for unique naming prevention(such as
a locked personal closet), and the `rename_reset()` proc to clean up
other possible renamed variables potentially changed in `nameformat()`
and `descformat()`.
This also adds `/datum/element/tool_renaming` to crayons, which will let
them rename anything that has `UNIQUE_RENAME`. I looked through
everything with that flag, and I didn't see anything that I don't think
should be renameable by a crayon(except things that shouldn't be
renamable with pens), so it shouldn't fuck anything up.
## Why It's Good For The Game
moves all of the non-honorable mentions in #82664 to the same renaming
system, and also moves all of the honorable mentions save for:
- plaques, as they only get renamed once and wouldn't benefit from
`UNIQUE_RENAME` imo
- books, because they're far more than just renaming, and are persistent
- paintings, because they're persistent
- photos, because they're not normal renaming and they're persistent
- endoskeletons, because they're done with a multitool in UI
- cardboard IDs, because they're far more than just renaming
Additionally, this fixes:
- Implanter renaming didn't work because a ! was missing
- Clown borg picket sign renaming didn't work because they didn't use
the correct arguments
This'll make it easier to make renameable objects in the future, as
well.
## Changelog
🆑
fix: fixes implanter renaming not working
fix: fixes clownborg picket sign renaming not working
code: brought most unique renaming implementations under UNIQUE_RENAME
/🆑
## About The Pull Request
currently, `/datum/element/weapon_description` is added during every
single item init, even tho it only ever affects examines. i noticed
while looking at tracy traces downstream that it spent a bit much time
adding the weapon description, so why not just lazily initialize it
during examine instead?
direct port of the same thing from
https://github.com/Monkestation/Monkestation2.0/pull/7502
## Why It's Good For The Game
less wasted time during item init
## Changelog
🆑
code: Item weapon description elements are now initialized when first
examined, instead of immediately upon initialization.
/🆑
## About The Pull Request
This PR tweaks how tools with the CRUEL_IMPLEMENT interact with
patients. Essentially, when performing a surgery without anesthetic, it
will give them the same mood debuff that they would suffer if you had
failed a surgery step (fairly long lasting mood debuff that is
removeable with alcohol or a nap).
Also adds experimental surgeries to morbid surgeries, meaning coroners
now do them faster and get a mood bonus for completing them. The
experimental surgery step now also causes a lot of pain when performed
by someone who is morbidly inclined, such as the coroner. This step is
the part where you are interacting with the patient with an open hand
and is contextual to the experimental surgery (thread the patients
veins, ground their nerves, etc). Anesthetic will mitigate this
entirely.
## Why It's Good For The Game
Cruel tools are cruel for a reason, using them on the living is akin to
torture. So they are going to hurt, a lot. And this gives those tools
some added mechanical flavor befitting of a mad doctor. Experimental
surgeries are all quite morbid in general, so its very thematic to add
them to the list of morbid surgeries. And the part where you start
interacting with the body is perhaps the most morbid part of those
surgeries! It also makes sense for that to cause quite a lot of pain,
its a delicate procedure so you really should have the patient under
anesthesia of some kind.
## Changelog
🆑
add:experimental surgeries are now morbid surgeries, and as such
coroners, or anyone else morbidly inclined, get a slight speed boost
when performing them. Coroner's, or anyone morbidly inclined will also
get a mood boost from completing these surgeries.
add:morbid tools now cause a great deal of pain for the patient if used
without anesthesia. The experimental surgery step will now cause a great
deal of pain when performed by someone who is morbidly inclined, such as
the coroner, however this can be avoided with anesthesia.
/🆑
## About The Pull Request
Borg omnitool is now nodrop so you can't drop the internal tool
reference out of the omnitool
## Why It's Good For The Game
You can put them in closets & on conveyer belts because it doesn't check
for ABSTRACT anywhere and ``doUnEquip`` doesn't prevent the dropping of
items that isn't directly in your modules (so you can drop your beakers
n stuff), so instead of fixing this one by one we're just gonna make
them nodrop, they aren't ever in your actual hand anyway.
Fixes https://github.com/tgstation/tgstation/issues/91580
## Changelog
🆑
fix: Borgs can't drop their omnitool's tools on conveyor belts & into
closets.
/🆑
## About The Pull Request
Fixes https://github.com/tgstation/tgstation/issues/87345
This adds a new item trait, `TRAIT_NO_WORN_ICON`, which is exactly what
it says on the tin - the worn overlay for said item will not be added
when the trait is present, so we give it to items hidden by the hood.
I also refactored the `EXAMINE_SKIP` item flag into
`TRAIT_EXAMINE_SKIP`.
## Why It's Good For The Game
stealth thing having an obvious sprite tell is bad. bugfix good.
## Changelog
🆑
fix: Void Cloaks now properly hide blades and such in the suit storage
from the wearer's sprite.
/🆑
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
## About The Pull Request
Facehuggers dont make people fall asleep, instead making them unable if
on (already was in), and muffling speech
Xenomorphs still have decent tools to stun people in melee thats stuff
for another pr
muzzle is now an element and also just makes you talk like
word word word -> mmmmf mmmf mf
COMPLETELY evaporates BLOCKS_SPEECH flag
## Why It's Good For The Game
Being instantly sent to sleep by a facehugger thrown the hunter that
materialized from a vent then getting dragged to their goon cave where
you spend 2 minutes to get gibbed so someone else but you can play antag
is just extremely unfun
This should allow you to survive if youre quick enough after getting
hugged instead of being forced to get gibbed, allowing cooler xenomorph
combat (you could try fistfighting the dude or something idk)
## About The Pull Request
The visor of the welding mask no longer goes down when you enable
internals
## Why It's Good For The Game
You'll no longer go semi-blind when you activate internals while using
this mask
Fixes#83728
## Changelog
🆑 Guestify
fix: The visor of the welding mask no longer goes down when you enable
internals
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
Recently we allowed items held in your hands to catch fire if you catch
fire.
This makes sense but the code had a few oversights, then we reverted it.
This PR reintroduces the feature, but with a few refinements.
The basic feature is simple: If you are on fire then items you are
holding will also catch fire, in the same vein as items you are wearing
on your head or hands.
There are also a few caveats we forgot about the first time we added
this:
- If your gloves cannot catch fire, your held items will not catch fire
(because your hands aren't on fire).
- If you are extinguished, your held items will also be extinguished.
- Stopping, Dropping, and Rolling on top of any items will also
extinguish those items.
As part of this change, after an argument about whether or not this is
an oversight in coding-general, I've made the proc `get_equipped_items`
take a bitflag instead of a series of booleans as an argument and added
a new one for "include held items", so that we need no longer argue
about whether holding something counts as "equipping" it (in all other
parts of the game than this proc, it does). This is what gives the PR
most of its code footprint, don't be scared.
## Why It's Good For The Game
Items you are holding in your hands _should_ catch fire if everything
else on your person is on fire, and taking an item off of your body to
put it in your hands shouldn't protect it from fire, because those
things don't make intuitive sense.
If we want an item to be able to catch fire when worn, then it should do
so.
This might expose some issues where we were improperly setting the
flammability flags on items, but any weapon which will burn in your
hands now would also have burned if you were wearing it on your belt or
back, so making those issues more visible should be a bonus (we'll also
stop them from burning on your back or belt).
If you see someone holding a piece of paper that you really don't want
them to read you can now set them on fire to stop them from reading it,
whereas previously they would deftly hold the very flammable object out
of reach of their flaming body.
## Changelog
🆑
balance: Items held in your hands can catch fire.
balance: Items you are holding won't catch fire if your hands cannot
catch fire.
balance: When you stop being on fire so will items you are holding.
balance: If you roll around on your burning items they will stop being
on fire.
/🆑
## About The Pull Request
This is the final PR for https://hackmd.io/XLt5MoRvRxuhFbwtk4VAUA that
I've been slowly inching towards the past few months.
This removes ``updateDialog``, ``updateUsrDialog``, ``IN_USE``,
``INTERACT_MACHINE_SET_MACHINE``, and everything surrounding it. Also
fixes advanced camera consoles not booting you off when you're moved out
of reach.
We called ``check_eye`` on mob life whenever they had their machine var
set, but their machine var would never be set to anything that actually
used it, which I found to be a little funny but was also probably my
fault.
## Why It's Good For The Game
This is poor and unmaintained code used for HTML UIs that we no longer
need thanks to TGUI, we should get rid of it to encourage the use of
TGUI in the future instead.
## Changelog
🆑
fix: Advanced camera consoles now boots you off when you're moved out of
reach.
/🆑
## About The Pull Request
1. Renames `NO_DECONSTRUCTION` -> `NO_DEBRIS_AFTER_DECONSTRUCTION`. As
the name suggests when the object is deconstructed it won't drop any
items/debris. After my last refactor for this flag it now serves a new
purpose so its name has been changed to match that
2. Fixes objects that are now using `NO_DECONSTRUCTION` incorrectly.
Some of these changes include
- Removing the flag in objects where there are no means to deconstruct
them (e.g. jukebox, hydroponics soil, flora etc)
- Replacing the flags old purpose by overriding its tool procs so that
it regains its old behaviour(e.g. You once again cannot deconstruct ctf
reinforced tables, survival pods, indestructible windows etc)
## Changelog
🆑
code: renamed `NO_DECONSTRUCTION` to `NO_DEBRIS_AFTER_DECONSTRUCTION` so
its name matches its intended purpose
fix: fixes some items that incorrectly used `NO_DECONSTRUCTION` prior to
its refactor, meaning makes some objects non deconstructable again
/🆑
## 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
https://github.com/tgstation/tgstation/blob/b5593bc6930cb60803214869a7b94c84e7baa02c/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
https://github.com/tgstation/tgstation/blob/b5593bc6930cb60803214869a7b94c84e7baa02c/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
https://github.com/tgstation/tgstation/blob/b5593bc6930cb60803214869a7b94c84e7baa02c/code/datums/elements/frozen.dm#L66-L67
By hologram objects. Obviously if you destroy an hologram nothing real
should drop out
https://github.com/tgstation/tgstation/blob/b5593bc6930cb60803214869a7b94c84e7baa02c/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?
https://github.com/tgstation/tgstation/blob/b5593bc6930cb60803214869a7b94c84e7baa02c/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.
https://github.com/tgstation/tgstation/blob/b5593bc6930cb60803214869a7b94c84e7baa02c/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.
https://github.com/tgstation/tgstation/blob/b5593bc6930cb60803214869a7b94c84e7baa02c/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
https://github.com/tgstation/tgstation/blob/b5593bc6930cb60803214869a7b94c84e7baa02c/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.
https://github.com/tgstation/tgstation/blob/3e84c3e6dad33c831ac259f52f2f023680e4899b/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
https://github.com/tgstation/tgstation/blob/3e84c3e6dad33c831ac259f52f2f023680e4899b/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
I wanted to add the ability to shove people with shields by
right-clicking your target, just like how it works barehanded.
This also required a solid refactor of disarm code, effectively bringing
down the core of it to `mob/living` from `mob/living/carbon` or
`mob/living/carbon/human`. This also means you can shove simple mobs
inside closets, bins and on tables.
Xenos and borgs are pretty much immune to regular disarms, but using a
shield will work (borgs and royal xenos are immune to the knockdown).
The riot shield armor has been balanced. It now tanks melee attacks
pretty well, but will break against bullets in just about 2 to 4 hits
depending on the bullet damage. I've always found the lack of sturdiness
of the riot shields for what they're supposed to be good for a bit
detrimental.
Because I've refactored an item flag into a trait, I've had to add a new
MOD module that grants protection from shove knockdown and staggering;
found pre-installed in the administrative MODsuit, but I've also added
it to the black market to make it cooler.
You can bash people with the strobe shield on combat mode.
## Why It's Good For The Game
Currently, shields are simply items that take a held slot in return of
some block chance without being anything special, save for the strobe
shield's integrated flash I guess, but are also a botherance as most
crumple under the duress of less than half a dozen attacks. Meanwhile
swords and other weapons with blok chance just don't care.
TL;DR, I want them a bit more remarkable, and flexible as a tool.
Of course, this ended up in a larger refactor because the right-click /
disarm code was inconsistent.
## Changelog
🆑
add: Shields (and pillows) can be used to shove people around the same
way barehanded right-clicking does. Xenos and borgs can actually be
moved this way.
add: Added a new MODsuit module, the bulwark module, which prevents
knockdown and staggering from shoving, and getting pushed away by thrown
objects. Inbuilt for the safeguard MODsuit, but one might also it in the
black market.
refactor: Disarming has been refactored. You can now shove simple
critters onto tables and into bins and closets
balance: Shields now take their own armor values and the armor
penetration of the attack they blocked when damaged. This means shields
are a bit sturdier now.
balance: Riot shields can tank a lot more damage against melee weapons,
but less against bullets.
qol: strobe shields can now be used to bash people while combat mode is
on.
/🆑
This flag only worked on the `/obj/structure` and `/obj/machinery`
level, so let's rescope it from `flags_1` and put it where it belongs -
`obj_flags`.
Bitflag operators should be scoped to their subtype specific bitfield,
not really useful to have this take up a spot on the `/atom` level if
absolutely nothing other than `/obj`s use it.
## About The Pull Request
Code to handle this flag only ever existed on the `/obj` sublevel, so
there's no need for it to be on the `/atom` level `flags_1`. There was
probably a point in time in which mobs or turfs conducted electricity
but there's zero code for it anymore so we truly just live in a society
now.
## Why It's Good For The Game
Frees up a slot on `flags_1` (which is really nice actually), proper
scoping of certain bitflag stuff, etc.
## Changelog
Not relevant to players.
I may have screwed something up, will be doing a few passes on this
myself to ensure all the search and replaces went alright but we should
be good™️
## About The Pull Request
renames plasmaman helmet exempt flag to stackable helmet exempt. hat
stabilizer now cares about this instead of letting you stack eva helmets
on top of modsuit helmets
improves some code that dripped in quality when i was on break
kinesis has some tweaks
previously it used to stun for a set amount of time - i think this is
because the creator couldnt figure out how to stop movement while being
held? this is changed, now as long as youre holding someone they are
immobilized
you can cancel your kinesis without throwing or moving out of range by
using right click on the click catcher
adds an admin version of kinesis just for the admin suit. it can grab
(almost) ANYTHING and config menu lets you enable phasing, which makes
it so the atom you grabbed phases through everything. pick up that can.
## Why It's Good For The Game
its fun
## Changelog
🆑
balance: hat stabilizer module can now hold what plasmaman helmets can
hold
qol: kinesis module can be stopped without launching an object with
right click
balance: kinesis module stuns last until the kinesis stops
add: admin suit has a version of kinesis that can pick up anything at
any range and can be configured to make grabbed mobs phase through walls
:)
/🆑
## About The Pull Request
As the title says. Adds a bunch more stat changes to various different
items and a somewhat simple way of modifying them whilst minimizing
side-effects as much as possible.
Added a new negative curse of polymorph suffix that can randomly
polymorph you once you pick up the item.
Curse of hunger items won't start on items that are not on a turf.
Curse of polymorph will only activate when equipped.
Bodyparts, two-handed melees, bags, guns and grenades, to name a few,
have a bunch of type-specific stat changes depending on their quality.
Some items won't gain fantasy suffixes during the RPG loot event, like
stacks, chairs and paper, to make gamifying the stats a bit harder.
I'm sure there'll still be other ways to game the event, but it's not
that big of a deal since these are the easiest ways to game it.
High level items also have a cool unusual effect aura
## Why It's Good For The Game
Makes the RPG item event cooler. Right now, it's a bit lame since
everything only gains force value and wound bonus on attack. This makes
the statistic increases more type-based and make it interesting to use
It's okay for some items to be powerful since this is a wizard event and
a very impactful one too. By making the curse of hunger items not spawn
on people, it'll also make it a less painful event too.
## Changelog
🆑
add: Expanded the RPG loot wizard event by giving various different
items their own statistic boost.
/🆑
---------
Co-authored-by: Watermelon914 <3052169-Watermelon914@users.noreply.gitlab.com>
This PR introduces a whole bunch of Coroner and Morbid related content.
Firstly, Morbid is now a mind trait, and specifically, coroners start
with it.
Coroners also have a liver trait that allows them to heal toxins (very
slowly) from eating pickles and drinking pickle juice. They also
can...drink formaldehyde. I guess. Dissections is thirsty work.
Coroners gain a whole set of special tools specifically for use in any
surgeries marked as interests of the Morbid. This is determined by the
``surgery_flag`` called ``SURGERY_MORBID_CURIOSITY``. Currently, these
surgeries are included;
dissections, autospies, revival surgery, plastic surgery, organ/feature
manipulations, amputations
To fit the theme, TRAIT_MORBID also applies the reduction to eye
snatchers.
While using their special tools, and the surgery is a morbid curiosity,
the coroner/anyone who is morbid gains a 30% speed boost! This stacks
with the dissection speed boost. Otherwise, the tools are just regular
tools with a special name (though the scalpel is better at killing
undead, because, you know, you're watching over the dead).
The coroner's special medkit, which is the only one you can get in a
round, can fit their autopsy scanners and tools. Anything that comes
standard with their kit can go back into it.
Anyone who is morbid can safely retrieve the secrets of the elephant
graveyard. The serrated shovel, notably, is a much better tool and
notably better at killing organics, but not inorganics (like the dead).
(Gives roboticists secure morgue access during skeleton crew pop totals)
## About The Pull Request
Fixes#75197
Adds a global list of gun types banned from being added to turrets. Adds
dueling pistols to the banned list as they can freely round remove
people when in turrets without the usual restrictions.
## Why It's Good For The Game
Instakill turrets are an undesirable outcome.
## Changelog
🆑
fix: Dueling pistols can no longer be fitted in turrets to instantly
kill people.
/🆑
## About The Pull Request
https://github.com/tgstation/tgstation/blob/0426f7ddbaa91439c7278189101f5db9c7f2ed95/code/game/objects/items/stacks/stack.dm#L449
Ok, but can we not?
This PR refactors sheet crafting to generalize all the cases that were
previously locked behind grille/window type checks and such. In their
stead there are bitflags that can be set to achieve certain behaviors.
All the behavior from before should be preserved, but now it can be
extended to other items. E.g. if you want a railing that can be crafted
underneath directional windows, or an item that behaves like a grille
does--it's just a matter of setting the right obj_flags for it now.
This makes it very simple and painless to add new recipes that use
directional crafting! It's all modular now.
<details><summary>Details</summary>
---
### What I've done:
-Eliminated all the type checks, instead it will now be handled by
object flags and recipe vars, making for a much more configurable
system.
-Added two new obj_flags: `BLOCKS_CONSTRUCTION_DIR` and
`IGNORE_DENSITY`.
-Additionally, I renamed the existing flag `NO_BUILD` to
`BLOCKS_CONSTRUCTION`.
-Changes the proc `valid_window_location` to `valid_build_direction`,
and makes it work for things other than windows.
-Removed a deprecated `window_checks` var from the stack_recipe datum.
-Added three more vars to the stack_recipe datum: `check_direction` and
`check_density`, `is_fulltile`
-Decoupled `on_solid_ground` from the object density check. Now you can
set those separately, allowing you to make recipes that forbid/allow
building things over other things while in space.
---
### What the new flags do:
`BLOCKS_CONSTRUCTION` works as before---prevents objects from being
built on the object. I felt that the previous name was not descriptive
enough, you should know exactly what it does just from looking at the
name.
_example: dna scanner_
`BLOCKS_CONSTRUCTION_DIR` -- setting this on an object will prevent
objects from being built on it when their directions are the same.
_example: directional windows, windoors, railings_
`IGNORE_DENSITY` -- setting this on an object will cause its density to
be ignored when performing the construction density check. This could
have other potential uses as well in the future.
_example: grilles, directional windows, tables_
These three flags cover all the bases for the types of items that are
currently craftable, so there is no more need for any type checking or
weird snowflake window checks. Simply set the appropriate flag and it'll
work as you would expect.
---
### What the recipe vars do:
`check_direction` tells the recipe to check if there's something in that
direction with the `BLOCKS_CONSTRUCTION_DIR` flag set.
`check_density` tells the recipe to run the density check when set. This
is true by default. There are very few items in the game that currently
have this set to false--namely grilles. Setting this to false will make
it so that the object can be constructed regardless of what is in that
tile (unless `one_per_turf` is also set, which will make it so that you
can't craft the same thing twice in the same turf).
`is_fulltile` is used for fulltile windows, but it doesn't necessarily
have to be--you can give this to any recipe and it will adopt the same
properties as that of the fulltile window. Basically they have a special
case where they shouldn't be able to be built over directional
constructions, where normally things would be able to be. Setting this
makes check_direction true as well.
---
### In summary:
Sheet crafting still works just as it did before. But the backend of it
has gotten a glow up and will be able to more easily support new
behaviors.
</details>
## Why It's Good For The Game
This makes the crafting system much more flexible to add recipes to, and
will prevent bad code practices of stacking more conditionals down the
line whenever someone wants to add an item that behaves like grilles or
directional windows in how they are constructed.
It had to be done. Those window checks were a mess.
## Changelog
🆑
qol: added fifty stack versions of remaining glass sheet stacks for ease
of debugging
refactor: refactored sheet crafting to better support directional
constructions that aren't windows
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
My April fools this year, though not going to call it one because some
people think it should just be actually merged.
### Chuunibyou Powers 🌟
Wizard gets a new spell for 2 points that gives him the powers of
chuuni. This makes them have ridiculous shouted invocations for all
their spells, their spells are colored pink, and they heal slightly when
casting one.
While mostly a meme spell, I could see a tailored loadout like lichdom
and splattercasting that takes advantage of the unique spellcasting
changes, like a very low cooldown spammable loadout to heal quickly.
There is also a granter book in the library, which teaches a version of
chunni that doesn't heal.
#### Medical eyepatch
I added it, chuuni wizards get a NODROP version.
## Why It's Good For The Game
This PR bestows upon the game the glorious gift of chuuni powers, the
ultimate manifestation of my hidden potential and the secret truth of
this world, which only I and a few chosen ones can comprehend and
unleash! Why wouldn't you want it?!
In all seriousness, it is a unique wizard playstyle and it will make for
some funny memes. Beyond wizard, the chaplain, heretics, or mime can
read it in the library for a very silly round. I like it!
## Changelog
🆑
add: Chuunibyou wizards, and chunni granters in the library
add: Medical eyepatches
/🆑
## About The Pull Request
Code changes:
- Fixes#73946 , Ice Slipping not going forever as intended
- Detailed in the issue report. Ice slide slip was replaced from a stun
to a knockdown, but it relied on it being a stun to function. I replaced
it back with an immobilize and incapacitate, reduced to 1 second to
prevent cheese.
- Refactors noslip mechanics
- Changes noslip and noslip_ice from a clothing flag to a clothing
trait, as the trait already existed and was used by MODsuits. Also added
noslip_slide, which prevents all sliding from slips like lube.
- Refactors magboots
- Refactored and modernized magboot code. Mostly cleanup, like using
base icon state, updating appearance, etc.
- Fixes speed potioned magboots not maintaining the speed boost after a
toggle
- Adds a helper for adding or removing clothing traits from existing,
(potentially) worn items.
- `TRAIT_NEGATE_GRAVITY` now always updates gravity on signal, no longer
requiring a manual call after.
Balance change:
- Magboots now prevent sliding on permafrost (outside icebox).
- This is mainly to give them more of a purpose on Icebox.
- Magboot snow prevent sliding on ice (or lube). You will still slip.
- Slipping over ice or lube will knock you down as before, but will not
send you across the room.
- See https://tgstation13.org/phpBB/viewtopic.php?t=33217.
## Why It's Good For The Game
Magboots justification:
This makes Magboots much less of a "noob trab" for engineers
fire-fighting in the Supermatter room. Most engineers believe themselves
to be completely save to the Supermatter's pull with magboots, however
"wet ice" will still send you flying into the crystal.
I think it is an inconsistency, seeing as it protects you from other
forms of forced movement like gravitational pulls. However making them
pure no-slip seemed a bit too far to me, so the knockdown still occurs.
## Changelog
🆑 Melbert
balance: Magboots will now protect you from sliding on ice. It will not
stop the slip, though.
fix: "Ice sliding" (from patches of permafrost ice) will now correctly
slide you until you reach a non-ice patch.
fix: Speed potioned magboots maintain their speed booster after toggling
them
refactor: Refactored magboots.
refactor: Refactored noslip mechanics.
/🆑
* Core internals refactor. Add open/close_internals procs to /obj/item/tank. Add open/close_internals, can_breathe_internals, and invalid_internals procs to /mob/living/carbon. Fixed bug in human_stripping.dm preventing changing internals for breathing tube users. Fixed bug in /obj/item/tank/toggle_internals that was auto-adjusting non-internals masks. Fixed bug in slements/strippable that caused two mobs to breathe from the same internals.
* Replaces `being_shocked` and `shocked_1` with `TRAIT_BEING_SHOCKED`, removing a flag_1, taking us away from the possibility of hitting the flag limit.
* Optimizes away /obj/Initialize
We were spending like 0.15 seconds just checking for blueprints, obj
flags and network ids
All these things can just be applied where they're wanted, saves time
Oh and I replaced object flags with an emag injector. I'll give it a
sprite and name later I promise
* Requires a GenerateTag() call to set DF_USE_TAG, rather then doing a check in atom New
This is technically harder to use, but I don't really want people using
tags, and it saves 0.15 seconds
* Moves generatetag to /datum
* I am dumb
* Saves 0.5 seconds, makes init emissive blockers actually work
Ok so background. If an overlay is added with add_overlay, and not
"managed" somehow, it will effectively never be removed, because
nothing's tracking it.
Update_overlays uses the managed_overlays list/var (one of those) to do
this.
I'm gonna piggyback off this to make emissive overlays actually like,
respect overlay updates.
Oh and uh, I've saved maybe 0.5 seconds by caching the new emissive, and
not using add_overlay. There's a chance this will lead to overlay
corruption, but since we never readd the flattened, I think we'll be
safe
* Fixes plane not being set right, changes color logic too, since alpha will override past color sets
* Makes it actually work. also makes rand posters update appearance to clear away the overlay, since it shows on right click and looks bad
* Fixes blockers showing as emissives. It turns out alpha sets override the color list we use. Not sure why we pretend to support them
* Makes the injector support traits, adds an amazing sprite
Finally makes external organs (horns, moth wings, antennae etc.) operable!
Also adds a new surgery: feature manipulation. It's a shorter version of organ manipulation that only lets you operate on species features. Note that organ manipulation can operate only on internal organs.
ever see the tram take 10 milliseconds per movement to move 2100 objects? now you have
https://user-images.githubusercontent.com/15794172/166198184-8bab93bd-f584-4269-9ed1-6aee746f8f3c.mp4
About The Pull Request
fixes#66887
done for the code bounty posted by @MMMiracles to optimize the tram so that it can be sped up. the tram is now twice as fast, firing every tick instead of every 2 ticks. and is now around 10x cheaper to move. also adds support for multiz trams, as in trams that span multiple z levels.
the tram on master takes around 10-15 milliseconds per movement with nothing on it other than its starting contents. why is this? because the tram is the canary in the coal mines when it comes to movement code, which is normally expensive as fuck. the tram does way more work than it needs to, and even finds new ways to slow the game down. I'll walk you through a few of the dumber things the tram currently does and how i fixed them.
the tram, at absolute minimum, has to move 55 separate industrial_lift platforms once per movement. this means that the tram has to unregister its entered/exited signals 55 times when "the tram" as a singular object is only entering 5 new turfs and exiting 5 old turfs every movement, this means that each of the 55 platforms calculates their own destination turfs and checks their contents every movement. The biggest single optimization in this pr was that I made the tram into a single 5x11 multitile object and made it only do entering/exiting checks on the 5 new and 5 old turfs in each movement.
way too many of the default tram contents are expensive to move for something that has to move a lot. fun fact, did you know that the walls on the tram have opacity? do you know what opacity does for movables? it makes them recalculate static lighting every time they move. did you know that the tram, this entire time, was taking JUST as much time spamming SSlighting updates as it was spending time in SStramprocess? well it is! now it doesnt do that, the walls are transparent. also, every window and every grille on the tram had the atmos_sensitive element applied to them which then added connect_loc to them, causing them to update signals every movement. that is also dumb and i got rid of that with snowflake overrides. Now we must take care to not add things that sneakily register to Moved() or the moved signal to the roundstart tram, because that is dumb, and the relative utility of simulating objects that should normally shatter due to heat and conduct heat from the atmosphere is far less than the cost of moving them, for this one object.
all tram contents physically Entered() and Exited() their destination and old turfs every movement, even though because they are on a tram they literally do not interact with the turf, the tram does. also, any objects that use connect_loc or connect_loc behalf that are on the same point on the tram also interact with each other because of this. now all contents of the tram act as if theyre being abstract_move()'d to their destination so that (almost) nothing thats in the destination turf or the exit turf can react to the event of "something laying on the tram is moving over you". the rare things that DO need to know what is physically entering or exiting their turf regardless of whether theyre interacting with the ground can register to the abstract entered and exited signals which are now always sent.
many of the things hooked into Moved(), whether it be overrides of Moved() itself, or handlers for the moved signal, add up to a LOT of processing time. especially for humans. now ive gotten rid of a lot of it, mostly for the tram but also for normal movement. i made footsteps (a significant portion of human movement cost) not do any work if the human themselves didnt do the movement. i optimized has_gravity() a fair amount, and then realized that since everything on the tram isnt changing momentum, i didnt actually need to check gravity for the purposes of drifting (newtonian_move() was taking a significant portion of the cost of movement at some points along the development process). so now it simply doesnt call newtonian_move() for movements that dont represent a change in momentum (by default all movements do).
also i put effort into 1. better organizing tram/lift code so that most of it is inside of a dedicated modules folder instead of scattered around 5 generic folders and 2. moved a lot of behavior from lift platforms themselves into their lift_master_datum since ideally the platforms would just handle moving themselves, while any behavior involving the entire lift such as "move to destination" and "blow up" would be handled by the lift_master_datum.
also
https://user-images.githubusercontent.com/15794172/166220129-ff2ea344-442f-4e3e-94f0-ec58ab438563.mp4
multiz tram (this just adds the capability to map it like this, no tram does this)
Actual Performance Differences
to benchmark this, i added a world.Profile(PROFILER_START) and world.Profile(PROFILER_START) to the tram moving, so that it generates a profiler output of all tram movement without any unrelated procs being recorded (except for world.Profile() overhead). this made it a lot easier to quantify what was slowing down both the tram and movement in general. and i did 3 types of tests on both master and my branch.
also i should note that i sped up the "master" tram test to move once per tick as well, simply because the normal movement speed seems unbearably slow now. so all recorded videos are done at twice the speed of the real tram on master. this doesnt affect the main thing i was trying to measure: cost for each movement.
the first test was the base tram, containing only my player mob and the movables starting on the tram roundstart. on master, this takes around 13 milliseconds or so on my computer (which is pretty close to what it takes on the servers), on this branch, it takes between 0.9-1.3 milliseconds.
ALSO in these benchmarks youll see that tram/proc/travel() will vary significantly between the master and optimized branches. this is 100% because there are 55 times more platforms moving on master compared to the master branch, and thus 55x more calls to this proc. every test was recorded with the exact same amount of distance moved
here are the master and optimized benchmark text files:
master
master base tram.txt
https://user-images.githubusercontent.com/15794172/166210149-f118683d-6f6d-4dfb-b9e4-14f17b26aad8.mp4
also this shows the increased SSlighting usage resulting from the tram on master spamming updates, which doesnt happen on the optimized branch
optimized
optimization base tram.txt
https://user-images.githubusercontent.com/15794172/166206280-cd849aaa-ed3b-4e2f-b741-b8a5726091a9.mp4
the second test is meant to benchmark the best case scaling cost of moving objects, where nothing extra is registered to movement besides the bare minimum stuff on the /atom/movable level. Each of the open tiles of the tram had 1 bluespace rped filled with parts dumped onto it, to the point that the tram in total was moving 2100 objects. the vast majority of these objects did nothing special in movement so they serve as a good base case. only slightly off due to the rped's registering to movement.
on master, this test takes over 100 milliseconds per movement
master 2000 obj's.txt
https://user-images.githubusercontent.com/15794172/166210560-f4de620d-7dc6-4dbd-8b61-4a48149af707.mp4
when optimized, about 10 milliseconds per movement
https://user-images.githubusercontent.com/15794172/166208654-bc10086b-bbfc-49fa-9987-d7558109cc1d.mp4
optimization 2000 obj's.txt
the third test is 300 humans spawned onto the tram, meant to test all the shit added on to movement cost for humans/carbons. in retrospect this test is actually way too biased in favor of my optimizations since the humans are all in only 3 tiles, so all 100 humans on a tile are reacting to the other 99 humans movements, which wouldnt be as bad if they were distributed across 20 tiles like in the second test. so dont read into this one too hard.
on master, this test takes 200 milliseconds
master 300 catgirls.txt
when optimized, this takes about 13-14 milliseconds.
optimization 300 catgirls on ram ranch.txt
Why It's Good For The Game
the tram is literally 10x cheaper to move. and the code is better organized.
currently on master the tram is as fast as running speed, meaning it has no real relative utility compared to just running the tracks (except for the added safety of not having to risk being ran over by the tram). now the tram of which we have an entire map based around can be used to its full potential.
also, has some fixes to things on the tram reacting to movement. for example on master if you are standing on a tram tile that contains a banana and the TRAM moves, you will slip if the banana was in that spot before you (not if you were there first however). this is because the banana has no concept of relative movement, you and it are in the same reference frame but the banana, which failed highschool physics, believes you to have moved onto it and thus subjected you to the humiliation of an unjust slipping. now since tram contents that dont register to abstract entered/exited cannot know about other tram contents on the same tile during a movement, this cannot happen.
also, you no longer make footstep sounds when the tram moves you over a floor
TODO
mainly opened it now so i can create a stopping point and attend to my other now staling prs, we're at a state of functionality far enough to start testmerging it anyways.
add a better way for admins to be notified of the tram overloading the server if someone purposefully stuffs it with as much shit as they can, and for admins to clear said shit.
automatically slow down the tram if SStramprocess takes over like, 10 milliseconds complete. the tram still cant really check tick and yield without introducing logic holes, so making sure it doesnt take half of the tick every tick is important
go over my code to catch dumb shit i forgot about, there always is for these kinds of refactors because im very messy
remove the area based forced_gravity optimization its not worth figuring out why it doesnt work
fix the inevitable merge conflict with master lol
create an icon for the tram_tunnel area type i made so that objects on the tram dont have to enter and exit areas twice in a cross-station traversal
add an easy way to vv tram lethality for mobs/things being hit by it. its an easy target in another thing i already wanted to do: a reinforced concept of shared variables from any particular tram platform and the entire tram itself. admins should be able to slow down the tram by vv'ing one platform and have it apply to the entire tram for example.
Changelog
cl
balance: the tram is now twice as fast, pray it doesnt get any faster (it cant without raising world fps)
performance: the tram is now about 10 times cheaper to move for the server
add: mappers can now create trams with multiple z levels
code: industrial_lift's now have more of their behavior pertaining to "the entire lift" being handled by their lift_master_datum as opposed to belonging to a random platform on the lift.
/cl
This PR adds the white cane.
It can be crafted using 3 iron rods. Additionally, white canes can be purchased from the medical vendor, differentiating them from the costume canes.
White canes are transforming items that can be folded down from a small size to their fully extended versions, which are too large to store in a bag.
Adds the foundational system for contextual screentips, which will show you what you can do with objects/items, including through context, such as what you are holding.
Provides several helper elements for most use cases, and applies it to a handful of common objects in order to show the full breadth of the system.
Changes screentips preference from on/off to on/off/only with context. Players who originally had it on off will have it migrated to only with context, though can re-disable it.
About The Pull Request
Allows to place hats(not helmets, and several other hats) on plasmaman helmet. Pure visuals, no armor added.
Why It's Good For The Game
Why not? More customise for plasmemes!
Images
image
image
image
Changelog
🆑 Colovorat
expansion: You can place hats on plasmaman helmets!
/🆑
nevimer
