## About The Pull Request
this fixes a bunch of code incorrectly calling qdel directly on a list,
and adds a stack trace to qdel if someone does pass a list to it
## Why It's Good For The Game
because I'm pretty sure qdel ends up calling fucking `del()` as `/list`
is not a `/datum`
## Changelog
No user-facing changes.
## About The Pull Request
Currently to check for Silicon access, we do:
``if is silicon or is admin ghost or has unlimited silicon privileges or
has machine remote in hand``
What has unlimited silicon privileges? Bots, Drones, and admin ghosts.
To check for AI access, it just checks for AI instead of silicon, and
doesnt check for unlimited silicon privileges.
This was kinda silly, so I thought I should make this a little easier to
understand.
Now all silicon/ai traits come from ``AI_ACCESS_TRAIT`` or
``SILICON_ACCESS_TRAIT``. I made a single exception to keep Admin ghost,
since now instead of being a var on the client, we moved it to using the
same trait but giving it to the client instead, but since we have to
keep parity with previous functionality (admins can spawn in and not
have this on, it only works while as a ghost), I kept previous checks as
well.
No more type checks, removes a silly var on the mob level and another on
the client.
Now while I was doing this, I found a lot of tgui's ``ui_act`` still
uses ``usr`` and the wrong args, so I fixed those wherever I saw them,
and used a mass replace for the args.
Other changes:
- machinery's ``ui_act`` from
https://github.com/tgstation/tgstation/pull/81250 had ``isAI`` replaced
with ``HAS_AI_ACCESS``, this has been reverted. Machine wands and admin
ghosts no longer get kicked off things not on cameras. This was my
fault, I overlooked this when adding Human AI.
- Human AI's wand gives AI control as long as it's in your hand, you can
swap to your offhand. I hope this doesn't end up going horribly,
otherwise I'll revert this part. It should let human AIs not have their
UI closed on them when swapping to eat food or use their door wand or
whatnot.
- Bots previously had special checks to scan reagents and be
unobservant, I replaced this with giving them the trait. I also fixed an
instance of unobservant not being used, so now statues don't affect the
basic creature, whatever that is.
## Why It's Good For The Game
This is an easier to understand way of handling silicon access and makes
these mobs more consistent between eachother.
Other than what I've mentioned above, this should have no impact on
gameplay itself.
## Changelog
🆑
fix: Statues don't count as eyes to creatures.
fix: Human AIs and Admin ghosts no longer get kicked off of machines
that aren't on cameranets.
/🆑
This reverts commit 9acf5bd821.
MSO determined that because we use `file(...)` instead of a string
instead of an asset being locked to its initial state via a cache object
we are sending it as it is on disk every time. which means that when a
new server deployment updates the tgui it will send this new tgui code
even if the currently running DM code does not support it.
## About The Pull Request
If we say something is a Modal it should actually be a Modal
## Why It's Good For The Game
You can now use this system in other windows if you want.
Fixed the misnomer.
---------
Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com>
## About The Pull Request
After https://github.com/tgstation/tgstation/pull/80628, these shouldn't
be needed anymore right?
## Why It's Good For The Game
Cleans up some vestigial code
## Changelog
EDIT: Not player-facing.
## About The Pull Request
Added a user type to integrated circuits that can't be stored as a user
type but can be typecasted to entity. Useful for components that
directly ask for an input from the user, like the list pick component.
Refactored the list pick component to use this user port and to also
send failure signals whenever a success signal is not sent.
Removed the triggered port for the list pick component.
Also fixes a runtime that occurs with the list pick component if the
list passed in only contains null values.
## Why It's Good For The Game
Can't force a prompt onto people who haven't interacted with your
circuit.
## Changelog
🆑
add: Added a user type to integrated circuits
/🆑
---------
Co-authored-by: Watermelon914 <3052169-Watermelon914@users.noreply.gitlab.com>
## About The Pull Request
Fixes#79321
```dm
/datum/tgui/proc/open()
if(!user.client)
return FALSE
```
The TGUI window won't even `open()` and do any work if we don't have a
client, so let's just explicitly get the hell out of dodge if we don't
have a client associated with a mob in these procs. Adding a `?` to
handle the runtime in the linked issue only obfuscates the deeper issue
because of the aforementioned code snippet.
## Why It's Good For The Game
Clientless monkeys will still somehow be able to interact with stuff
through their random behavior, and this is still plausible enough to
show up on live servers every so often, so let's just patch it out
early. These alerts are meant for player user input, so if we don't have
a player, let's bounce.
## Changelog
A player would never ever notice this.
## About The Pull Request
Title. Adds a new argument to the factory proc, the New(), adds a
variable, and changes ui_state() to return that variable. The variable
is always_state by default.
## Why It's Good For The Game
It allows custom behavior to be injected into the ui_state logic of the
basic input datums. This is good because there are circumstances where
always_state isn't acceptable. Ex. you open tgui_input_list(mob/user),
and the mob dies or is deleted. The list stays open, the contents can be
picked, despite this not being what the author wants. With this PR, you
can make sure the list closes and inputs are invalid in circumstances of
your choosing without having to completely re-make the input procs via
copypasting.
## Changelog
🆑
code: TGUI input datums can now accept custom ui_states
/🆑
