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>
