These were some of the first given feedback for skills, so I may as well
implement it.
Piloting is now split into three levels like other skills which note
what pilot class of vessel you may comfortably pilot.
(Familiar) **Shuttle Pilot** is for all landables: Spark, Canary,
Intrepid, the Quark, and the like are all equal under it.
(Trained) **Class II Pilot** covers most ships, which are "overmap-only"
and unable to land or dock.
(Professional) **Class IV Pilot** covers only the Horizon normally, but
design-wise extends to whatever is the main player ship, or for anything
massive
**Antags get Professional Pilot, so they can always do ship hijack
gimmicks without worry.**
As a convenience to make Bridge personnel stand out, Professional/Class
IV Pilots can deduce their current overmap coordinate from examining
space on help intent for 3s. There's no way to directly link to the
overmap, so on the backend, this ability briefly references an existing
ship console.
### Design
Class II and IV are pre-existing terms in-lore, used on the Interstellar
Travel page to refer to civilian size classes.
With how important each level of piloting is, they cost _+4 points_ each
instead of going 2 -> 4 -> 8. This lets there exist the occasional pilot
character from any background, but it's _always_ an investment and
piloting the Horizon stays hard without training.
As Familiar currently costs 6 points, this is effectively a 2-point buff
for most cases as you'll rarely have to pilot non-shuttles.
(**EDIT**: Piloting levels are now 4 -> 8 -> 10 so there's a bit of
flexibility to have an extra skill for Professional Pilots from
Expeditionary Trade)
#### The _**real meat**_ of this PR...
is that you can now attempt to pilot vessels a level higher than you
with penalties, so there's now a failure spectrum should you manage to
access an adjacent-class ship rather than always being hard-locked. The
penalties affect acceleration, slowing, turning, and rolling. They're
most extreme for Shuttle and Class IV to represent how clueless an
unlicensed pilot would be and how complex the Horizon realistically is
to operate.
With smart usage of autopilot, you can actually find a way to travel
normal-ish. I think this is a fun interaction to have for underskilled
characters, and makes autopilot actually have a use as it otherwise
kills you. Maybe Bridge personnel can give lessons to Class II pilots
with it.
### Piloting Education Backgrounds
Coming are THREE piloting education backgrounds: Flight Academy, Fleet
Training, and Expeditionary Trade.
#### ALL GET _Familiar Electrical Engineering,_ _Familiar Atmospheric_
(EDIT: Flight Academy is now the only background that gets Familiar
Mechanical Engineering, this makes them stand out as being notably
handy/utility-ready for emergencies, but other backgrounds can still
easily match them with points.
Fleet Training has Tenacity down to Trained for character variety,
though tenacity is very slight buffs and hard to notice.
Expeditionary Trade now uses Familiar Firearms over Familiar Armed
Combat as it's more immediately important.)
Electrical Engineering now lets you use a power cell on an unpowered
ship console to give it emergency battery life based on the charge. This
helps with cases of being stranded from an APC broken by a meteor, a
high-capacity cell can give 10m or more based on Electrical level. I may
expand this bypass mechanic to all consoles in the future.
Atmospherics skill has no implementation currently, but dealing with
breaches or cycling on shuttles is too important.
Flight Academy - BC, XO, Captain
*Professional Piloting, Trained Leadership, Familiar Mechanical
Engineering*
> "You are at least 25 years of age, with the best navigation training
the Spur can offer, vessel handiness in a pinch, and the know-how for
reining in or assuring passengers for the voyage."
Flight Academy has Leadership honestly just because I didn't want Fleet
Training to look too good, and because I think they can rock the "this
is your pilot speaking" in a cool way. Bridge personnel are usually the
ones that have to wraggle people on away sites, especially during
events.
Mechanical Engineering allows them to make machine frames of ship
consoles in emergencies.
Fleet Training - BC, XO, Captain
*Professional Piloting, Trained Firearms, Trained Tenacity*
> "You are at least 25 years of age, with the most extensive navigation
training possible and military discipline to back it up. You're a steady
shot in emergencies and, damn it-- You. Go. Down. With. The. Ship."
This was made because a player informed me many BC and XOs choose
military backgrounds, and the +4 points design would prevent that. Fleet
Training isn't the same as Military Training, but having all of Piloting
gives you 6 points free to match MT if wanted. The high Tenacity is
primarily for surviving in ship combat, where you'll probably
bleed/suffocate to death.
Expeditionary Trade - Miners, Xenology roles, OM, RD
*Familiar Piloting, Familiar Firearms, Familiar Medicine*
> "You've developed trade skills for a career of expeditions. You are at
home in a shuttle piloting to and from for an average day's work. You
can even hit a shot or tend to wounds when things eventually get
unsafe."
This is for Miner and Xenoarch primarily. An expedition is just any
journey with an objective, all roles revolving around piloting shuttles
to an objective needs to be able to hold their own if they ever find
carp or have an accident, especially since they'll likely be alone.
#### MISC stuff
corrected shaper gear comments I left wrong
Hotwiring piloting consoles now checks for Familiar in Electrical
Engineering. Its visible emote also now looks identical to attempting an
emergency bypass at first glance, so you can sneakily attempt one with
an unpowered console.
The Doctor of Psychology education background now gives Trained in
Leadership. This was intended to be uncommented, but the person forgot
to do it.
Research Directors now need to have Familiar/Shuttle Pilot. According to
the Guide to Piloting wikipage, they're supposed to be able to fly the
Intrepid and Quark for expeditions, and likely mirroring how the OM can
fly the Spark, but an RD can spawn completely incapable of piloting
currently.
---------
Signed-off-by: runecap <43975590+runecap@users.noreply.github.com>
Co-authored-by: VMSolidus <evilexecutive@gmail.com>
This PR adds a set_machine call to the base ship computer's attack_ai
procs, allowing AIs and borgs to view the overmap without their view
immediately being reset by the next life() call.
Fixes#22467
Re-creation of https://github.com/Aurorastation/Aurora.3/pull/21046 to
skip merge conflict hell. Brings us modern TGUI.
**ALTERNATE TITLE: TGUI HELLSCAPE PR
ABANDON ALL HOPE YE WHO ENTER HERE**
- [x] Migrate build tools (javascript -> typescript, bun for package
management).
- [x] Upgrade all TGUI dependencies and associated root files to
TG-congruent versions (axios, babel, dompurify, eslint, highlight,
marked, prettier, sass, source-map, stacktrace-parser, typescript).
- [x] InfernoJS -> React migrations
- [x] React cleanup and polish (migrate all remaining .js files to
appropriate .ts or .tsx filetype, all remaining hooks, linting, error
corrections, etc.)
- [ ] Test all remaining TGUI interfaces
No longer does the SCC see fit that their AI must be restricted by silly
'safety' regulations, this PR does away with restrictions around robots
piloting the helm console allowing them to drive ships where they need
to go in emergencies or low pop situations.
Clean variant from https://github.com/Aurorastation/Aurora.3/pull/22142
---------
Signed-off-by: ArbiterAmbrose <n22don2009@gmail.com>
Co-authored-by: Batrachophreno <Batrochophreno@gmail.com>
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.
```
- refactor: "Updates the Computer Fabricator to TGUI"
- refactor: "Updates the Instruments to TGUI"
- refactor: "Updates the Geo Scanner to TGUI"
- refactor: "Updates the Stacking Machine to TGUI"
- refactor: "Updates the Robotics Console to TGUI"
- refactor: "Updates the Requests Console to TGUI"
- refactor: "Updates the Synthesizer/Instrument main panel to TGUI"
- refactor: "Updates the Nuclear Bomb control panel to TGUI"
- rscadd: "Requests Console messages are now typed (Assistance Request, Supply Request, Information, Reply); the type is shown in the recipient's log, audible alert, and PDA notification."
- rscadd: "Reconstructs the Synthesizer's Virtual Environment Editor (was broken since added — its NanoUI template never existed). The Custom environment preset that depends on it is gated behind a new musical_config.can_use_custom flag (default off, matching prior behavior)."
- bugfix: "Fixes the Autolathe UI re-opening after every print job."
- bugfix: "Fixes the Song Editor's currently-playing line indicator not advancing during playback."
- bugfix: "Fixes a class of bugs where TGUI windows for the Air Alarm, Portable Turret, Mining Vendor, Mineral Processor, Tank Dispenser, Helm Console, all Chemistry machines, and Suit Cycler would force themselves back open after every action, even when the player had closed them."
- bugfix: "Fixes the spatial sound system silently dropping every sound that used the 'None' (-1) environment id or a 23-element custom environment list. The validator was rejecting both as invalid, so synthesizer notes played with Custom or None mode produced no audible output at all."
- admin: "Adds two requests consoles and two fax machines to the bridge on the runtime test map."
```
Claude Opus 4.7 has been used during the creation of this PR
---------
Signed-off-by: Arrow768 <1331699+Arrow768@users.noreply.github.com>
Co-authored-by: Werner <Arrow768@users.noreply.github.com>
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
Co-authored-by: Batrachophreno <Batrochophreno@gmail.com>
Makes Navigation Consoles (the ones scattered around the public spaces
of the Horizon that only let you view the nearby starmap) able to be
viewed again without having piloting skills.
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>
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
Many, many, many items have inhand sprites in their .dmis but for
whatever reasons do not display them in-game. This PR:
1. Updates many item definitions to point to their already-existing
inhands correctly. This consists largely of held tools, but also gas
tanks and jetpacks mounted in the suit storage slot.
2. Adds a few codersprites made by me for objects with either missing
inhands or poorly matching mishands (IE, the tape recorder, which has a
black case, reused the white inhand sprites of the health analyzer). The
new sprites are modified or recolored variations of other inhand sprites
from our repo, except for circuitboards which are new.
<img width="444" height="400" alt="image"
src="https://github.com/user-attachments/assets/7f107b9a-fe24-4e31-8f16-4d34768ee117"
/>
3. Adds inhand sprites for Inflatables and Inflatable Boxes made by
Tomixcomics.
<img width="424" height="101" alt="image"
src="https://github.com/user-attachments/assets/434107c4-8577-49a2-a58e-d6b014c03933"
/>
4. Ports inhand sprites for the Hydraulic Rescue Tool from tg's Jaws of
Life.
<img width="224" height="94" alt="Screenshot 2026-02-07 172931"
src="https://github.com/user-attachments/assets/070c7956-f6a8-4fb5-870f-10c64afcc8b3"
/>
5. Some additional cleanup while in the area. The 'analyzer' has been
renamed the 'gas analyzer' to be consistent with the other analyzer
objects, standardized icon_state naming conventions where I saw
oddballs, updated code docs to use DMDocs when in the area, etc.
### Asset Licenses
The following assets that **have not** been created by myself are
included in this PR:
| Path | Original Author | License |
| --- | --- | --- |
| icons/obj/item/hydraulic_rescue_tool.dmi | [SomeAngryMiner (bee
station)](https://github.com/BeeStation/BeeStation-Hornet/pull/2487),
[maxymax
(/tg/station)](https://github.com/tgstation/tgstation/pull/58616) |
CC-BY-SA |
| icons/obj/item/inflatables.dmi |
[Tomixcomics](https://github.com/tomixcomics) | CC-BY-SA |
For a robust crafting system, I need a new materials framework.
For a new materials framework, I need to clean up reagents.
To clean up reagents, I need to pare down foods from reagent holders.
To pare down foods from reagent holders, I need to port edibility
components.
To port edibility components, I need to port processing components.
To port processing components, I need to port tool behaviors.
This is all back-end code, no new features or functionality from this.
V2 of [previous music playing
PR](https://github.com/Aurorastation/Aurora.3/pull/21466). TLDR no
longer uses the connect_range component for implementation because it
turned out a bit too inflexible for overlapping music players.
Removes a NanoUI template for the [TGUI
update](https://github.com/Aurorastation/Aurora.3/pull/21046).
New changelog:
- refactor: "Ported Jukebox's NanoUI interface to TGUI."
- refactor: "Ported Jukebox audio playing functionality to a component."
- refactor: "Sound keys refactored from singletons to datums, along with
larger breakout of sound.dm to allow for easier SFX updates in future."
- code_imp: "Expanded track datums to include track lengths."
- code_imp: "Reorganized music file folders for more intuitive access."
- rscadd: "Earphone status feedback text now includes track length."
- rscadd: "Added autoplay functionality to earphones."
- bugfix: "Fixed earphones' 'Previous Song' verb not sending you to the
end of the playlist when used while the first track is selected."
- bugfix: "Fixed gain adjustment for 'Konyang-1' (-23 dB -> standard
-9.8 dB)."
- bugfix: "Fixed y-offset of audioconsole-running overlay animation to
line up with the actual screen."
---------
Co-authored-by: VMSolidus <evilexecutive@gmail.com>
Extends and reworks how various extended information text (desc_info,
desc_build, desc_upgrades) are handled to make object interactions and
mechanics A.) much more clearly documented in-game and B.) much easier
to support from the back-end.
Almost certainly a candidate for test merge.
Assembly/Disassembly instructions are noticeably sporadic, largely due
to our current lack of a unified framework. That's a future thing I'd
like to attack so that it can be handled programmatically, but for now I
only targeted the biggest culprits as I came across them.
---------
Signed-off-by: Batrachophreno <Batrochophreno@gmail.com>
Bugfixes- changes weren't committed in original PR :(
This PR makes component upgrade text viewable in all circumstances,
restores component detection text to RPED, and excludes ship sensors
from updating their power draws based on components (they all use a huge
number of stock components compared to most machines, so their power
draws turned whack. They can be tuned later.)
---------
Signed-off-by: Batrachophreno <Batrochophreno@gmail.com>
Co-authored-by: SleepyGemmy <99297919+SleepyGemmy@users.noreply.github.com>
Turned a ton of unmanaged globals into managed globals.
Refactored some UT output.
Removed some unused things, including vars.
Added a test to ensure people don't keep adding new unmanaged vars.
Ship consoles such as targeting and sensors now check for access.
Emagging a ship console disables access checks
Horizon shuttles given access requirements (bridge crew can access any
ship)
Went through most offships and added access requirements, likely missed
some however.
For access requirements, I only added them for helm control, targetting,
and shuttle control consoles
---------
Signed-off-by: Ben <91219575+Ben10083@users.noreply.github.com>
Co-authored-by: Ben10083 <Ben10083@users.noreply.github.com>
Co-authored-by: Fluffy <65877598+FluffyGhoster@users.noreply.github.com>
Runtime map now has a bunch of new areas / items with often-tested
stuffs, and some hard-to-put-at-runtime stuffs.
Runtime map jobs now are positioned to make it faster to reach the
aforementioned often-tested stuffs.
Runtime map doesn't generate an overmap anymore by default, which speeds
up the process.
Runtime map now loads in ~11 seconds instead of ~40 seconds as it was
before.
Updated the maploader to be faster in parsing maps.
Bapi is not engaged anymore if we're only measuring the map size, which
speeds up the process.
In fastboot we do not generate the codexes anymore, which speeds up the
process.
In fastboot and if exoplanets and away sites are not enabled, we do not
parse the map templates anymore, which speeds up the process.
Updated the icon smoothing to be faster.
Optimized cargo area code.
Other optimizations.
Refactored the attack proc signature.
Added signals and components for the attack proc.
Added signals and components for the attackby proc.
Adjusted some leftover attackby procs signatures.
Added grep test to ensure people don't keep adding attack/attackby procs
with the wrong signature.
Refactored the projectile code, mostly in line with TG's now.
Refactored various procs that are used or depends on it.
Projectiles can now ricochet if enabled to.
Damage falloffs with distance.
Homing projectiles can now have accuracy falloff with distance.
Projectiles have a maximum range.
Muzzle flash is configurable per projectile.
Impact effect of the projectile is configurable per projectile.
Accuracy decreases with distance.
Projectiles work with signals and emits them, for easy hooking up from
other parts of the code.
Meatshielding is now less effective .
Impact sound is now configurable per projectile.
High risk.
Made relaymoves uniform in function header and non sleepable.
Improved IPC/borg recharger, made it time constant.
Tweaked client/Move() to avoid a range(), moved a relaymove around to
fix a bug, some minor tweaks.
Fixed IPC/borg recharge station not taking the IPC/Borg in on bump.
Fixed certain bugs on the sensor relay as well as tidied up and moved a
few things around.
Also added a generic version of the sensor relay's large sensor suite,
for use by other away sites/ships. See IDB for the sprite.
CL:
- bugfix: Fixed the sensor relay away site having locked airlocks and
undeconstructable windows, alongside other misc changes.
- rscadd: Performed other various map tweaks and cleanup to the sensor
relay.
- imageadd: Added a generic variant of the sensor relay's sensor suite,
intended for other away sites. Replaced the sensor relay's Solarian
paintjob into its own variant.
Refactored the machinery operable procs into a single one, DMDoc'd, SDMM
marked, made more readable.
Fixed suspension field generator not being able to be used as it was not
checking the power cell for operability.
Fixes#19249
A significant amount of influence was taken from
https://github.com/Baystation12/Baystation12/pull/33255, however adapted
to Aurora. Key things to note is the port of the newer alpha settings
from /tg/, among other improvements.
The ancient holographic and screen overlay code has been purged. This is
now handled with emissives, while holograms are handled with filters as
well.
---------
Co-authored-by: Cody Brittain <cbrittain10@live.com>
Flips the sensor and landing control sprites for the canary consoles so
they'd fit on the opposite sides, swaps the pipes around for the fuel to
thrusters, to accomodate moving the pump for the fuel can inside, and
shifts the sensors and engine control consoles around so the WSO has the
Sensors and gun, and the pilot has the engines, landing control, and
helm.
Requested by Firstact.
Our SSOverlays system is outdated, and is likely the cause of many of
the issues seen in #18895. It has also been linked to a massive server
performance decrease.
This brings an updated system from Baystation, hopefully with speed
increases.
Should be testmerged, ideally with #18895.
---------
Co-authored-by: Cody Brittain <cbrittain10@live.com>
Sensors, IFF beacons, and thrusters can now be built with circuit
boards.
Ship sensors consoles will no longer throw an error if their sensors are
deleted or destroyed.
Thrusters and other unary atmos machines now take their initial dir from
the machine frame like other machines rather than requiring modification
of the circuit board item.
Unified most of the procs into one definition, so there are no duplicate
around the codebase.
Marked some of the above as overridable if a good enough case can be
made for them (eg. external dependency or unlikely to be used).
-fixes the hailstorm shuttle not docking
-fixes the hailstorm pipes not connecting to the vents
-added primitive versions for the ship computers using sprites we had
but were never implemented
This is part 1 of a project to, eventually, bring the render planes
system from /tg/ and bay into Aurora. This is a prerequisite and blocker
for many things the development team and community want to have, and
this was long overdue.
Many objects have been re-assigned layers, which are now thoroughly
defined. Maps have had their custom layer defines purged, as we should
be moving away from this in favor of saner definitions in the base
items.
This should be a test-merge due to the sheer amount of layers changed,
which will very likely create issues that I cannot possibly discover and
debug in a reasonable amount of time myself.
---------
Co-authored-by: Cody Brittain <cbrittain10@live.com>
* SSatlas.current_map
* hardsuit spell tab appears to clear correctly
* sdfsa
* from the moment i understood the weakness of my flesh, it disgusted me
* sdf
* SDQL2 update
* fix that verb
* cl
* fix that
* toworld
* this is pointless
* update info
* siiiiick..
* vv edit update
* fix that
* fix editing vars
* fix VV
* Port the /TG/ globals controller.
* part 1
* part 2
* oops
* part 3
* Hollow Purple
* sadas
* bsbsdb
* muda na agaki ta
* ids 1-15
* 16-31
* 41-75
* bring me back to how things used to be before i lost it all
* the strength of mayhem
* final touches
* cl
* protect some vars
* update sdql2 to use glob
* stuff?
* forgot that is not defined there
* whoops
* observ
* but it never gets better
* a
---------
Co-authored-by: Matt Atlas <liermattia@gmail.com>
runecap