So one of the most important 'features' of the Skills System is that
Skills are supposed to have a fairly interconnected web of **Opportunity
Costs** against each other. EG: Points spent in Surgery are points not
spent in Xenobiology and vice versa.
A significant problem with this however is that from the start we were
very wishy-washy about having skills actually tell the players what they
do, and were intentionally refraining from telling the players the
actual numbers behind them. This creates a few major problems:
1. It creates a knowledge difference between players who can code-dive
to find out what the skills do, and those who can't, effectively turning
skills into the same problem as "Secret Chem Recipes".
2. It prevents players from making informed decisions about how they
build their characters.
3. It turns out players are extremely unlikely to put points into a
skill if they don't know what it does.
4. It sabotages the "Opportunity Cost" factor of skills. If a player
doesn't know that Xenobiology for instance has some niche uses for their
role, they won't ever consider taking it over something more 'useful'
like Surgery.
There is also a side issue that players generally tend to overwhelmingly
despise skills that are 'reverse ordered', giving them penalties if they
don't buy the skill. They feel like this punishes them for not picking
something. In the case of Firearms/Unarmed/Armed my hands are tied right
now because of how the combat system is (not) balanced. But I can at
least fix that for the Mech piloting skill with some clever small tweaks
to the math. Players currently strongly don't like the new mech movement
because the non-forward directions tend to be too punishing. So I'm
tweaking the Pilot: Mechs math to be more player-friendly by actually
improving the handling experience of mechs.
The bulk of this PR is of course making as many skills as possible fully
transparent about what they do. Wherever possible, Skills now openly
state what they modify, and by how much at a given rank.
<img width="1270" height="982" alt="image"
src="https://github.com/user-attachments/assets/9619f2fa-8dd6-4021-8482-43a1f76f33f4"
/>
This PR adds new Cross-Skill Interactions for both Cooking and
Xenobiology, the latter of which now provides a new Situational Skill
Modifier.
Cooking Skill now causes animals butchered by the character to drop
additional meat. A pretty simple small interaction that doesn't change
much in the grand scheme of things.
Xenobiology has gained two new interactions, aimed at making it a skill
"potentially useful" for players who think their character might be
fighting Space Fauna. The first is that it provides a melee damage
modifier (which can offset the penalties from low melee skill), but only
when attacking Space Fauna (that aren't player controlled). Normally
direct damage modifiers are very hard to balance as a consequence of
brainmed, but since this applies exclusively to a PVE interaction, the
balance concerns are significantly lessened. Its second new interaction
is to situationally modify the amount of butchering products gained from
Space Fauna (and only Space Fauna).
Particularly in the case of Xenobiology, this helps position the skill
in such a way that it provides Opportunity Cost for characters in
Cooking, Mining, and Security (to a much lesser extent, given they
almost never engage carp in melee). If points spent in Xenobiology helps
a miner fight off space fauna, then points spent in Surgery are not
points they're spending on being better at fighting carp. Almost all of
the skills in general should have care put into making sure that they
can provide viable Opportunity Cost against other skills in their same
category. Cross-Skill Interactions like this are an incredibly effective
method of doing so.
---------
Signed-off-by: VMSolidus <evilexecutive@gmail.com>
This PR "gently refactors" surgery doafter timers to be deterministic
and variable. Instead of being simply a random number of seconds between
an upper and lower bounds, surgeries now have a base amount of time they
take to perform (in fractional seconds). This doafter time can then be
modified via signal interactions, such as coming from components.
The Morale component, Surgery skill, Anatomy skill, and Xenobiology
skill all have had signal hooks for surgery speed added, while the
latter two are uniquely conditional signal modifiers. Anatomy only
provides its modifier if the target's species matches your own, while
Xenobiology only applies its modifier if the target is an alien. Morale
can situationally either give a bonus or a penalty depending on your
current amount of morale points.
So to offset that this is now significantly more variable and that 4
different sources of bonus surgical speed exist, I've actually made the
base surgery times always on the upper end of what their previous
doafter duration range was, so surgeries are in general slower if you
aren't taking advantage of specializing in it.
Signed-off-by: VMSolidus <evilexecutive@gmail.com>
This PR fixes a bunch of skills related bugs, the biggest of which were
the result of the system being overly trusting of the database, when in
reality due to a bunch of unpredictable edge cases, the database is not
guaranteed to always have what I think it has. To fix these bugs, I've
had to slightly refactor how skills are generated on player characters
and antagonists, such that the burden of proof for skills is with the
Skills Subsystem rather than the Database.
Skills generated for a fresh character that has NO preferences saved
(Worst case scenario):
<img width="1491" height="849" alt="image"
src="https://github.com/user-attachments/assets/683fb538-106a-4679-8e2a-30dd45f456a1"
/>
Promoting that same character to Antagonist now increases certain skills
to a minimum baseline:
<img width="1315" height="830" alt="image"
src="https://github.com/user-attachments/assets/94bcc69e-cbbe-45fa-956e-f53b7f5d2779"
/>
By Mel's request, Bluespace Technicians spawn with all skills fully
maxed out for debugging purposes:
<img width="1909" height="985" alt="image"
src="https://github.com/user-attachments/assets/db4f3f65-3d87-47fc-907e-c68eae6d4cdb"
/>
**Modular laser changes**
- tl:dr Shooting mod laser at a mob counts up an improvement potential
variable, which when the gun is disassembled, gets spread across the
components.
- When the components are repaired, by someone with high skill, there is
a chance to increase a variable, such as damage, shot count, accuracy.
- Players give the biggest increase, followed by non-player humans
(protohumans & mechs fall in this catagory), then simple mobs and
finally monkeys. Non combat modlasers improve slowly when used for their
intended task (betarays slowly tick up when shooting hydroponics bays)
The philosophy for these changes is that research should continue to be
involved with the equipment they give out.
It should also be difficult (but not impossible) for research to upgrade
their weapons without support from other departments.
Xenobio slimes, protohumans, medical help to keep the protohuman alive
while you shoot it, security help to actually use the guns on real
targets (this gives the biggest increases).
The more powerful a weapon is the harder it is to upgrade, as it'll kill
it's targets quicker. The more upgraded a weapon is the more difficult
it is to upgrade further, improvement potential will get wasted on
components that have already hit their cap.
On their own, by the time the 5 monkeys research start with are dead,
it's possible for a max skill scientist to improve one gun's worth of
components by ~25%.
The weapons research can now make at roundstart (with max tech) are
significantly worse than what spawns in the armoury.
The weapons research can make with gold, silver, uranium and phoron are
equal to what spawns in the armoury.
The weapons research can make with diamonds are better than what spawns
in the armoury.
Major nerfs to heat vents, auxiliary capacitor and capacitor overcharge,
these were the problem children.
It is now impossible to make a weapon that does not take damage through
use. Safe designs will only break with heavy use, by people who don't
bring them back to research for repairs.
Powerful designs break quickly and need repeated repairs.
Adds two side grade capacitors that can be made at roundstart (with max
tech), one higher damage and fewer shots. One lower damage and more
shots.
High skill characters get much more information when examining modular
lasers and a chance to throw the gun away before it explodes.
Adds some defines to help balance these changes:
Improvement cap (the total percent a component can increase) Currently
100%.
Increase & Decrease Cap, how much an individual variable can be
increased or decreased. Currently 2x and 0.2x.
Improvement multiplier, multiplies all improvement gains. Currently 1x.
**Firing Pin fixes & changes**
Fixed ID locked firing pins and adds them to R&D.
Adds the inner research department to the firing range locked pins. This
is so xenobotanists, xenobiologists & xenoarchs can use the modular
lasers. Freeze rays for slimes, betarays for xenobotanists, laser
activation for artifacts for xenoarch.
It is still impossible for a scientist to make a weapon they can use
anywhere, but they can give them to security who can use them freely.
**Misc bug fixes**
The weapon analyzer UI now updates and only shows relevant statistics,
instead of displaying every variable even when they do nothing.
Replaces the buggy tesla zap with just electrocuting the holder.
Fixes a few broken visual messages.
Fixes the vermin modulator not killing anything, now it also works on
grems.
Fixes click delay on malfunction.
Fixes radiation damage numbers.
Fixes the temperature modulator.
Fixes the report printout showing the wrong numbers.
---------
Co-authored-by: Copilot <copilot@github.com>
This PR extends the functionality of the Morale Component to also
provide a UI element. Which is dynamically controlled by the component.
Players can click on it to view their current morale modifiers, and what
percentage effect said modifiers are currently providing. Morale is not
actually new, the mechanic has been on the server for over a month now,
though the players had no way of knowing it was there unless they
closely follow along with the github history.
I have extensively tested this over the course of 6 hours of work, and
have attached video proof of said testing.
https://github.com/user-attachments/assets/c0d3ca3a-0a52-46e1-8e46-9d1e5ef46e4f
### Asset Licenses
The following assets that **have not** been created by myself are
included in this PR:
| Path | Original Author | License |
| icons/mob/screen/morale_ui.dmi |
https://github.com/BeeStation/NSV13/commit/b6b1e2bf2cc60455851317d8e82cca8716d9dac1
| CC-BY-SA-3.0 |
This PR adds a new Combat skill largely designed for non-combat
characters called Tenacity. It's fairly analagous to traits like Will to
Live from Shadowrun. Ranks in this skill make a character take a little
bit longer to "bleed out in crit", but do nothing to actually change how
hard they are to take down in combat. Effectively this means that ranks
put in this skill give you a little bit more of a buffer of time to be
picked up by a paramedic and rescued.
For actual combat characters it's very undesireable since it does
nothing to actually help win you fights, so this skill is largely more
to serve as an option for characters outside of security who don't
actually want to spend any points on direct combat capabilities. All of
the numerical modifiers from the skill are rather small, and make use of
pre-existing signal hooks that I've made previously for Brainmed to
allow component based modifiers to organ code.
<img width="1069" height="243" alt="image"
src="https://github.com/user-attachments/assets/92d6c19a-a0f2-4cc8-b490-df4538fd2b3d"
/>
Fixes projectiles always hitting.
When a projectile rolled a 'miss', and returned Null as it's bodypart to
hit, it was being defaulted to hit the torso.
This meant that a low accuracy weapon, was not more likely to miss than
a high accuracy one.
In fact, low accuracy was a significant buff, because it made your shots
scatter to random limbs 30% of the time.
There was also no reason ever to aim for the torso, shooting the head or
hands was mechanically correct.
This is why mercs one handing the STS in burst mode were breaking so
many hands.
<img width="386" height="226" alt="image"
src="https://github.com/user-attachments/assets/a0c2992f-ca5b-41cb-84c9-c6a3f74e09d0"
/>
This is the table of the chance to hit the torso, after this fix.
Point blank shots (range 1 and 2) always hit.
Almost all lasers have 2 accuracy (when wielded, if they are 2 handed)
Almost all ballistics have 1 accuracy (likewise when wielded, if
possible)
Snipers have up to 4 accuracy. (When scoped)
Burst fire imposes an accuracy malus, the STS-35 is the heaviest malus
outside of admin spawn guns like the L6 SAW.
burst=5, burst_accuracy=list(1,0,0,-1,-1)
This means the first shot of the burst is accuracy 1, then it falls off.
If you aim for a different body part, these are the base chances to
miss:
BP_HEAD = 70,
BP_CHEST = 10,
BP_GROIN = 20,
BP_L_LEG = 40,
BP_R_LEG = 40,
BP_L_ARM = 40,
BP_R_ARM = 40,
BP_L_HAND = 60,
BP_R_HAND = 60,
BP_L_FOOT = 60,
BP_R_FOOT = 60
There is a minimum 30% chance to hit, regardless of any modifiers.
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>
VMSolidus