[maartix1]

Type of change

• Bug fix
• New feature

Description

Fix #6599 by synchronizing module event subscriptions with player and world availability instead of relying on local null guards.

Related issues

Closes #6599

How Has This Been Tested?

Compiled the code successfully.
Launched the game to verify that it starts correctly.

Checklist:

• My code follows the style guidelines of this project.
• I have added comments to my code in more complex areas.
• I have tested the code in both development and production environments.

[Gingerbeard5773]

to quote @crosby-moe
"i think this is all setting a bad precedent, instead of adding null checks everywhere we should tighten the code to prevent nullness altogether"

id suggest reading the conversation in #6734

meteor modules shouldn't ever need null checks for mc.player or mc.level under events like onTick and onRender (unless the module has been explicitly granted permission to run in the main menu using runInMainMenu)

InvUtils/FindItemResult funcs are never supposed to be called when mc.player/ mc.level is null, so those null checks shouldn't really exist either.

[maartix1]

to quote @crosby-moe "i think this is all setting a bad precedent, instead of adding null checks everywhere we should tighten the code to prevent nullness altogether"

id suggest reading the conversation in #6734

meteor modules shouldn't ever need null checks for mc.player or mc.level under events like onTick and onRender (unless the module has been explicitly granted permission to run in the main menu using runInMainMenu)

InvUtils/FindItemResult funcs are never supposed to be called when mc.player/ mc.level is null, so those null checks shouldn't really exist either.

Thanks for the feedback. I understand the concern about adding null checks instead of enforcing the expected lifecycle. Is my code okay now?