## About The Pull Request
So this nice way of explicitly override an emote type exists, but for
some reason it is not properly used and mostly nonfunctional.
Custom emotes, a perfect use case for these, was just... mutating the
singleton and then resetting it back, instead of actually making use of
args.
Sinful. Just sinful.
<details><summary> It does work, note the type override from the prompt
making its way where needed. </summary>
<img width="209" height="206" alt="dreamseeker_DRS9nFqoQP"
src="https://github.com/user-attachments/assets/35cbac9b-600f-4060-938e-519e110f330d"
/>
<img width="308" height="493" alt="Code_ZQfaj3GGSu"
src="https://github.com/user-attachments/assets/6847e070-d11f-4a32-90fa-edbb5e869e13"
/>
</details>
## Why It's Good For The Game
Fixes a likely oversight/coding skill issue. Improves code modularity.
## Changelog
Nothing anyone would notice, if this is working correctly.
## About The Pull Request
When a camera update is triggered, it is instead added to a queue on a
background subsystem
An AI entering a camera chunk which is queued to update will force the
update immediately (bypassing the queue)
While the root problem of this is, ultimately, not addressed...
<img width="554" height="58"
alt="467828777-eff3f0e5-49d6-4997-b4d7-05eff6432155"
src="https://github.com/user-attachments/assets/c2d6a5f5-d958-463e-959f-116bd0dab475"
/>
...the change will ultimately prevent update spam from consuming all of
the server's resources - instead allocating updates to the backburner in
times of high server stress (or on multi-z maps)
## Changelog
🆑 Melbert
refactor: Refactored the way camera updates are handled to hopefully
reduce some lag. Report any oddities
/🆑
## About The Pull Request
Added recovered crew to the ghost role spawner menu. Clicking spawn will
make you orbit the recovered crew body.
https://github.com/user-attachments/assets/326856c4-e306-43fd-b7d6-a8d5554a0e81
Orbiting the body will make it twitch a little to indicate to
coroners/MD's/roboticists that you're ready to be revived.
## Why It's Good For The Game
Getting people to actually play the recovered crew is kinda hard on most
rounds :( . First on my list is to make the process more convenient for
everyone.
By adding it to the ghostrole spawner menu, ghosts can quickly see if
bodies are available if they wish to play as one. Making them twitch
when orbited makes it so the people reviving them don't have to revive
them every few minutes in the case someone wishes to join as them (they
still might, it does get more attention).
I think the twitching effect is the best natural indicator that someone
wishes to join without being too OOC. I can imagine doctors being a
little confused at first, but it should click pretty quickly.
I am not too concerned about it being used as a ghost communication
medium. The spectroscopic sniffers are a more convenient tool for this,
and I don't think I've seen someone do it with them.
## Changelog
🆑
add: Recovered Crew have been added to the ghostrole spawner menu
add: Orbiting Recovered Crew corpses will make them twitch to indicate a
soul is available
/🆑
Giving them straight up superpowers or more aggressive antag rolls is
still something I'm considering. We'll see if/when I decide to do it
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
This PR adds usb functionality to advanced camera consoles.
The advanced camera console component gets the last valid position
viewed from the console, which is usually the current viewed position,
unless you move the view into static.
The advanced camera target intercept outputs the position you left/right
click (except shift-clicking), and what you clicked on. This only works
for atoms the camera can actually see, even if you somehow glitch your
way into not seeing static on your client.
Equipment action components on circuits attached to a camera console
will add their actions to be used from the console.
## Why It's Good For The Game
Expands the use cases for the advanced camera console, providing a means
to extend their functionality, as well as a potentially powerful source
of input data for circuit users able to acquire illegal tech (or get the
board from a space ruin).
## Changelog
🆑
add: Advanced camera consoles now have usb ports. Connected circuits can
get the position the camera is viewing, get the location of targeted
entities, and provide the console with actions that the user can
activate.
/🆑
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
## About The Pull Request
This PR adds some tweaks to make custom shuttles a bit easier to use,
and more useful.
- The station blueprints can be used to allow/forbid custom shuttle
docking in station/custom areas. Custom areas allow shuttle docking by
default, while station areas (apart from the asteroid) forbid it.
- A station area that allows shuttle docking can have a shuttle
built/expanded in it, as long as the area's APC isn't contained within
the frame used to construct/expand the shuttle.
- A shuttle frame does not need to contain the entirety of a custom
area, unless that frame contains the area's APC. If the frame doesn't
contain the entirety of the custom area, that section of the frame
becomes part of the default area, instead of a separate area.
- Custom shuttles will go off into the sunset at the end of the round,
as long as they have a welded engine.
- I think I saw a bug that caused engines to contribute twice the
intended power to the attached shuttle, possibly creating an exploit in
the case where the engine was broken while welded. I fixed that.
- Custom shuttle docking computers can cross over to any z-level
adjacent to the shuttle's z-level (or vertically-connected z-levels,
because docking computers can traverse stacked z-levels freely). This is
based on the new `zlink_range` var on all shuttle docking consoles,
which can be var-edited to provide the same functionality.
- Shuttle engines constructed from circuits now link to shuttles without
needing to be unanchored and reanchored.
## Why It's Good For The Game
The tweaks to shuttle construction and docking serve to address several
gripes I heard about players not being able to build/dock custom
shuttles in station areas. The means to do this have been locked behind
possession of the station blueprints.
I don't see what problem there would be with allowing custom shuttles to
leave the station at the end of the round, but I could lock it behind a
particular action (antag-exclusive or otherwise).
Custom shuttles don't quite have as much utility if you have to manually
travel to z-levels to drop off gigabeacons. Jumping to adjacent z-levels
one at a time is a bit more useful for space exploration.
## Changelog
🆑
add: The station blueprints can be used to toggle whether custom
shuttles can be built/expanded/docked within station areas.
qol: Custom areas do not have to be completely contained within shuttle
frames, as long as the APC isn't attached to the frame.
add: Custom shuttles with functioning engines will fly off into the
sunset when the emergency shuttle leaves.
add: Custom shuttle navigation computers can view space levels adjacent
to the one the shuttle is currently docked at.
fix: Constructed shuttle engines no longer contribute twice as much
engine power to shuttles, nor can they be used to add unlimited shuttle
power.
fix: Constructed shuttle engines now connect to shuttles when build,
rather than needing to be unachored and then reanchored.
/🆑
## About The Pull Request
The AI's definition is big and unorganized, which makes figuring out
what does what really annoying, so I took the time to document and
organize the file
Some vars have been renamed to better communicate what they actually do
when reading code
Unused vars have been deleted:
* var/chnotify
* var/waypoint
* var/interfaceButton
### Misc changes:
The check to see if malf modules could be used was written incorrectly,
and therefore all malf modules could be used without cooldown. The check
has been fixed, so actions which used to have no cooldown should now
AI bot summoning was supposed to have a cooldown, but it was broken and
not implemented for basic bots. This has been removed instead of fixed,
since I found it was an unnecessary limitation for something so simple.
## Changelog
🆑
fix: Malf modules correctly use action cooldown (affects camera repair
and detonate RCDs)
code: Minor (extremely minor) AI code maintenance
/🆑
## About The Pull Request
The `relaymove` proc for remote camera eyes used `get_step` where
`get_step_multiz` would be more appropriate. This PR changes that.
## Why It's Good For The Game
Fixes#83655
## Changelog
🆑
fix: The "Move Up" and "Move Down" verbs properly respect multi-z
connectivity when operating a remote camera.
/🆑
## About The Pull Request
* A generic /mob/eye/camera type has been made, containing everything
needed to interface with a cameranet
* /mob/eye/ai_eye has been refactored into a generic /mob/eye/camera
instance
* Advanced cameras no longer inherit from AI eyes, splitting off
behaviour
* Camera code has been somewhat cleaned up
* Probably some more stuff I'm forgetting right now
## Big man Southport:
## Changelog
🆑
code: made /proc/getviewsize() pure
refactor: mob/eye/ai_eye has been restructured, now inheriting from a
generic mob/eye/camera type
refactor: advanced cameras and their subtypes are now
mob/eye/camera/remote subtypes
code: the cameranet no longer expects the user to be an AI eye
code: remote camera eyes have had their initialization streamlined
code: remote cameras handle assigning and unassigning users by
themselves now
code: remote cameras now use weakrefs instead of hard referencing owners
and origins
code: also the sentient disease is_define was removed (we don't have
those anymore)
fix: AI eyes no longer assign real names to themselves, fixing their
orbit name
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## Why It's Good For The Game
Clarity and consistency regarding DM's systems.
Internally, `eye` is used for anything that controls the client's view.
How `eye` is used in DM is consistent with how we use the term, so I
figured this would add clarity.
Being named mob/camera also makes it unclear exactly what it's doing.
The name implies that it would function similar to how mob/camera/ai_eye
does, but most of the time it's only used as... an eye.
My ulterior reason for this PR is that I want to clean up
mob/camera/ai_eye and it's subtypes after this.
## Changelog
🆑
server: mob/camera has been renamed to mob/eye, which may break
downstreams
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
Bloop