<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
## About The Pull Request
title
## Changelog
🆑
fix: world_topic status host is correct now
code: updated progressbar
code: updated stack trace
code: updated callback
code: updated weakref
code: updated topic request, now supports returning json format
code: datum browser doesnt hold atom owner directly
code: updated stat tracking (debugging, not player stat)
admin: updated del-all verbs
admin: allow f12 browser inspect (516 only)
/🆑
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
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!)
* shit code goes in the comedy bin
* stubs
* move those
* w
* vehicle repath
* maybe that instead
* aouhgoawhuh3ho
* markers
* a
* fixes
* hell
* let the great refactoring begin
* a
* aouhg
* changes
* augh
* signals
* s
* offhand stuff
* wrappers
* stuff
* modifications
* a
* stuff
* base component
* Stuff
* a
* stuff
* ay
* Ay
* ?
* fix
* a
* augh
* aough
* mark those
* sigh
* correction
* that
* let the good times roll
* more
* more
* on god
* aoihgouh
* fixes
* done with that ifle
* sigh
* a
* s
* fuck off voremobs
* stuff
* pain
* some more
* changes
* changes
* f/r
* sigh
* impl
* out with the useless
* fix
* Fixes
* a
* fixes
* move that
* pain
* fix
* m
* pain
* WHY
* regex
* s
* just offsets to go
* reserve those words
* that
* stuff
* stuff
* not sure if list ops were a good ide abut whatever
* fix
* and once more with energy!
* and once more with energy!
* fixes
* offsets
* fix
* lmao!
* ay
* patch
* fixes
* propagate that shit through
* ayo
* bruh?
* e
* PLEASE END MY SUFFERING
* ah.
* that
* fix
* fix
* fixes
* e
* Fix
* fix
* fix
* Fix
* fix
* fix
Co-authored-by: VM_USER <VM_USER>
