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
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.
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>
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.
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>
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>
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
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).
* 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