## 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
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>
MrMelbert