10 Commits
Author SHA1 Message Date
siliconsandGitHub 6144b87b9a [IDB IGNORE] [MDB IGNORE] orbital support update 1 / 3 (#7361) 2026-01-20 14:46:22 +01:00
siliconsandGitHub 50fcf32571 comment pixel offset stuff a bit more, removes unnecessary get standard offsets (#7475)
:)
2026-01-12 18:05:37 +00:00
b1029a24f8 Power Cell Rework + Energy Weapon Rebalance (& misc changes) (#7438)
- all cells in the game are now small, medium, large
- super, hyper capacity cells, device, and weapon cells are all removed
- cells now have standardized variants, some of which are printable by
R&D
- energy weapons rebalanced
- **advanced energy guns and stun revolvers removed** - use the new
modular weapon system and microfission cells.

---------

Co-authored-by: silicons <silicons@silicons.dev>
2025-12-24 12:15:01 +01:00
siliconsandGitHub 60db51850c experimental gc / init fixes and optimizations, and fixes emotes (#7431) 2025-12-15 09:13:19 +01:00
siliconsandGitHub 1e309efd39 adds status emoji flicking (#7320)
tl;dr you can make stuff like the beserk icon come on at will for your
character.
2025-10-04 20:35:59 +02:00
siliconsandGitHub 2533caefd9 combat code overhaul + projectiles v8: impact handling (#6579) 2024-09-02 20:34:27 +02:00
siliconsandGitHub 7b5c263ae5 fast turf reservation lookups & aligned spatial grid lookups (#6532)
# why?

non-player facing

we're going to need fast lookups for "is this thing in range of this
other thing" at some point, for things like telecomms

this current solution consumes about 16KB per reservation level

we also add the capability to use spatial grids to quickly get atoms on
a level.
spatial grids are also at 16KB per grid, per world level

all in all worth it in my opinion.
2024-06-20 17:26:53 -06:00
siliconsandGitHub efc6e6111a Spatial Grids (#6521) 2024-06-19 19:24:46 +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
4f76022369 fishing port from tgstation (#5360)
Co-authored-by: silicons <no@you.cat>
2023-04-16 16:16:51 +02:00