Crashes / Reload-Loops on Quilt (Async resource loading)
sisby-folk opened this issue Ā· 5 comments
Describe the bug
When loading the mod on Quilt with QFAPI, the game crashes on startup on most boots (it's possible for the game to boot successfully). In heavier mod configurations (possibly with mods that guard against these crashes), we've also observed the game enter a reload-loop and not reach the start screen.
To Reproduce
Steps to reproduce the behavior:
- Open the game with the minimum quilt mod set - Cloth, QFAPI, Architectury, Antique Atlas
- Wait and cross your fingers
Expected behavior
Game starts up correctly.
Logs
Game reaches the start screen successfully on Quilt (Rare): https://mclo.gs/MgKSL8E
Game crashes on start on Quilt: https://mclo.gs/tI2ReAH
Game reaches the start screen successfully on Fabric (with the giant modlist that would cause reload-loops): https://mclo.gs/JAm1e58
Version information (please complete the following information):
- AntiqueAtlas: 7.0.1 (also occurs on .2)
- Minecraft: 1.18.2
- Fabric Launcher: Quilt 0.17.5-beta.2
- Fabric API: QFAPI 1.0.0-beta.24
Additional context
This is likely a bug/oversight with QFAPI's replication of FAPI behvaiour, and can either be fixed their side or simply tweaked to work around on this side - Further info will need to be provided here by QSL developers.
From what we know already reworks for resource loading have occurred on QFAPI recently, and the mod worked on quilt when we tested the Sep 7 version - so it's likely the parts of the Architectury Commit responsible for asynchronous resource loading that are stressing QFAPI here.
We're primarily opening this issue for visibility and tracking - especially for users that may not understand why issues like this occur and erroneously believe this is a bug with Antique Atlas.
Looking at a possible fix now š looks like a typo on AA's side that fabric just wasn't kicking a fuss about by luck.
Thanks for the extra info - The first thing we were alerted to by one of the QSL devs was this, which while helpful unfortunately doesn't seem remedy the issue, likely for the reason you're describing.
I'll keep an ear open for possible ways on getting around that and put them here or in a PR.
I've been a bit busy to dig into this one, but I should probably share the advice we were given -
They really must use the dependency stuff on Fabric, even if they need to mixin their own class
Architectury API is incredibly bad on this one
This would mean (as we understand it) mixing in implements IdentifiableResourceReloadListener onto the existing listeners, in order to fill out getFabricDependencies() (here) and then doing... something.
We've been a little busy recently, but we're starting to tinker around with this on our fork - we're missing a few pieces of info required to get this to work, but it's a start.