mirror of
https://github.com/Aurorastation/Aurora.3.git
synced 2026-07-22 05:17:38 +01:00
VMSolidus
4379dd2c1b
Skills being based on "Hard Requirements" absolutely suck, and I wasn't happy with the surgery code being essentially hardcoded around them. So this PR refactors surgery to use soft requirement checks, based on modifiers to the success rate probability. Surgeries still state what skills (if any) they require and at what level, but rather than blocking the surgery, it instead imposes a penalty(or bonus) on the success chance based on how much the user's surgical skill differs from the required level. This actually stacks with the penalties for "non ideal tools", so if you're completely unskilled in surgery and you attempt to make an incision with a shard of glass, you're going to have an extremely hard time. Individual surgeries also can define how much the success rate is modified by "skill diff", with the more advanced "surgeon exclusive" surgeries having extremely large potential modifiers. I have also added a signal based check for modifiers, which the Morale component now hooks into. This can also allow for other components, implants, drugs, etc to modify the surgery chances in the future. I have manually tested this PR and verified by examining debug breakpoints in VSCode that the system correctly applies its modifiers.
Datum Component System (DCS)
Concept
Loosely adapted from /vg/. This is an entity component system for adding behaviours to datums when inheritance doesn't quite cut it. By using signals and events instead of direct inheritance, you can inject behaviours without hacky overloads. It requires a different method of thinking, but is not hard to use correctly. If a behaviour can have application across more than one thing. Make it generic, make it a component. Atom/mob/obj event? Give it a signal, and forward it's arguments with a SendSignal() call. Now every component that want's to can also know about this happening.
See this thread for an introduction to the system as a whole.