12 Commits
Author SHA1 Message Date
7e8cd3f5ac refactors combat backend & adds kinetic gauntlets (#7144)
Co-authored-by: Zandario <zandarioh@gmail.com>
2025-05-31 19:30:25 +02:00
siliconsandGitHub b497e19b83 minor changes from melee refactor branch (#7127)
removes dead code, fixes descriptions, adds examine event struct, and
adds fmttext()
2025-04-30 10:14:25 +02:00
siliconsandGitHub 6959c31a55 wield update (#7116) 2025-04-29 18:05:51 +02:00
siliconsandGitHub 4137b01947 guncode update (and misc refactors) (#6740) 2025-02-22 16:31:23 +01:00
9885763e3d hand refactor (#5677)
Co-authored-by: silicons <no@you.cat>
2024-11-20 09:25:57 +01:00
siliconsandGitHub 7678e98fa0 nt expeditionary weapons (#6682) 2024-10-14 16:32:21 +02:00
siliconsandGitHub 2533caefd9 combat code overhaul + projectiles v8: impact handling (#6579) 2024-09-02 20:34:27 +02:00
siliconsandGitHub 4155eecdac Completely changes how DCS types works (#5911)
DCS now registers based on its registered type, as opposed to at every
subtype.
Dupe mode is no longer considered realistically usable unless
if-and-only-if all var pre-setting behavior is considered - which is not
the case on the majority of citrp-made components outside of
/datum/component/radioactive

## Why?

Components are a generic way to attach datums to things.
The common practices included:
- No getcomponent
- Use signals for all interaction
- Don't subtype, set vars on initialization

This resulted in components, while being quite stable, being also quite
rigid, in my opinion. Given we don't use components for the same things,
and probably never will, I think it's better for us to get the
optimizations from not supporting what's honestly behavior that we
shouldn't rely on in the first place - if something needs to be applied
multiple times (e.g. radiation) it should rely on the old behavior and
this new system still allows it. If it doesn't, the author should either
not be adding the component multiple times, or **making** their
component functional under this system. InheritComponent still has all
the tools necessary to properly do component inheritance, it's just now
we default to all components only being considered the same if it's the
exact subtype - which from what I could see, is also the previous case
(as if you add a subtype, uh, bad shit's going to happen if the base
type is registered but not the subtype anyways!)
2023-08-25 22:49:52 -07:00
93de2c0872 Revert "Revert "fixes noncompliance with 514 procpaths"" (#5781)
Co-authored-by: silicons <no@you.cat>
2023-07-27 20:49:36 +02:00
LordMEandGitHub 9b128134df Revert "fixes noncompliance with 514 procpaths" (#5780)
Reverts Citadel-Station-13/Citadel-Station-13-RP#5779
2023-07-24 21:50:50 +01:00
58f4094413 fixes noncompliance with 514 procpaths (#5779)
turns out the old way of doing procpaths is illegal now

this should fix some weird potential (?) bugs

---------

Co-authored-by: silicons <no@you.cat>
2023-07-24 21:26:17 +01:00
siliconsGitHubVM_USER <VM_USER>
0f5030afa0 adds multihand wielding component (#4829)
Co-authored-by: VM_USER <VM_USER>
2022-12-16 20:12:03 -06:00