## About The Pull Request
Stumbled upon this by accident. If you add a trait that **should**
prevent engraving from a source other than INNATE_TRAIT you'd probably
want it to actually work. This doesn't actually do anything at the
moment but could save someone a few hours in the future.
## Changelog
🆑
code: Non-innate engraving blockers should work now (none as of now)
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
Paradox clones spawn with a "quick copy" of their target's memories.
These are notably limited in that they can't be used for stories
(engraving or tattoos), but if people metagame Paradox clones by saying
"engrave something for me" there's no hope for this community
Closes#73931
## Why It's Good For The Game
Stops a meta-y exploit
## Changelog
🆑 Melbert
fix: Paradox Clones now know that their target knows.
/🆑
## About The Pull Request
So, a huge issue with memories and - what I personally believe is the
reason why not many have been added since their inception is - they're
very annoying to add!
Normally, adding subtypes of stuff like traumas or hallucinations are as
easy as doing just that, adding a subtype.
But memories used this factory argument passing method combined with
holding all their strings in a JSON file which made it just frustrating
to add, debug, or just mess with.
It also made it much harder to organize new memories keep it clean for
stuff like downstreams.
So I refactored it. Memories are now handled on a subtype by subtype
basis, instead of all memories being a `/datum/memory`.
Any variety of arguments can be passed into memories like addcomponent
(KWARGS) so each subtype can have their own `new` parameters.
This makes it much much easier to add a new memory. All you need to do
is make your subtype and add it somewhere. Don't need to mess with jsons
or defines or anything.
To demonstrate this, I added a few memories. Some existing memories had
their story values tweak to compensate.
## Why It's Good For The Game
Makes it way simpler to add new memories. Maybe we'll get some more fun
ones now?
## Changelog
🆑 Melbert
add: Roundstart captains will now memorize the code to the spare ID
safe.
add: Traitors will now memorize the location and code to their uplink.
add: Heads of staff winning a revolution will now get a memory of their
success.
add: Heads of staff and head revolutionaries who lose their respective
sides of the revolution also get a memory of their failure.
add: Completing a ritual of knowledge as a heretic grants you a quality
memory.
add: Successfully defusing a bomb now grants you a cool memory. Failing
it will also grant you a memory, though you will likely not be alive to
see it.
add: Planting bombs now increase their memory quality depending on how
cool the bomb is.
refactor: Memories have been refactored to be much easier to add.
/🆑
Makes the code compatible with 515.1594+
Few simple changes and one very painful one.
Let's start with the easy:
* puts call behind `LIBCALL` define, so call_ext is properly used in 515
* Adds `NAMEOF_STATIC(_,X)` macro for nameof in static definitions since
src is now invalid there.
* Fixes tgui and devserver. From 515 onward the tmp3333{procid} cache
directory is not appened to base path in browser controls so we don't
check for it in base js and put the dev server dummy window file in
actual directory not the byond root.
* Renames the few things that had /final/ in typepath to ultimate since
final is a new keyword
And the very painful change:
`.proc/whatever` format is no longer valid, so we're replacing it with
new nameof() function. All this wrapped in three new macros.
`PROC_REF(X)`,`TYPE_PROC_REF(TYPE,X)`,`GLOBAL_PROC_REF(X)`. Global is
not actually necessary but if we get nameof that does not allow globals
it would be nice validation.
This is pretty unwieldy but there's no real alternative.
If you notice anything weird in the commits let me know because majority
was done with regex replace.
@tgstation/commit-access Since the .proc/stuff is pretty big change.
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
ELEMENT_DETACH is **not** a requirement to having `Detach` called.
Detach is always called when the element itself is destroyed.
ELEMENT_DETACH is a flag that when set, makes sure Detach is called when
the atom destroys.
Sometimes you want this, for instance:
```dm
/datum/element/point_of_interest/Detach(datum/target)
SSpoints_of_interest.on_poi_element_removed(target)
return ..()
```
This Detach cleans up a reference that would have hung if target was
destroyed without this being called.
However, most uses of Detach are cleaning up signals. Signals are
automatically cleaned up when something is destroyed. You do not need
ELEMENT_DETACH in this case, and it slows down init. This also includes
somewhat more complex stuff, like removing overlays on the source
object. It's getting deleted anyway, you don't care!
I have removed all uses of ELEMENT_DETACH that seemed superfluous. I
have also renamed it to `ELEMENT_DETACH_ON_HOST_DESTROY` to make its
purpose more clear, as me and a lot of other maintainers misunderstood
what it did,
---
An update to this, ELEMENT_DETACH *is* needed for anything that can
register to a turf, as turfs do not clear their signals on destroy.
