* Sideports a couple of init unit tests from Neb.
* Trying to unfuck initialize logic.
* Removing del()s.
* Adjusting return values to Initialize().
* Moving some dangerous object logic from obj onto the two types that use it.
* Rolling back some init changes and commenting out initialized atom unit test.
* this comment formatting is a minor war crime
* Removed sleep() from signaler circuit Initialize().
* Additional Init fixes post-rebase.
* Uncomments subsystem test since that's passing.
This adds a system for picture-in-picture UI windows using
vis_contents. Essentially, it allows you to make UI windows that show an area of turfs. It also refactors how cameranet visibility works.
Currently, this is implemented on AIs. They gain two new UI buttons - "Enter Multicam Mode", and "Create Multicam". When they go into Multicam Mode, they see a background of animated binary numbers, and they are allowed to create an infinite amount of these picture in picture windows, which subsequently creates an AI Eye for each one. They are able to control each AI eye individually, by first clicking on the PIP window to select it as "active" and then using the normal arrow key controls. The PIP windows can be freely resized and moved around the area.
You can control everything inside these PIP windows EXACTLY the same as you can using a traditional AI Eye, as demonstrated below.
For admins, there is a config option to disable PIP entirely - simply set `var/multicam_allowed = TRUE` to FALSE if you wish to disable it from being used. (Please be reasonable.) <3
You can see an example of how this works here:
AI Multicam functionality.
Do note that if the lightbulb in the AI core is busted, the multicam room is dark(er) than it would be, but you can still see your camera windows just fine. (I'll probably fix this later.) It only affects the "matrix" backdrop, the PIP windows are still fine.
This has been runtime-tested with the latest `master` revision and produces 0 runtimes, and has no noticeable impact on server CPU usage.
Polarisport is here! Port of https://github.com/VOREStation/VOREStation/pull/7752
* Creating new objects is cheap, in fact comparable to the cost of getting it out of the pool, so it doesn't help there.
* Placing items in the pool is far more expensive than letting them garbage collect due to the resetting of vars and such.
``/mob/dead/observer`` -> ``/mob/observer/dead``
``/mob/eye`` -> ``/mob/observer/eye``
Reason being that they are similar in that they both don't interact with
the world in any way. Some procs were shared, some checks as well, and
it overall makes more sense this way. Plus, there were no ``/mob/dead``
mobs.
Implementation of a cult visual network, similar to the original camera network.
Includes the "eye" itself and the initial construction of a mob that can control one.
