#52 · open · 5 comments
the 1.21.1 neoforge version of [lazyDFUreloaded](https://modrinth.com/mod/lazydfu-reloaded) 1.1 and mod sets 2.1.3 cause the game stuck on loading screen. <img width="3840" height="1745" alt="Image" src="https://github.com/user-attachments/assets/96d863fc-491b-4dc6-b072-6345dd1e8e41" />
send the latest.log and debug.log
the stuck happen in my heavily moded client, logs: [latest.log](https://github.com/user-attachments/files/28264605/latest.log) [debug.log](https://github.com/user-attachments/files/28264638/debug.log) then i create a new instance with only mod sets (and dependcies) and lazyDFUreloaded, and i got this: <img width="3840" height="1745" alt="Image" src="https://github.com/user-attachments/assets/142e8952-170b-4641-8d96-659376e593ac" /> logs: [latest.log](https://github.com/user-attachments/files/28264940/latest.log) [debug.log](https://github.com/user-attachments/files/28264944/debug.log)
模组在重构，所以会修的不是这个问题，这个报错应该和 lazydfu 是无关的，应该是本模组的问题。 我会在重构完成后测试看看能不能正常运作 :)
谢谢你。另外因为我还再用这个模组的子文件夹识别来给mods分类，我注意到lxeris4.3.0、CrashAssistant1.11.9在mods的子文件夹内会使游戏无法运行，放在mods文件夹又不会有问题。我还没向两边的开发者issue，鉴于这里在重构我也不在这里开新issue了。谢谢。
因为有些模组，比如这两个，它们是运行在服务层的模组，这意味着它们相比起其他模组需要更早的启动 这种模组只能在根目录里，因为这是最早点可启动点，Forge 只会尝试在根目录寻找，ModSets 本身甚至还要比这些模组稍晚一点启动，所以就没有处理这种情况的模组 不过这并不是不可能处理的，原理上我觉得应该可以，可以新开一个 issue