Repaths obj/machinery to obj/structure/machinery. **Note for
reviewers:** the only meaningful changed code exists within
**code/game/objects/structures.dm** and
**code/game/objects/structures/_machinery.dm**, largely concerning
damage procs. With the exception of moving airlock defines to their own
file, ALL OTHER CHANGES ARE STRICTLY PATH CHANGES.
Objects, _categorically_, are largely divided between those you can hold
in your hand/inventory and those you can't. Machinery objects are
already subtypes of Structures behaviorally, this PR just makes their
pathing reflect that, and allows for future work (tool actions, more
health/destruction functionality) to be developed without unnecessary
code duplication.
I have tested this PR by loading up the Horizon and dismantling various
machines and structures with tools, shooting guns of various types
throughout the ship, and detonating a bunch of explosions throughout the
ship.
Human_defense was calling it's parent, which also EMP'd all carried
items, so carried items were taking two EMP acts.
This mean that PDAs always exploded from light EMPs.
Energy guns used sleep() in their EMP act and didn't multiply by *
SECONDS.
EMP_LIGHT is 2 and EMP_HEAVY is 1, previous implementation was
multiplying where it should divide.
Also added some feedback about why the gun won't fire.
Now decrements a timer in process, 10 seconds for a light EMP, 20
seconds for a heavy EMP.
Several fixes to chemicals that deal brute or burn.
The problem was that their damage was being healed by autoheal faster
than it could add up.
Damage over time chemicals with more than 1dps would suddenly double in
how fast they killed you when they crossed the autoheal threshold.
This fixes that by adding a 60 second delay on wounds autohealing. This
also affects ALL wounds.
If a wound is bandaged it starts autohealing immediately, if it's still
under the authoheal threshold.
To compensate, I've reduced the damage of chlorine/phoron exposure, as
this change effectively increased the damage by 1.
Overall phoron/chlorine exposure is now more dangerous to naked people.
Less dangerous to clothed people.
Less dangerous to people who do the reasonable thing and put their
internals on, previously this was actually worse for you.
Also fixes contamination of items from chlorine and phoron:
- Contaminated items now only damage the bodyparts they cover.
- Contamination now checks if the item can be contaminated before
contaminating it.
- Contamination is now a 100% chance per tick, multiplied by the
permeability of an item. (Most items are permeability 1, labcoats &
other chem resistant medical clothing are 0.5, latex gloves are 0.1,
biosuits, gas masks, etc are 0).
- Contamination respects the permeability of your gloves, it's safe to
handle contaminated items with latex gloves now.
- Air tanks are now permeability 0, your internals won't get
contaminated and force you to take them off.
- Contaminated clothes now deal damage even if you put a spacesuit on
over the top of them.
- Life no longer checks every mob's internal organs for contamination
every tick.
First PR. Adds mechanical representation of faint Hivenet echoes for
Vaurcae. Like the lore, only they can pick them up.
It's designed for a lot of variety so as to trigger every 3-5 minutes
without boring players. All together, there's 500 different echoes.
There are three categories of broadcasts (gossip, happy, tense) split
between "starter" and "response" messages to imitate two vaurcae
talking. These make up 380/500.
Gossip can occasionally have a singular, joined echo to represent only a
single vaurcae talking for extra variety. Happy is less common and tense
is the rarest, implying possible danger.
There's also echoes of projections, on a separate 4-8m timer with 120
different sensations for the remaining echoes.
Hivenet should never feel empty again and echoes extend past being
fluff, they can prompt roleplay since they'd ICly be just as valid as an
in-round broadcast. Echoes are automatically disabled in the Lemurian
Sea to represent the Fog there and can be manually toggled by Admins &
Storytellers for gimmicks or events.
---------
Signed-off-by: runecap <43975590+runecap@users.noreply.github.com>
Co-authored-by: VMSolidus <evilexecutive@gmail.com>
The last time the Light Sensitivity code was changed, I remarked in a
review that "This should probably be a component so that its code isn't
being run on every mob forever". Well I've gotten around to doing that
myself, except I figured out it's even better off as an Element in this
situation rather than a Component. So this is now my first time adding
Elements to the repo. It turns out they're really awesome when paired
with signals.
This PR removes the hardcoded check for the light senstivity and dark
phobia traits from the Life() path, replacing them instead with two
Elements which hook into the pre-existing signal used to handle vision
updates for human mobs. I've mainly done this to help cut down on the
overwhelmingly high cost of the Life() codepath, which is currently one
of the most expensive paths we have.
While I was at it with refactoring these two, I noticed that there
wasn't a trait selection for either of them, so I added selections for
both traits to the disabilities tab so that players can opt-in to being
light sensitive or afraid of the dark!
<img width="318" height="336" alt="image"
src="https://github.com/user-attachments/assets/a1e60e83-d899-44df-8ea3-0cd5a87c231c"
/>
**Summary**
Converts hardsuit NanoUI to TGUI and overhauls much of the associated UI
and module code.
The conversion alone is what necessitated quite a bit of cleanup of our
11-year-old hardsuit code, for which I leaned heavily upon tg's
implementation of MODsuits. Therefore, this is a PARTIAL (???) port of
both https://github.com/tgstation/tgstation/pull/59109 and
https://github.com/tgstation/tgstation/pull/77022. While a lot of
wonderful code and UI design was ported 1:1 (for which I am grateful!),
our hardsuits are still NOT MODsuits. Most of our back-end remains the
same.
Fixes https://github.com/Aurorastation/Aurora.3/issues/22071
changes:
- refactor: "Migrates Hardsuit NanoUI to TGUI."
- refactor: "Updates Hardsuit module type definitions, configuration
data, many misc other functions for the purpose of the UI refactor
(general utility and readability improvements)."
- balance: "Hardsuits now passively consume a small amount of energy
while online, even when retracted."
- balance: "Hardsuit boots can no longer be retracted without also
retracting the chest piece first."
- balance: "Mounted hardsuit storage module max space increased from 9
to 14."
- balance: "Plasma cutter (standalone and mounted) damage increased and
range decreased by 50% each."
- soundadd: "Adds several new sounds for hardsuit use (attribution
located w/ files)."
- code_imp: "Makes power_wattage_readable() a global proc and adds
power_joules_readable()."
- code_imp: "Lots of misc DMdoc updates."
- bugfix: "Synthetic Charging Stations now charge hardsuit power cells
as intended."
**Old UI**
<img width="804" height="1321" alt="Screenshot 2026-05-04 135705"
src="https://github.com/user-attachments/assets/f01957a0-7cec-4fcc-b862-c9dfde0dcc43"
/>
**New UI**
<img width="998" height="782" alt="Screenshot 2026-05-04 174658"
src="https://github.com/user-attachments/assets/ad402902-d489-435a-9c16-82150ed82618"
/>
### Asset Licenses
The following assets that **have not** been created by myself are
included in this PR:
| Path | Original Author | License |
| --- | --- | --- |
| icons/mob/rig_modules.dmi (mounted-plasmacutter)|
[Ghostsheet](https://github.com/ghostsheet) | CC-BY-SA |
---------
Signed-off-by: Batrachophreno <Batrochophreno@gmail.com>
Co-authored-by: VMSolidus <evilexecutive@gmail.com>
Moves all HUD screen object icon files from various scattered locations
to icons/hud. No changes made to any icon_states in this PR, no
player-facing changes. Part of larger icon organization work and in
preparation for action button rework.
Mechanically representing its pre-existing lore and description.
Mechanical description added on the item too.
<img width="416" height="97" alt="image"
src="https://github.com/user-attachments/assets/e70da937-30ab-42f3-bf85-5a8da5accddf"
/>
NEW:
Shaper Helmet now also removes Hive name when physically speaking.
<img width="330" height="65" alt="image"
src="https://github.com/user-attachments/assets/a56af02c-0494-4589-bf15-4d59f6d0767e"
/>
NEWER: Helmet affects visible name and messages. It ignores worn ID for
obvious reasons, but some Shapers may hide their ID while talking to
other Vaurcae.
<img width="533" height="225" alt="image"
src="https://github.com/user-attachments/assets/da85914d-52bc-4036-9616-66e479794fa3"
/>
Full Preimminent Shapers should wear robes and helmet with TTS accent to
be as anonymized as possible. Parts of your carapace that peek through
can be easily hidden as well.
NEWEST: Robes and helmet functionality have been swapped, as it makes
more sense for the robes that cover you up to remove from physical
messages.
I got annoyed with the Hivebot beacon causing me a test fail 3 times in
a row, so I decided to fix it myself. I've done so by:
1. Reworked hivebots to use a weakref to their beacon. No more circular
references.
2. Removed the stupid signal registries on qdeling spam, it's no longer
necessary since there's no longer a circular reference.
3. Fixed a stacktrace in the beacon calling the same function twice.
4. Made the beacon generate its smoke cloud when KILLED rather than when
DELETED (kill calls delete on a timer), so that it can no longer spawn
stupid smoke effects during the unit tests.
5. Made the beacon clear its giant lists of references to a bunch of
turfs when deleted.
Does primarily three things:
- Adds a new dock to the voidtamer ship so ships like the spark can
actually dock
- Adds a new armored carp, basically a reskinned dog that voidtamers can
have
- Minor fixes in the voidtamer ship
---------
Signed-off-by: Yonnimer <31339047+Yonnimer@users.noreply.github.com>
Co-authored-by: SleepyGemmy <99297919+SleepyGemmy@users.noreply.github.com>
renames the basic role access list to "job_access" to make its purpose
clearer and removes the unused expanded access list since we only use
the former. it should also help prevent confusion when adding access to
roles.
server config should be updated.
Having played with it for a couple weeks, made additional changes to
light sensitivity effects. Less frequent and less sensitive, alongside
tweak to cigarette lights (the only common light source that seemed to
have an outsized impact on turf corner light calcs).
Adds:
- Dosimeter, keeps track of how many rads a person has absorbed as well
as showing the dose after armour.
- Adds a message to shelter in maint to the supermatter explosion.
- Adds a flag that makes damage not apply to robotic limbs, useful for
preventing radiation burns to metal parts. Should also be added to
chemicals that deal brute damage, such as arithrazine and the the burns
from chemical exposure to chlorine, but that's another PR.
- Added radiation resistance values to makeshift armour. As it only
covers the chest, this isn't very useful, but better than nothing.
Balance:
- Re-scaled radiation damage.
- Radiation now maxes out at 1000, from the previous 100.
- Radiation damage when at maximum rads is converted directly into burn
damage.
- Radiation sources decay slowly, so all the old numbers were maxing
people's radiation values instantaneously.
- Re-scaled organ damage from radiation. Previously you would take no
organ damage till 75% rads, then lose your liver almost immediately. Now
organ damage ramps up from 500-1000, with 750-1000 being about 1/3rd the
organ damage of 75-100.
- Added debilitating, but not lethal, effects to moderate and high
radiation levels. Lots of pain events instead of straight damage.
- Reduced speed and stamina for high radiation doses.
- Hyronalin and Arithrazine both remove much more radiation.
The intent: People should now be able to work in low radiation zones,
without using the radiation suit for short periods of time.
The geiger counter is no longer an 'if this is ticking you are at max
rads' detector.
With the engineering voidsuit, 75% rads, I could stand next to a charged
supermatter ~50rads a second, for about 2 minutes before I hit lethal
radiation levels.
If people stay in a radiation zone, or are exposed to extreme radiation
100+ rads a second, radiation is much more lethal, but not by just
killing your organs. Conventional medicine will help a lot.
---------
Signed-off-by: FenodyreeAv <fenodyree.av@gmail.com>
Co-authored-by: Batrachophreno <Batrochophreno@gmail.com>
Just cleaning up some Mob Human related timers that occasionally hard
del(). Fixing the /mob/living/carbon/human hard del completely is
proving to be a challenge because there's just so many damn things that
could possibly cause it that there's really no definitive source for it
without having the reference logging enabled.
This PR is a revisit to the previously derelict PR #20159 that has been
unfinished for sometime now. More details about it in general can be
found here:
https://github.com/orgs/Aurorastation/projects/2?pane=issue&itemId=53167153
For awhile I've been talking about "Things I've been doing but it would
be really nice to do them with a skills system", or "And here's how I
would put this into the skills system when it's done". The main thing
that was stopping me from building it myself was having poor real life
skills in UI code and in DB code. However, I've gotten permission to
resume this PR, which has already completed the steps I would not have
been able to do myself. The rest of the PR fits well into my skillset as
a dev.
I'm opening this PR as a draft so as to enable my dev environment to
locally track all the previously modified files. I'll take this PR out
of draft and give this a full writeup when I have more work to show for
the PR this weekend.
### TODO
- [x] Rework a decent chunk of the currently existing skills to no
longer require hardcoded inserts into other systems. EG, converting from
classical ss13 methods, to modern /tg/-style ECS coding methods that
work off of component-signal patterns.
- [x] Make sure all of the existing skills have actual game
functionality (I won't PR a 2016 Baystation12 situation where 90% of the
skills are fluff only)
- [x] Add the various skills not yet made but are necessary for
completion sake, EG: Pilot (Spacecraft), Gunnery, Pilot (Walkers).
- [x] Examine each existing job in the game and assess whether it should
have a skill made with it in mind, or if it's covered by an existing
skill.
- [x] TO DISCUSS, BUT NOT ESSENTIAL: Additional skill proposals not
currently in the pre-existing TODO list, proposing subcategories.
- [x] Ensure that the previous TODO list is completed.
### Current Skills
The current list of skills, checkmarked for if I've completed them/they
have actual game mechanics. Or if we're just relegating them to separate
PRs. Originally this list was going to be forced to visit for a bare
minimum "does at least one thing" requirement, but now that is being
forgone due to this PR ballooning out of control and in complexity, as
well as development time overruns.
- [x] Bartending
- [x] Cooking
- [x] Gardening
- [x] Entertaining
- [x] Electrical Engineering
- [x] Mechanical Engineering
- [x] Atmospherics Systems
- [x] Reactor Systems
- [x] Medicine
- [x] Surgery
- [x] Pharmacology
- [x] Anatomy
- [x] Forensics
- [x] Robotics
- [x] Pilot: Spacecraft
- [x] Pilot: Exosuits
- [x] Research
- [x] Xenobotany
- [x] Xenoarchaeology
- [x] Xenobiology
- [x] Unarmed Combat
- [x] Armed Combat
- [x] Firearms
- [x] Leadership
---------
Signed-off-by: VMSolidus <evilexecutive@gmail.com>
Co-authored-by: Matt Atlas <liermattia@gmail.com>
Co-authored-by: FabianK3 <21039694+FabianK3@users.noreply.github.com>
Co-authored-by: Matt Atlas <mattiathebest2000@hotmail.it>
```
- server: "Changed the synthsprites to use the new DBCore"
- server: "Changed the MalfAI to use the new DBCore"
- server: "Changed the Alien Whitelists to use the new DBCore"
- server: "Changed the Requests Console to use the new DBCore"
- server: "Changed the Contracts Uplink to use the new DBCore"
- server: "Changed the Admin Ranks to use the new DBCore"
- server: "Changed the Job Bans to use the new DBCore"
- server: "Changed the Tickets to use the new DBCore"
- server: "Changed the Create Command Report to use the new DBCore"
- server: "Changed the WebInterface interconnect to use the new DBCore"
- server: "Changed the CCIA Recorder to use the new DBCore"
- server: "Changed the IPCTags to use the new DBCore"
- server: "Changed the Main Menu Poll-Check to use the new DBCore"
- server: "Changed the Client-Procs to use the new DBCore"
```
---------
Co-authored-by: Werner <Arrow768@users.noreply.github.com>
Guess how many people play characters with the Light Sensitive trait who
also have mechanical eyes? At least one, me.
Well it turns out my original implementation ends with your augs
poisoning you because it didn't check for whether your eyes autoheal.
Removed the 1 damage from the fluorescents being too bright.
<img width="1919" height="985" alt="image"
src="https://github.com/user-attachments/assets/f10f6e84-65e3-4a73-b977-4017aca5169a"
/>
I have also actually tested this PR. This PR cleans up Hostile Mob code,
removing **several** hard del conditions that were universal across all
hostile mobs, as well as a few individually specific simple mobs that
weren't cleaning up overlay images correctly. While I was at it, I
removed some verifiably unused vars from hostile mobs.
Light sensitivity traits (either to excess of light or absence of light)
were not firing, because they were tucked behind a 0.1% chance prob for
an unrelated spooky noise proc if you're in pitch black.
Did some testing and found a prob value that was infrequent but not
absent. Also added a little visual effect for the light-sensitive one
(similar to v minor flash, which is 1 eye dmg that immediately heals & a
very brief translucent grey overlay).
* Please describe the intent of your changes in a clear fashion.
Fixes
[SERVER-PROD-8](https://sentry.io/organizations/aurorastation/issues/7404514309/).
The issue was that: Mob's `adjustHalLoss` compares HUD `pain` object to
integer, instead of organ's numeric `pain`.
- Corrected pain check from local 'pain' variable to 'E.pain' when
healing damage.
- Ensures the pain attribute of the specific entity 'E' is referenced.
This fix was generated by Seer in Sentry, triggered by Werner. 👁️ Run
ID: 13169977
Not quite right? [Click here to continue debugging with
Seer.](https://sentry.io/organizations/aurorastation/issues/7404514309/?seerDrawer=true)
* Please make sure that, in the case of mapping changes, you include
images of these changes in the PR's description.
* Please make sure to mark your PR as wip or review required by making a
comment with !wip or !review required
* If you include sprites/sounds/... (assets) that you have not created
yourself specify the license and original author below.
* Ensure that you also credit them in the appropriate location /
changelog as specified in the contributor guidelines
### Asset Licenses
The following assets that **have not** been created by myself are
included in this PR:
| Path | Original Author | License |
| --- | --- | --- |
| icons/example.dmi | ExamplePerson (Example Station) | CC0 |
---------
Signed-off-by: Arrow768 <1331699+Arrow768@users.noreply.github.com>
Co-authored-by: sentry[bot] <39604003+sentry[bot]@users.noreply.github.com>
Co-authored-by: Arrow768 <1331699+Arrow768@users.noreply.github.com>
closes#22079closes#21945
This bug was also my fault, and it happened when I decoupled organ
processing from the life() tick to prevent organs being processed twice.
Since Huds were generated during the Life() tick, but implants were
adding the Hud during Process(), a flicker occured whenever they fired
out of sync, with the Life() tick erasing the hud and Process() adding
it back. To significantly cut down on the time complexity of having to
iterate and fire every HUD producing implant and component during
Life(), I've instead reworked it into a Signal that permits the HUD
implants to inject hud elements into the Life() codepath dynamically.
Here is the fix in action now.
https://github.com/user-attachments/assets/18ccc80d-cb5f-4fd7-9ad5-28c91acf6ca5
Adds some signals to update the HUD when necessary.
The only one which will fire every tick is in remove_pain, which will
now only fire if there is pain to remove.
The extra update in robotize is necessary because robotize is called
after Initialize, so robot limbs were being set to the wrong colour.
Fixes: #22186
# Summary
This PR refactors radiation values and cleans up custom radiation values
without a definition.
This also fixes#22155.
## Changes
- Update ARMOR_RAD_STRONG 75 -> 70, now fits RAD_LEVEL_VERY_HIGH.
- Update radiation level defines:
- NONE = 0
- VERY_LOW = 1 (old LOW)
- LOW = 10
- MODERATE = 25
- HIGH = 40
- VERY_HIGH = 70 (old value was 100)
- EXTREME = 100
- CATASTROPHIC = 120
- Update a couple of rad values to their respective define name (with
minor implicit balancing).
- Remove the super awkward/LRP hairloss with high radiation exposure.
We think the culprit behind this one was VSCode autofilling Destroy()
with . = ..()
which is improper. There's a **surprising** number of improper order
Destroy() procs in the repo, so I might as well get all of them in one
pass. Several of these files are associated with currently known hard
dels, such as the modular computer and organ related dels. More than a
couple were my own mistakes, since the Destroy() or Removed() . = ..()
behavior on signal registering objects also prevents the signal from
being unregistered, which similarly creates a hard del.
Signed-off-by: VMSolidus <evilexecutive@gmail.com>
From testing roughly the same distance, this is how long it took each
species to make it
Geras - 8.49
Coeus - 4.1s
G2 - 6.31
Human - 3.97
Unathi - 4.67
Geras Dionae, while slower than Coeus and humans, should not be this
slow, almost 2.2x slower than a human is by default, which is
near-unplayable, especially given the current balance of Dionae as being
pretty weak. This PR changes it so, from the same distance, Dionae are
roughly 1.5 slower than humans, taking 5.76s. This can be looked at
again in the future when Dionae are in a better place balance wise, but
a weak species with a near-unplayable speed aint a good combo.
(the rotate room thing was from me fugging up and doing something to the
wrong branch)
---------
Signed-off-by: Yonnimer <31339047+Yonnimer@users.noreply.github.com>
The /tg/-style movespeed_modifier datums were not incorporated into the
original smooth movement PR. While
https://github.com/Aurorastation/Aurora.3/pull/22043 restores that
functionality, the original values no longer feel good now that we're on
smooth movement. This PR halves ALL movespeed_modifier/slowdown datums,
with the exception of species-native, as a baseline before more
individual adjustments are made.
Explosions used to randomly pick a limb, based on the weighted list of
their size, then do a little damage to every limb.
This broke when un-targetted damage was defaulted to the torso.
This restores the random organ and fixes DAMAGE_FLAG_DISPERSED to
disperse damage.
These changes are intended to prevent red grabs (neck grabs) being
broken so easily.
It also makes blue grabs very slightly harder to break, by stopping
people from pulling grabbed mobs.
Firstly, the grabbed mobs were not being moved along with their grabber
sometimes.
This happened when the grabber was force moved (such as by a pull, or
another grab or being walked into on harm intent), in which case the
grab that breaks was resolved purely by which had Process called on it
first.
Secondly, you can now no longer pull either the grabber, or the grabbed
mob. This prevents blue-grabs being broken by someone walking up and
pulling either person away, bypassing the Resist mechanic.
Thirdly, a red-grabbed mob cannot be pulled or grabbed by anyone else.
This means the only way to break a red-grab is to disarm the grabber,
stun the grabber, or throw the grabber more than 2 tiles.
https://github.com/user-attachments/assets/9d392229-4544-4546-ae8d-bdfc835fda19
I touched mob, living and mob_movement for this, because the grab checks
were so spread out. I'm not particularly comfortable with having done
that!
I've tested pretty extensively and it seems like nothing broke, but it's
hard to find edge cases without lots of clients and lots of grabs.
This PR is intended to sort out our existing guns into something
resembling organization. In addition, ancient decrepit guns are removed,
and abstract paths are labeled as such.
In addition, all guns are now standardized to refer to their model.
Considering the huge number of weapons we have, a `pistol` is not
descriptive enough.
NOTE: At over 200 files touched, this is being split. Not everything was
sorted, but this is already a monster to sort through. The rest can
wait.
