[TESTMERGE ONLY] Weird Atom Init Issues VS. One Lizard

[DeltaFire15]

About The Pull Request

Sooo we have been having some very fun atom init issues popping up concerningly often, and given it tends to fix itself for a single tick (aswell as all only partially uninitialized atoms) if someone buys a shuttle / docks to an asteroid, my assumption is it has something to do with something SSmapping related. (Sabres?)

This messes with some components that touch this, namely some overmap z treadmill handling that was super cursed (still is, but a bit cleaner :) ), and ship interior z loading which was not only very cursed but also caused SSatoms to yell occassionally when multiple things started to load their interiors in a short timeframe.

Treadmills use some slightly more proper z initialization (instead of using ++world.maxz for.. their names??), while interior initialization is now handled by a queue system that sends signals when it's done loading. (Notably, only for asteroids and ships using instance_interior(), boarding map loading (ai_load_interior()) remains unchanged.)

As should be seen by the tag at the top, please only TM this for now, if at all. This might have consequences I am not quite aware of yet, since I'm messing with very complex things in this PR.

I'm not sure if this'll actually make the weird init issues stop, but it's my shot at them for the moment. We'll see if they still occur with this.
(According to someone in the comments this does resolve the issue, which I've never been able to trigger personally, so thats good).

Potentially fixes #2397

Why It's Good For The Game

I can't express my distaste for Atom Init partially breaking in enough words.

Testing Photographs and Procedure

Only partially tested for the moment, and fairly difficult to in-depth test too. Might ignite things.

Changelog

🆑
code: Ship interior loading now uses a queue system (for virtual z using things like Sabres & Asteroids)
code: Some overmap z generation handling is ever so slightly cleaner now.
fix: Should resolve certain atom init issues (that manifested as broken sparks, among many other things).
/:cl:

[jet-pack-cat]

I somehow fixed it which is wild, because I'm a total dumbass.

NSV13/code/controllers/subsystem/atoms.dm

Line 29 in 10bf6e3

/datum/controller/subsystem/atoms/Initialize(timeofday)

^^ SOMEHOW, calling that MANUALLY with the Advanced ProcCall verb fixes it entirely, for the entire round.
The other behavior?, map loading (bluespace capsules, asteroid magnet, asteroid docking, shuttle purchasing) calls InitializeAtoms so it will do that or whatever, though it calls just that and not this magical text that initializes the initialization subsystem or something or whatever. ( I don't know what this is fucking doing)

Anyways, somethings breaking but calling that seemed to fix it, at least as a temporary in game solution.
Yeah so basically to fix (in game)
Advanced ProcCall verb (in debug menu)
Owned by something: Yes
Datum Reference
type: /datum/controller/subsystem/atoms
click ok on the funny numbers.
type: Initialize
arguments: 0
press ok

And it works which is super cool i guess?
I dunno you could totally call it again after game start as a super awesome and not very horrible way of preventing it!.

[DeltaFire15]

I dunno you could totally call it again after game start as a super awesome and not very horrible way of preventing it!.

Sure, lets call Initialize, the proc that is meant to only be called once, of a subsystem, manually, that sounds like it could not cause any lingering issues whatshowever and definitely is better than diagnosing what exactly is going wrong!

[jet-pack-cat]

that sounds like it could not cause any lingering issues whatshowever and definitely is better than diagnosing what exactly is going wrong!

( :

[jet-pack-cat]

I did test the changes of the pull request myself and it does seem to fix the issue. Hopefully I won't have to manually crank the ss13 machine like before, I don't think the crew liked the issues that came from that.

[DeltaFire15]

I did test the changes of the pull request myself and it does seem to fix the issue. [...]

Neat! I've never actually had that issue trigger on my own local so I've mostly been operating off likely related janky things. Probably was the Sabre loading then..
One day I'll have to reinforce boarding mapload too in that case (albeit lower priority).