You can now move and talk through statues and mannequins (#81188)
## About The Pull Request
I recently played a game where I rotated my skeleton model while
rotating my own character at the same time and it being in sync gave me
the realization on how cool it would be if the Coroner was able to
simply control the skeleton body.
I find skeleton displays very funny and I want to see more funny things
happen with them, so I thought this would be a good place to start, with
the benefits that it also works on mannequins and statues too so they
aren't left out.
Basically, while it is unanchored, if you have a statue/mannequin
grabbed, it will change its direction as you do, and speak the same
words you do. Your own messages can only be heard if the person is
directly next to you, revealing that it was you talking through it all
along.
I was originally gonna add this to the simple rotation component but
moved off when I decided to add talking through it, I left in the code
improvements I made to the component though since it is one of the
oldest components and hasn't been touched in a while.
Video demonstration (before I added the person also talking, just ignore
that missing)
https://github.com/tgstation/tgstation/assets/53777086/27242fc3-9649-418d-95cb-b31619319e97
While fixing the Toilet bong's rotation stuff I noticed a lot of it
wasn't up to proper code standards so I went over it and fixed issues I
had with it. It now doesn't give text saying you found something nasty
to species that still likes mice (like flypeople), and fixed its update
appearance to match the codebase standard set by the introduction of
``update_appearance`` many years ago.
## Why It's Good For The Game
It's a funny small idea I had and got inspired to add, it's a niche
mechanic that I think fits the aesthetic I am going for with Coroner and
also give a funny interaction with the human-like inanimate objects.
## Changelog
🆑
fix: Species that can eat mice don't get disgusted from seeing one in
the toilet bong.
add: Grabbing an unwrenched statue/mannequin/skeleton model will now
move its direction as you move yours, and you can talk through it.
/🆑
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
* health assembly altclick sanity (#81264)
## About The Pull Request
checks can_interact now
## Why It's Good For The Game
bug bad
## Changelog
🆑
fix: you may not toggle health assemblies from any range, even while
crit
/🆑
* health assembly altclick sanity
---------
Co-authored-by: jimmyl <70376633+mc-oofert@users.noreply.github.com>
* Kills off /obj/item/onetankbomb, assembly bombs now handled by the tank itself (#81218)
* Kills off /obj/item/onetankbomb, assembly bombs now handled by the tank itself
---------
Co-authored-by: SapphicOverload <93578146+SapphicOverload@users.noreply.github.com>
* Some Processing improvements (#80693)
## About The Pull Request
Got the idea from #80682. A lot of parent procs don't do anything, some
are just formatted in a bad way, and others early return and do no ops,
it's bad in general but this should give us a head start.
Some good overhead saved here
* Some Processing improvements
---------
Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com>
* Demotes the "electrical conductivity" flag from `flags_1` to `obj_flags` (#80033)
## 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™️
* Demotes the "electrical conductivity" flag from `flags_1` to `obj_flags`
* Modular
* Update misc.dm
---------
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com>
* Adds `UPSIDE_DOWN` movetype for negative gravity / makes Atrocinator affected by less things (#79785)
## 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>
* Adds `UPSIDE_DOWN` movetype for negative gravity / makes Atrocinator affected by less things
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: Ghom <42542238+Ghommie@ users.noreply.github.com>
* Cuts down on unnecessary non-TGUI stuff (#79590)
## About The Pull Request
Removes INTERACT_MACHINE_SET_MACHINE on machines that don't use a
non-TGUI UI.
Removes set_machine from TGUI things that forgot to remove them
previously.
Decouples advanced camera consoles from UI procs since it doesn't
actually use one.
## Why It's Good For The Game
TGUI machines don't need to be using these procs and vars, and this
makes it more clear what does and doesn't use a TGUI menu from a glance.
I explain it a bit better
[here](https://hackmd.io/XLt5MoRvRxuhFbwtk4VAUA) if you're interested.
## Changelog
No player-facing changes.
* Cuts down on unnecessary non-TGUI stuff
---------
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
* fixes signal circuit not working | refactors name of timer cooldown macros to be inherent, also docs them (#79367)
## About The Pull Request
Title
## Why It's Good For The Game
Less headache in the future for a macro thats not really obvious in what
it does
## Changelog
🆑
fix: signals in circuits now actually function
/🆑
* fixes signal circuit not working | refactors name of timer cooldown macros to be inherent, also docs them
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
* Updates signaler investigate code | Adds some nice QOL changes for signalers | Enforces cooldown on signaler circuitry (#78974)
## About The Pull Request
See title.
If someone was abusing signalers previously to cause server lag, going
into list signalers would actually cause even worse lag as byond sat
there and processed thousands of items into a string over and over,
which would cause string format operations on longer and longer strings,
resulting in more and more overhead. This is bad.
So instead there is now a limit to the size of the list, currently I
have that set to 500 although I am open to increasing and even reducing
the number.
I have also made signalers slightly more intuitive by having the
cooldown actually displayed in the ui as a tooltip instead of just being
a secret feature you didnt know about unless you code dived. Also made
the cooldown actually respected by things such as circuitry where it
didnt even implement the cooldown and would happily send as many signals
as you had items connected to your proximity circuit.
## Why It's Good For The Game
Admins won't accidentally kill the server by trying to parse a lag
machines signal list. Players lagging the server? No, how about the
admins trying to fix it!
## Changelog
🆑
qol: signalers now tell you their cooldown and also use balloon alerts
/🆑
* Updates signaler investigate code | Adds some nice QOL changes for signalers | Enforces cooldown on signaler circuitry
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
* Invisibility refactor (#78908)
This adds a tracker for sources of invisibility and a priority system. I
needed this for another thing so I'm doing this first since it touches a
lot of code. As for the bugs fixed in the changelog, it's only what I
noticed while going through everything and there's likely a few more
things fixed with this. This should be testmerged for a while, I'll
bring this out of draft when it feels safe.
🆑
admin: Invisimin can now be used on mobs that are already invisible,
whether through temporary or permanent effects.
fix: Monkeyize/Humanize mob transformations no longer permanently reveal
invisible mobs if they had effects making them invisible otherwise.
fix: Objects with the undertile element that have been made invisible
through other means are no longer revealed by being uncovered.
/🆑
* Invisibility refactor
---------
Co-authored-by: Emmett Gaines <ninjanomnom@gmail.com>
* Fixes greyscale colors not updating when changing their colors via VV, and fixes some issues with accessories (#77806)
## About The Pull Request
Fixes https://github.com/Skyrat-SS13/Skyrat-tg/issues/23214
This fixes a few bugs and cleans up code a bit:
1) Greyscale colors that were changed via the VV modify greyscale menu
will now update the mob's worn clothing accordingly. It wasn't doing
this before. Accessories in particular needed a bit of extra work to
update in this way because it wasn't coded with this case in mind.
2) Accessories will call `equipped()` and `dropped()` when they get
added/removed. This will fix issues like item flags being incorrectly
set, action bars not being added, etc.
3) Accessories will now be returned by `get_all_gear()`. This will
probably fix a few issues I'm not aware of.
## Why It's Good For The Game
<details><summary>Works</summary>
</details>
<details><summary>get_all_gear()</summary>
</details>
<details><summary>get_equipped_items()</summary>
</details>
<details><summary>item_flags get set now, hopefully preventing future
issues related to that</summary>
</details>
## Changelog
🆑
fix: greyscale colors will now update on the mob when modifying them via
the VV menu
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@ users.noreply.github.com>
* Fixes greyscale colors not updating when changing their colors via VV, and fixes some issues with accessories
---------
Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com>
Co-authored-by: Ghom <42542238+Ghommie@ users.noreply.github.com>
* Immovable rod meets unstoppable tram (#77656)
## About The Pull Request
Adds interaction between immovable rod and the tram for the rare
occasions the rod hits it at the front or back while flying at a
parallel angle.
The rod will push/pull the tram in the direction it's flying until a
short distance past the tram's usual landmark, eventually winning and
carrying on.
- Only applies to random rods, if the rod has a target it will ignore
the tram as usual.
- Looping rod only pushes the tram once.
- As long as the tram has power, can be returned to the rails as usual
by calling it.
## Why It's Good For The Game
When the HoP is having a really unlucky day.
https://github.com/tgstation/tgstation/assets/83487515/2f0393cd-f796-4b00-8674-d97e57358543https://github.com/tgstation/tgstation/assets/83487515/f74c8497-8d62-4fcf-80a0-da7259160b7f
## Changelog
🆑 LT3
add: Immovable rod will now battle the unstoppable tram should they
cross paths
fix: Birdshot's maint tram doors now work properly
fix: Tramstation's exterior light fixtures no longer get destroyed as
soon as the tram moves
code: Tram landmarks are now all subtyped instead of map varedits
/🆑
* Immovable rod meets unstoppable tram
---------
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
* Change mousetraps to kill rats instantly (except regal rats) (#77487)
## About The Pull Request
Today I witnessed a minefield of mousetraps against a horde of mice. To
my surprise, they were able to tank multiple mousetraps without dying.
Mousetraps should insta kill any mice (or rats) caught in it otherwise
it defeats the purpose of setting the traps especially when there is a
horde of them. Cat's instakill any mice they touch. This should follow
the same formula. The only exception should be regal rats, which are
already excluded from mousetrap damage code.
## Why It's Good For The Game
When you arm a dozen mousetraps, there should be a dozen dead mice.
## Changelog
🆑
balance: Change mousetraps to kill mice instead of damaging them (except
regal rats)
/🆑
* Change mousetraps to kill rats instantly (except regal rats)
---------
Co-authored-by: Tim <timothymtorres@gmail.com>
* A small pile of borg combat changes (#75819)
## About The Pull Request
This PR rebalances borg combat. It is first part of broader set of
changes that I talked about with armhullen, which was then discussed in
discord player project channel. Ultimately arm decided to rewrite the
complete rebalance and grab combat, but to help with testing, and to
measure reaction to that changes, I wrote this much smaller change, that
should be usable as a TMd test.
Main points that changed:
- Flashing cyborgs for the first time blinds them, and scrambles their
movement. Flashing them while they are blinded immobilizes them as it
used to, but still allows them to talk, and use radio.
- Emping cyborgs still turns them completely off, but the code behind is
_slightly_ changed, because of how utterly incomprehensible cyborg code
is
- Borg stunarm deals 60 stamina damage, costs 200 energy (SUBJECT TO
CHANGE AS SOON AS I DECIDE ON HOW TO), and applies confusion,
stuttering, and jittering.
- Robot consoles used by humans can now lock down only one borg at a
time, they exhibit increased power draw while doing so. The borg is also
informed of the location of the console. If left alone, the borg will
unlock itself in 10 minutes, to avoid leaving it permanently locked down
in some faraway place. If the console gets destroyed (or depowered), the
borg will get unlocked
- laser pointer only blinds borgs, without the paralyze component. If
you flash a borg blinded this way it will paralyze it, so comboing it is
possible.
- Throwing things at borgs slows them down
Not planned, but possible if testing shows its required:
- Changing borg health to malfunctions
- Whatever people convince me to add
- Portable lockdown solution for sec, or a way for them to do basic
check on borg.
- Usage of bucket/something else to restrict radio usage of cyborg
If you have ideas what would make this change better please use [discord
channel](https://discord.com/channels/326822144233439242/1113145741788065924),
or comments. Almost everything that I wrote here is subject to change,
as requested or suggested.
### DISCLAIMER
I had to change few functions in background of how borgs work. This WILL
have changes I couldn't predict, since some of them aren't linked in any
obvious way in code. I am aware of that, and will try fixing what needs
fixing when pointed out.
PS: Borg code is a nightmare
## Why It's Good For The Game
Borg combat sucks. It is absolutely binary, there is 0 capacity for
talking, because both sides fear losing in one click. Sec can't really
feasibly ask the borg to state laws while flashed, so their only
solution is to kill it and revive it.
- Turning most instastun solutions into less lethal versions should
lessen the pressure, since it reduces the chance that person that reacts
first survives.
- It causes minor reduction in traitor's capacity to emag borgs with
only a flash, but EMPs still hardstun, and they are plentiful both in
uplink, and in ghetto form, so that shouldn't be a problem.
- Since it allows borgs to scream for help while being flashed, it also
increases the potential of AI helping it, or at least noticing its
death.
- Lockdown console changes reduce its capability in completely turning
off malf ai, and leave it still highly capable of being an useful tool
in stopping emagged cyborgs.
## Changelog
🆑
balance: Flashing borgs requires two consecutive flashes to fully
immobilize
balance: Flashed borgs can speak
balance: Remote lockdown on cyborgs lasts 180 seconds
balance: Cyborg stun arm works like normal baton, and costs less energy
/🆑
---------
Co-authored-by: ATH1909 <42606352+ATH1909@ users.noreply.github.com>
Co-authored-by: Jacquerel <hnevard@ gmail.com>
* A small pile of borg combat changes
---------
Co-authored-by: Kubisopplay <38842052+Kubisopplay@users.noreply.github.com>
Co-authored-by: ATH1909 <42606352+ATH1909@ users.noreply.github.com>
Co-authored-by: Jacquerel <hnevard@ gmail.com>
* Machine list is now stored in SSmachines | Remove excessive use of global lists for specific machine types
* Resolve merge conflicts
* Modular adjustments
* destroy this double return on destroy
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
Co-authored-by: Giz <vinylspiders@gmail.com>
* Standardize Welder Fuel Usage (#76021)
Remove welder fuel usage from all actions except attacking and leaving
it on
most welder tasks require a minimum of 1u of fuel, some longer tasks
require a minimum of 2 or 3u welders now drain 1u every 5 seconds
they're active
## About The Pull Request
Prior to this PR welder fuel usage was random, a lot of tasks didn't use
any welder fuel and welders were basically near infinite so long as you
didn't use them for combat, it took 26 seconds of activity to drain 1u
of fuel, that means an emergency welder alone could run for 5 minutes
straight before needing a refuel
After this PR all welders will drain 1u every 5 seconds instead of every
26 seconds, but welding objects won't require extra fuel anymore, making
the fuel usage much more consistent.
resolves#55018
## Why It's Good For The Game
Actually makes fuel tanks useful and relevant without making it
obnoxious to do repetitive quick tasks like turn rods into plates,
there's actually a reason to upgrade off the emergency welder now since
it lasts 50 seconds rather than 5 minutes
## Changelog
🆑
qol: Welders now have a more consistent fuel usage
/🆑
* Standardize Welder Fuel Usage
---------
Co-authored-by: Couls <coul422@gmail.com>
* Fixes cases where doors do not bolt correctly (#75882)
## About The Pull Request
Some things, like door control buttons, set locked directly instead of
calling lock() or unlock(). This fixes that, which should make sound
effects play. Also annotates some code where we *don't* want that to
happen with an explanation of why we just set locked directly.
## Why It's Good For The Game
Fixes Skyrat-SS13/Skyrat-tg/issues/21510, which also applies to
upstream.
* Fixes cases where doors do not bolt correctly
---------
Co-authored-by: Penelope Haze <out.of.p.haze@proton.me>
* Hot Stuff(Igniter's & Sparkers) are buildable. (#75722)
## About The Pull Request
**1. Igniter's**
Those things which you see in atmospheric's incineration chamber &
ordanance lab used to ignite gases, they can now be crafted
- **Interactions**
a) attack with hand to turn it on/off
b) use a multitool to change it's ID(how that's useful? keep reading)
c) use welding tool to deconstruct it
**2. Sparker's**
No they aren't a new thing, you probably woudn't have noticed them but
it's this thing in xenobiology lab for example, and you use the button
to turn it on
They function the same as igniter's(i.e. combust gases) except as the
name implies they emit spark's to get the job done
These can now also be made in the autolathe as a wall mount
Yup just stick it on a wall and your done
- **Interactions**
a) use a multitool to change it's ID(how that's useful? keep reading)
b) use welding tool to deconstruct it
To turn this on see the last section
**3. Ignition Switch Controller**
These function just like blast door controller's except they can control
only sparker's & igniter's
Also printable in autolathe
- **How it work's(or a reminder if you already know)**
a) First use multitool on sparker/igniter to set their ID's
b) Use multitool on this controller to set it's ID to be the same as
your sparker/igniter ID. If the igniter, sparker & this controller all
share the same ID you can use this controller to turn all device's
on/off at once
c) stick it in a button frame & close
d) use button
Hot Stuff
https://github.com/tgstation/tgstation/assets/110812394/8b59a71e-8992-428e-a629-5c371b5c0c3d
Ok so really what's the actual difference's between an igniter & sparker
1. Igniter's are built on the floor while sparker's are mounted on
wall's
2. Igniter's have `max_integrity = 300` while sparker's have it s normal
`max_integrity = 100` so yeah igniter's are more durable than sparker's
3. Igniter's keep the turf hot continuously as long as it's on so they
take up power continuously, so their operation cost is high whereas
sparker's emit spark's only once and use power only that one time so
they are cheaper to operate
**Why it's good for the game**
Make your own combustion chamber professionally and not in an improvised
way. Honestly I'm tired of seeing people chuck in lit welding tool's/
Zipo lighter's to ignite the gases and we loose those item's so yeah now
we have the tool's to do it the right way
## Changelog
🆑
add: Igniter's can be crafted
add: Spraker's can be printed in the autolathe
add: ignition controller can be printed in the autolathe
/🆑
---------
Co-authored-by: Fikou <23585223+Fikou@ users.noreply.github.com>
* Hot Stuff(Igniter's & Sparkers) are buildable.
---------
Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com>
Co-authored-by: Fikou <23585223+Fikou@ users.noreply.github.com>
fixes runtime when building things with proxy sensors that get deleted in the process (#70786)
proximity_monitor.set_host() was being called after being deleted (qdel -> movetonullspace -> dropped())
Co-authored-by: ShizCalev <ShizCalev@users.noreply.github.com>
* Fix SHOULD_NOT_SLEEP hit in infra assemblies (#75408)
See #75232
refreshBeam() is a sleeping proc, dropped gets called on Destroy()
* Fix SHOULD_NOT_SLEEP hit in infra assemblies
---------
Co-authored-by: Jordan Dominion <Cyberboss@users.noreply.github.com>
* Fix SHOULD_NOT_SLEEP hit in mass driver activation (#75273)
See #75232
* Fix SHOULD_NOT_SLEEP hit in mass driver activation
---------
Co-authored-by: Jordan Dominion <Cyberboss@users.noreply.github.com>
* AOE flash fix (#74556)
## About The Pull Request
Fixes head revolutionaries being able to convert with the AOE mode
Why did AOE flash even have a targeted arg? Dumb
## Changelog
🆑 Melbert
fix: Head revs can no longer convert with the AOE flash mode
/🆑
* AOE flash fix
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* Moves revolution code of out of flash code, fixes April Fool conversion forcesay never working in any cirumstances (#74411)
## About The Pull Request
- Signallizes head revolutionary flash conversion code, moving it out of
core flash code.
- Removes "tacticool" flashing from head revs, but they can still
convert from any direction
- Fixes April Fools "You son of a bitch! I'm in" force say never
working.
- Revs are muted on conversion so they couldn't talk.
- Fixed by only muting revs on non-holidays
- Cultists are unconscious on conversion so they couldn't talk
- Fixed by only unconscious-ing cultists on non-holidays
- Brainwash victims are more often than not unconscious / asleep so they
couldn't talk
- Just left this one.
- Reduced the chance of them occurring and limits it to April Fools only
- A 1% chance of the force says ocurring means they will happen pretty
much once a week, given multiple rev / cult rounds happen every week and
on average like, 20 people are converted. A little absurd, it's good
that it never worked?
## Why It's Good For The Game
Antag code in core item code is bad
It's funny this meme has existed for like 2, 3 years now? No one's
tested it, it's never worked
## Changelog
🆑 Melbert
refactor: Removes Rev code from core flash code
fix: Getting converted on April Fools now triggers the meme force say as
always intended
del: The meme force say can no longer trigger on any day (it didn't work
before anyways)
/🆑
* Moves revolution code of out of flash code, fixes April Fool conversion forcesay never working in any cirumstances
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* Tram signal process/destination improvements (#74072)
## About The Pull Request
- Tram crossing signals now call process() much less often
- Tram crossing signals don't turn amber/red needlessly
- Tram destination landmarks are more generic to accommodate future
maps, like Birdshot
- Renames to_where and from_where, because those vars didn't always
match tram position to/from
## Why It's Good For The Game
Tram works better, uses less processing
## Changelog
🆑 LT3
code: Tram crossing signal/platform logic improvements
/🆑
* Tram signal process/destination improvements
---------
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
* Made assembly bombs unable to multignite (#73446)
Added stack traces for multignition events
Also moves the tank procs into the tanks file from bomb because I can
and I hate the previous organisation
* Made assembly bombs unable to multignite
---------
Co-authored-by: oranges <email@oranges.net.nz>
* Made prox sensor cooldown apply before pulse effect (#73447)
This prevents it pulsing multiple times before the next activation time
is reached
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Made prox sensor cooldown apply before pulse effect
---------
Co-authored-by: oranges <email@oranges.net.nz>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Minor improvement to blast door construction. (#73038)
## About The Pull Request
This PR does some QOL tweaks to blast doors and their construction.
Namely, adding some balloon alerts to the whole construction process
(adding, removing electronics, adjusting their electronics IDs).
Additionally, adds some extra examine text to an open blast door by
explaining that you can multitool it to adjust the ID, and that it must
match that of the blast electronics to be added to a wall frame.
Adjusts a forcedrop to a `move_to_hands` because it's 2023 and we trust
that users can hold things during a attack_hand proc.
Also adds some description to button frames as well to guide them that
they can install and remove electronics and boards while open.
I'm gonna be real, this needs a LOT more work than this to be up to code
standards, but this was what I could pull off in the 30 minutes before I
need to sleep while away on business, but it's a start nonetheless.
## Why It's Good For The Game
Button frame code is practically ancient, yet it's still widely used to
this day. It needs some real polish more than this, but for now this
will at least make the construction process more intuitive and clear.
Also to that guy who I said I would do this about a month ago I'M SORRY
I'VE BEEN TRAPPED IN THE **_SUPERMAX WAGE CAGE_** I CAN PROVE IT
~~Wait what do you mean you need to make player made blast doors through
the CRAFTING UI WHAT THE FUUUUUUUU~~
## Changelog
🆑
qol: Improves feedback on buttons as well as the blast door electronics
so that installing your very own blast doors is less tedious.
/🆑
* Minor improvement to blast door construction.
---------
Co-authored-by: ArcaneMusic <41715314+ArcaneMusic@users.noreply.github.com>
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
* Converts blindness and nearsightedness to status effects, scratches some VERY dumb blindness handling that resulted in mobs becoming "incurably" blind
* Fixes the conflicts and makes shit compile!
* Fixes other things that didn't show up because I hadn't updated
* Fixes the lints.
* Okay NOW it's ready (please don't add anything else that touches blindness I beg you)
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
Tram Mk. IV (#73057)
- After one too many tram malfunctions, Nanotrasen's insurance provider
finally sprung the cash for a new tram. Made with the latest in
lightweight materials, there's more capacity than ever before to shuttle
your crew around the station.
https://user-images.githubusercontent.com/83487515/215639768-3f7fcb84-cfd2-4efe-b578-998197651f13.mp4
- Consolidates all the tram turfs, objs, and structures into respective
.dm files because they were haphazardly spread everywhere.
- Fixes tram doors playing open/close animations when they're already in
the correct state, corrects timing for when they change density.
- Tram now correctly has an operating status and will stop functioning
when power is lost.
- Call buttons no longer dispatch a tram that doesn't have power.
- Fix for emergency exit when tram has no power.
- Running at closing tram doors is a gamble, you may be crushed
- Fixes https://github.com/tgstation/tgstation/issues/73125
Looks nice, more space, tram doors demand a pound of flesh.
🆑 LT3
imageadd: Nanotrasen's insurance provider finally sprung the cash for a
new tram. Made with the latest in lightweight and mostly* non-flammable
materials, travel in comfort and style!
code: All tram components are now organised based on type
code: Tram is now aware if it has power or not
del: Removed movement slowdown running on tram plates
fix: Tram call buttons will not work calling an unpowered tram
fix: Tram doors will no longer cycle open/closed when they're already in
the correct position
fix: Fixed an edge case where running onto the tram you bounce off the
open door as if it was closed
fix: Unpowered tram doors can only be forced into the open position
fix: Westbound travel shows the correct controls animation
add: Tram doors take a chunk of flesh if you run at them last minute
qol: Reduced duration of amber stage on tram crossing signals
/🆑
Add lints for idiomatic balloon alert usage (#72280)
Adds lints for `balloon_alert(span_xxx(...))` (which is always wrong),
and balloon alert where the first letter is a capital (which is usually
wrong). Fixes everything that failed them. As a reminder, abbreviations
like "AI" and "GPS" shouldn't be capitalized in a balloon alert.
In cases where this is intentional for flavor (there was one case), you
can `UNLINT` like so:
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
* Converts drowsy and eye blur to status effects, striking yet another two carbon level status vars
* merge conflicts
* adjust_eye_blur and set_eye_blur_if_lower
* adjust drowsiness overdoses
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: tastyfish <crazychris32@gmail.com>
* makes status tab use signals, thirds the delay between updates (#72002)
## About The Pull Request
status panel for carbons and humans instead of hardcoding stuff, uses
signals (borg material storage too)
removes combat mode indicator in status tab from xenomorphs which have a
button for it, but adds it to simplemobs, since they dont have a visual
indicator
adds status tab stuff to basic mobs, i think they were missing
everything by accident
offsets unique status tab stuff for all mobs by a single line
the delay between updates is a third of what it was before, mainly to
make shuttle timers more accurate (approved by kyler)
## Why It's Good For The Game
much cleaner code, makes future implementations easy
## Changelog
🆑
qol: you can see your combat mode status as a simple or basic mob, and
you can see your health as a basic mob
qol: status panel updates three times as fast
/🆑
* makes status tab use signals, thirds the delay between updates
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
* Saycode refactor, unit tests, and fixes
* parrot
* SR tweaks
* say tests from pstream/71873
Co-authored-by: Tim <timothymtorres@gmail.com>
Co-authored-by: tastyfish <crazychris32@gmail.com>
* Fixes an exploit with stacking igniters. Refactors some assembly flag oddities. Limits assembly holders at 12 assemblies. (#71264)
## About The Pull Request
Soft revert of #71224 , Fixes#71222
Fixes an exploit involving attachment of multiple igniters to one
assembly.
- Multiple igniters or condensers can no longer be attached to the same
assembly holder
- Assembly holders have a limit of 12 assemblies maximum
- I'm not sure if this is too low or limited, I picked it arbitrarily.
Please inform me if it could be upped a smidge.
- This lag exploit was born because of limitless assembly holders, which
is a little silly even with the exploit aside. All that uncapped holders
can bring are exploits or bugs, which I feel confident limited can
prevent. What use is there even for having so many?
- Cleans up / refactors some aspects of assemblies and assembly holders.
- Assemblies had a weird wire type flag that was only ever used by
signallers, but also used wrong by signallers. I did some scanning of
the code and realized that ... a lot of this was just straight up
unused, and not even assigned anywhere.
- Now, there is a flag assembly flag var, which everything is read off
of. Tested it and still seemed to all work fine.
## Why It's Good For The Game
Lag exploits are bad.
## Changelog
🆑 Melbert
fix: Fixed an exploit involving igniters attached to themselves.
Assembly holders are now limited to 12 assemblies maximum, and you
cannot attach multiple igniters to the same assembly.
refactor: Refactored some assembly jank, namely in how they pulse and
are pulsed.
/🆑
* Fixes an exploit with stacking igniters. Refactors some assembly flag oddities. Limits assembly holders at 12 assemblies.
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* Strays away from GLOB.machines when possible (#71100)
## About The Pull Request
This replaces needless GLOB.machines with more precise lists whenever
one existed, plus adding a new one for CTF machines.
## Why It's Good For The Game
GLOB.machines holds every single /obj/machinery in the game, so checking
the whole list for stuff is pretty big. This aims to cut that down by
using smaller lists whenever possible. I also gave CTF a new list
because it checked machines very often.
## Changelog
Nothing player facing.
* Strays away from GLOB.machines when possible
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
* Fixes a server lagging bug with igniters. (#71224)
🆑 Iamgoofball
fix: You can no longer attach igniters to igniters.
/🆑Fixes#71222
Players were using this to lag the server.
Co-authored-by: san7890 <the@ san7890.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Fixes a server lagging bug with igniters.
Co-authored-by: Iamgoofball <iamgoofball@gmail.com>
Co-authored-by: san7890 <the@ san7890.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Fixes proximity sensors to work on 0 tile now (#70859)
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
## About The Pull Request
Previously it didn't work while it was supposed to, setting it up to 0
tile range would make it useless and not trigger. Now it does.
https://www.youtube.com/watch?v=ouseFRoEgD8
<!-- Describe The Pull Request. Please be sure every change is
documented or this can delay review and even discourage maintainers from
merging your PR! -->
## Why It's Good For The Game
Fixes are good for the game
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
## Changelog
🆑
fix: fixed the prox sensor
/🆑
* Fixes proximity sensors to work on 0 tile now
Co-authored-by: exymian <66227760+exymian@users.noreply.github.com>
