Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

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

wants to merge 3 commits into from

Conversation

DeltaFire15
Copy link
Contributor

@DeltaFire15 DeltaFire15 commented Sep 4, 2024 •
edited
Loading

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:

@DeltaFire15
lets hope
48f7f01 
Ratvar guides me on this path so this better actually do its thing.
@jet-pack-cat
Copy link

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
Copy link
Contributor Author

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
Copy link

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
Copy link

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
Copy link
Contributor Author

DeltaFire15 commented Sep 6, 2024 •
edited
Loading

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).

@DeltaFire15 DeltaFire15 added the Fix label Sep 6, 2024
@DeltaFire15
Don't forget to transition.
70c6bf1
@DeltaFire15
easy access
8b9cdf2 
Proc is on the controller already so no need for that.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@Bokkiewokkie Bokkiewokkie Bokkiewokkie approved these changes

Assignees
No one assigned
Labels
Active Test Merge Code Improvement Fix
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Midround-spawned ships do not apply_weapons()
3 participants
@DeltaFire15 @jet-pack-cat @Bokkiewokkie