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>
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>
# Summary
This PR fixes material stacks being able to drop into the negative.
Common occurrence are the synthetic fabricators.
## Changes
- Fixed new stack initialization overflow logic.
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
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>
https://www.youtube.com/watch?v=9mPvZ96pHJI
A pull request commissioned by the Synthetic Lore Team to
comprehensively rework synthetics (read: IPCs) and how they work in
Aurora. The objective is to make IPCs as unique as possible from humans,
upgrading the robotic feel and atmosphere, while also preserving a good
sense of balance in-game.
Key features:
- A comprehensive expansion of synthetic organs, all of which now
fulfill a purpose: hydraulics, cooling units, power systems, actuators,
diagnostics units.
- Customizable organs with benefits and drawbacks, such as with cooling
units and power systems.
- Unique ways to repair the organs and more involved steps.
- Unique damage mechanics - every organ has wiring and electronics which
affect its functioning, and they are defended by plating which provides
natural armour.
- Improved and immersive diagnostics.
- Unique features, benefits, and drawbacks for every IPC frame.
- A rework of the positronic brain, which can be either destroyed or
shut down, alongside effects caused by low integrity.
- A rework of how EMPs affect IPC organs.
- Non-binary damage states for each organ.
To-do:
- [x] Finish the unique features for each frame.
- [x] Look into if mechanical synthskin is possible.
- [x] Power system.
- [x] Posibrain mechanics.
- [ ] Passive cooling expansion.
- [x] EMP mechanics.
- [x] Repair mechanics.
- [x] Mob weight mechanics.
- [ ] Gurney for heavy mobs.
- [x] New augments.
- [ ] IPC tag scanning and flashing.
---------
Signed-off-by: Werner <1331699+Arrow768@users.noreply.github.com>
Co-authored-by: Matt Atlas <liermattia@gmail.com>
Co-authored-by: Geeves <22774890+Geevies@users.noreply.github.com>
Co-authored-by: Werner <1331699+Arrow768@users.noreply.github.com>
This PR includes several changes to bring our wound code up to date with
baystation, nebula, and modern standards. Highlights include:
- The usage of integers between 0 and 100 for ratios (expressed as a
percentage), instead of 0.0 to 1.0. Small decimal values are prone to
floating point precision errors, but by moving to a percentage instead,
we can reduce the impact of this.
- The untangling of damage flags and injury flags, which were used
interchangably in the code. This could have caused issues should we
expand any of these.
- Larger embedded objects now halt bleeding in wounds, until they are
pulled out. In exchange however, embedded objects will halt healing in
wounds (it is difficult to close an open wound that currently has a rod
stuck in it)
- A lot of data, such as implanted objects and organs, are now stored in
amputated limbs.
Progress on DMDocs. PRing progress so far so there's not one mega PR
later with 1500 affected files.
I want my goddamn highlight text on what all these goddamn procs goddamn
do goddamnit. >:(
No actual code change anywhere in this PR, only comments.
---------
Signed-off-by: Batrachophreno <Batrochophreno@gmail.com>
1. Look up now follows your mob (no more auto-removal when you move,
only when you go below a solid tile). Maybe add a hotkey?
2. Made the codebase work with the latest version of spacemandmm lint.
3. Advanced kits don't work on robotic limbs.
4. Density shifting should now always use set_density. Ported
TRAIT_UNDENSE from CM to better control the density of living mobs.
Fixes weird shifting behaviour with wall leaning -- what was happening
is that mob density was getting reset to TRUE because the mob wasn't
lying down.
5. TGUI say light prefs actually save.
---------
Co-authored-by: Matt Atlas <liermattia@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>
This makes nanopaste take about twice as long to apply at a baseline, 2
seconds rather than 0.7, multiplied by five times if the mob you are
applying it to is yourself, reckoning out to 10 seconds to apply it once
to yourself. This also prevents you from applying nanopaste multiple
times at once, so this time limit can't be contravened.
The intention of this is to discourage using nanopaste mid-firefight,
which has been very powerful in the past since it took less than a
second to apply and could be spammed repeatedly to speed that up even
further. I also hope that it'll encourage IPCs to ask for help to apply
nanopaste, involving other people in the repair process, or to simply
use the workshop now that nanopaste is less instantaneous.
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.
* Bandages now do not disappear as damage heals, instead, a special
Remove Bandages verb must be used to remove bandages. This cannot be
used to re-open wounds for now, and can only be used if the bandage
would've downgraded / disappeared at that point.
* Taking damage on a bandaged limb now removes the bandages.
Moved all calls of randpixel_xy in Initialize() (if they were in New())
Some tweaks of the proc
This should avoid some random CI failures due to it matching shifted
pixels as dirty vars
No player facing changes
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 all the builtin text procs to use string interpolation
instead.
Added a linting for the above.
This is based on, and should only be merged after, #19847
Refactored hitby to be in line with TG's version.
Refactored item weight defines to a more clear naming scheme, also in
line with TG's version.
Refactored how the movement bumps are handled, ported signals to handle
them, in preparation for the movement update.
Fixed disposal hit bouncing the hitting atom on the wall.
Items do not push other items anymore if they are tiny.
Refactored fire_act() to be in line with TG version, removed useless
parameter, added signal, made non sleepable and forced to call parent.
Added atom_act.dm file for the various *_act procs.
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>
* sdaf
* sdaf
* sdfa
* sadf
* sfda
* gfd
* reduce thrusters volume
* sdafsadsdaf
* sdfa
* Reduced some sound ranges and made some/more not ignore walls for loops
* health analyzers too
* ivdrip adjustment
* most tools now use play_tool_sound to have the sound played, reduced range for it
* pain
* sadfas
* sdfa
* sdfasf
* sfa
* sdf
* might the lord have mercy on our soul
* i cri everidai
* adeste fideles
* sdf
* where will this lead, what's coming next, from your inventions
* dear lord
* gjvhk
* i cri everidai
* fsgf
* sdfa
* sdaf
* hiuhi
* 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>
* tis time for nefarious deeds
* all it takes is one lattice
* francisca directions and minor tweaks
* scarab origin ooc note
* lint pls
---------
Co-authored-by: ShakyJake <jakeisnowshaken@gmail.com>
* Refactored do_after to use a flag-based system for options
* More flags
* Ditto
* Use the HAS_FLAG macro
* do_after pass
* Fix burning paper code
* Resolve issues from Fluffy's code reviews
* .
