Another and hopefully my last fix for the Observer hard dels. This
probably but might not also clear the Storyteller harddel since they're
an observer child. But I dunno. I have actually tested this.
<img width="670" height="435" alt="image"
src="https://github.com/user-attachments/assets/41e75448-211d-429b-b694-43b9d025e996"
/>
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>
The Planemasters Update gave observers a hud reference to store, but no
Destroy() method was added for them to clear this reference when
despawning, which caused a hard del. Pretty simple fix.
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.
Fixes https://github.com/Aurorastation/Aurora.3/issues/21669
Fixes https://github.com/Aurorastation/Aurora.3/issues/21951
Fixes https://github.com/Aurorastation/Aurora.3/issues/21972
Fixes https://github.com/Aurorastation/Aurora.3/issues/22077
changes:
- bugfix: "All movespeed_modifier slowdown data now applied correctly
post-smooth movement PR. IE: active magboots, duffel bags, etc. again
slow you down."
- bugfix: "Sofas no longer able to be rotated while anchored."
- bugfix: "Attempting to use crowbars, fire axes, hammers on airlocks
while in the Hurt intent will now make you attack the airlock."
- bugfix: "Fixes graphical bug with open lid graphics for crates painted
in any engineering color variants."
- bugfix: "Individual butterfly knife parts are no longer larger than
butterfly knives themselves."
- bugfix: "Elevators that squish mobs (any type of mob/living) will now
appropriately gib instead of just quietly deleting them."
- rscadd: "Miniature fusion reactor explosions now use subsystem
radiation instead of manually applying rad damage to all mobs in range."
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.
Ports screen alerts from CM13. This enables an immediate reference to
whether you are cuffed or buckled. It also provides an easy way to get
out of said situation by simply clicking on the alert.
<img width="430" height="454" alt="image"
src="https://github.com/user-attachments/assets/0c20abf2-0901-49e0-ac29-492ba7c6dbe5"
/>
### Asset Licenses
The following assets that **have not** been created by myself are
included in this PR:
| Path | Original Author | License |
| --- | --- | --- |
| icons/mob/screen_alert.dmi (buckle, succumb) | CM13Devs (CM-13) |
CC-BY-SA 3.0 |
Stasis now gives a ripple effect on the mob when they are under it, as
well as giving them a HUD icon. In addition, this improves stasis bed
code, fixing a bug and adding some neat stuff too.
title
I was lied to by the incapacitation proc (it does not actually check
incapacitation necessarily)
---------
Co-authored-by: Matt Atlas <liermattia@gmail.com>
Instead of middle clicking to lie down, you now simply rest. You can
also now do it with your gun in your hand. Removes all code related to
bespoke lying down.
To-do:
- [x] Add a signal to make firearm accuracies update on lying down.
---------
Co-authored-by: Matt Atlas <liermattia@gmail.com>
Fixes#21974
Turns out we had ancient code that used a hardcoded bodytemp value to
lower people's movespeed if they got too cold. Tajara naturally want a
cooler body temp, and as a result they could end up movespeed nerfing
themselves silently. Now the movespeed nerf is pegged to
cold_discomfort_level, so your move speed will only be nerfed when you
start getting warnings about feeling too cold.
For the upcoming Tajara ethnicity overhaul.
Zhan-Khazan can now be Operations Managers and Chief Engineers. M'sai
can now be Executive Officers.
Putting this up now for code review purposes. Full retcon will be
announced soon (and then this can be merged).
Organs were being given ~3 seconds of DT per ~2 seconds of real time,
because they were being hit by Process() TWICE, once during processing
for the "Set of all objects", and again during processing for the "Set
of all mobs". No species was hit harder than this but IPCs, who suffered
from having wildly inconsistent temperature mechanics that seemingly
never matched the expected numbers.
I have actually tested this PR to verify that it works. I even went the
extra mile to more extensively test IPC temperature mechanics to find a
separate bug unrelated to DTs that was causing suit coolers to just
straight up not work at all (space suit or otherwise) on a majority of
all IPC subspecies. I then tested the numbers in the PR for IPC cooling
to verify that things work as intended.
<img width="969" height="623" alt="image"
src="https://github.com/user-attachments/assets/01c3aca7-b436-4e52-86f7-aed847dcba5e"
/>
I also tweaked all the subsystems to have a small performance
improvement.
---------
Signed-off-by: VMSolidus <evilexecutive@gmail.com>
We don't need a million paint guns. Makes it so a single paint gun can
paint whatever you want. Which now also includes crates and lockers.
changes:
- rscadd: "Paint sprayers can now be used on unpainted crates and
lockers to give them a custom appearance."
- rscadd: "Adds paint sprayers to Hangar Tech lockers."
- qol: "Moves pipe painter functionality to paint sprayers; pipe
painters now just flavor objects on some offsites."
- qol: "Adds paint sprayers to allowed items list for utility
toolbelts."
- imageadd: "Codersprites pipe painter with recolorable paint storage
component indicating current color (used by paint sprayer)."
- imagedel: "Removes old paint sprayer sprite."
- bugfix: "Removes old runtime caused by targeting turfs w/ paint
sprayers that don't have flooring singletons assigned."
<img width="496" height="505" alt="Screenshot 2026-02-20 142403"
src="https://github.com/user-attachments/assets/152ea63a-4baf-48e5-864e-400caef9efc6"
/>
<img width="515" height="429" alt="Screenshot 2026-02-20 142424"
src="https://github.com/user-attachments/assets/cb05b674-ac4f-4e2f-8f17-9d8654f099ff"
/>
<img width="450" height="102" alt="image"
src="https://github.com/user-attachments/assets/aa6e51b5-a325-4e8c-baf8-21134843fbf2"
/>
Replace /datum/gas_mixture/proc/return_pressure with XGM_PRESSURE(xgm)
macro. Having such a relatively simple statement contributing proc
overhead to procs called millions of times is ridiculous
Rename /datum/gas_mixture/proc/zburn to react, deleting the old react
which was just an alias for it. Free proc overhead
Turn check_combustibility into a macro CHECK_COMBUSTIBLE(is_cmb, xgm).
also rewrite it slightly so that it only needs to do one pass. Its a bit
nasty so I apologize for that, but speeeeed.
Delete most powernet and obj/machinery/power procs for handling power,
replacing them with macros. The fact that we were unironically calling a
draw_power() on APCs to call draw_power() on their terminals to call
draw_power() on their powernet every single process tick was insane.
Turn `between` into a macro alias for clamp() since the param order is
different
turn `Percent` into a macro AS_PCT
Rewrite significant chunks of update_canmove so its not quite as
horrifying of a proc and hopefully doesn't eat the entire mob subsystem
every movement now
# Summary
This PR updates the marshalling wands and gives them intent based
coloring. In addition, hold a second wand in your hand, the settings
will be automatically synced.
## Changes
- Update marshalling wand sprite (more the structure then the actual
sprites).
- Added color modes, updated text, added mechanical hints and two hand
sync to marshall wands.
- Added signal for mob intent changes (unused at the moment).
- Adjusted Hangar Tech round start spawn points in the breakroom.
- Added second marshalling wand to each Hangar Tech locker.
## Preview
(Note this preview has been made prior further pixel adjustments,
consider it a demo.)
# Summary
This PR decouples the eye sprite state from the robots integrated light
state.
To my understanding, disabling the eye glow wasn't primarily intended by
toggling the light and at the same time the toggle-states were flipped.
Fixes#21769
## Sprite note
No sprites were modified.
we have a gorillion hard deletions and it turns out half of them are
because we set the "ALWAYS HARD DELETE THIS" flag rather than just like.
fixing the hard delete.
cool
after ragebaiting all of coderbus with our 10 second sendmap ticks, i
have slapped together this bandaid fix which should help decrease server
load from all you nerds with 72,000 body markings
i know what you are
