People can now pet held mothroaches and pugs if they want to, or use
items on them, hopefully without causing many issues. After all, it only
took about a couple dozen lines of code to make...
...Oh, did the 527 files changed or the 850~ lines added/removed perhaps
catch your eye? Made you wonder if I accidentally pushed the wrong
branch? or skewed something up big time? Well, nuh uh. I just happen to
be fed up with the melee attack chain still using stringized params
instead of an array/list. It was frankly revolting to see how I'd have
had to otherwise call `list2params` for what I'm trying to accomplish
here, and make this PR another tessera to the immense stupidity of our
attack chain procs calling `params2list` over and over and over instead
of just using that one call instance from `ClickOn` as an argument. It's
2025, honey, wake up!
I also tried to replace some of those single letter vars/args but there
are just way too many of them.
Improving old code. And I want to be able to pet mobroaches while
holding them too.
🆑
qol: You can now interact with held mobs in more ways beside wearing
them.
/🆑
## About The Pull Request
- pet bonus element now works by getting an emote fed into it.
- all pets who had pet bonus emotes now have it as a proper emote they
can use if controlled by a player.
## Why It's Good For The Game
- standardises pet bonus so it's easier to give more behaviors to
petting, like sounds :3
- allows basic mobs controlled by players to use the emote at will,
which will allow them to react to situations more with emotes.
## Changelog
🆑 grungussuss
add: a lot of basic mobs and pets got new emotes
refactor: emotes triggered by petting pets work differently now, please
report any oddities with these behaviors.
sound: new emotes for basic mobs got sounds
/🆑
## About The Pull Request
Partial Revert of https://github.com/tgstation/tgstation/pull/80800
Assuming every num passed in the parameters of `add_mood_effect` is a
`timeout_mod` is incorrect, because there can be mood events that take a
numeric arg which is not meant to be multiplied against the timeout.
This leads to the same issue as multiplying it with strings essentially
(in one case, shown below, this results in a negative duration of a
timer).
Plus having a keyword arg that may or may not actually be what the
keyword arg claims to be is really confusing and bad.
Instead here's what I propose: passing in an instantiated mood datum
itself, which has been modified, and copying the timeout from it before
discarding it.
It is not as clean as I'd prefer either, but at least it's logically
sound and the intent is clear, and it's the best I can think of short of
a major refactor of the entire system for this one small thing which is
only being used by food quality.
## Why It's Good For The Game
Clearer, less smelly code.
## Changelog
🆑
code: removed the timeout_mod arg from add_mood_event, which was only
used for one thing and causes more issues than it's worth
/🆑
## About The Pull Request
In a previous PR (https://github.com/tgstation/tgstation/pull/79661), I
noted that a lot of moodlets tended to have their timeouts break because
it was passing their names and whatnot as a parameter, that gets fed
into the timeout modifier parameter, causing the timeout multiplier to
break, because BYOND type-agnosticism means that it can multiply a
number (timeout_mod) by text (a name or some other object), resulting in
0 - which makes a moodlet permanent. This is probably not intended.
This fixes that in two ways:
- Adding a `1` to potentially applicable moodlets (searched for with a
regex of `.add_mood_event(.*, .*,)`) just to make sure the timeout
doesn't get multiplied out weirdly.
- Making the add_mood_event thing CRASH() if the timeout_mod is bad.
If someone else wants to come up with a solution better than this,
please do.
## Why It's Good For The Game
Maybe having your arm permanently fall asleep after getting it
reattached sucks, moodlet-wise. (Being stuck with permanent
positive/negative moodlets is probably not intended.)
## Changelog
🆑
fix: Moodlets with parameters/effects e.g. limb reattachment moodlets
should probably disappear more appropriately.
/🆑
---------
Co-authored-by: Hatterhat <Hatterhat@users.noreply.github.com>
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.
About The Pull Request
Mood was abusing signals and get component pretty badly, so I redid it as a datum to stop this.
Why It's Good For The CODEBASE
Better code pratices, also gives admins easier tools to manage mood
Changelog
cl
admin: Added two new procs into the VV dropdown menu to add and remove mood events from living mobs.
/cl
