Skidamek
Client startup crash when using certain combinations of local and modpack mods
Bug description
Certain combinations of mods in the server modpack and the client's local mods folder may cause the client to crash on startup.
One such combination is PassthroughSigns (and dependencies) in the server's modpack, and Charmonium (and dependencies) in the client's local mods folder.
There is no crash when both mods are in the server's modpack or when both mods are in the client's mods folder. I suspect the crash has to do with the mods sharing a dependency (Fabric API) and the way AutoModpack handles duplicate mods in the modpack and the local mods folder.
Steps to reproduce
- Create a fresh server instance.
- Add AutoModpack, PassthroughSigns, Forge Config API Port, and Fabric API to the server's modpack folder
- Start the server
- Create a fresh client instance with Fabric 0.16.0
- Add AutoModpack, Charmonium, and Fabric API to the client's mods folder
- Start the client and connect to the server
Expected behavior
After downloading the server's modpack and restarting, the client works as expected
Actual behavior
After downloading the server's modpack and attempting to restart, the client will crash on startup.
Note that the client will continue to crash on startup if AutoModpack is removed; Fabric API must be redownloaded to resolve the crashing.
Relevant logs
https://mclo.gs/RsUNJ7v
Minecraft & Mod Loader versions
1.21 fabric 0.16.0
Minecraft launcher
No response
Operating system
Windows 10
AutoModpack version
4.0.0-beta11
Other information
No response
Check list
- [X] I have verified that the issue persists in the latest version of the mod.
- [X] I have searched the existing issues and confirmed that this is not a duplicate.
Sorry for the late reply, I've been kind of busy the last few days. But yeah, I can try with 0.15.11 tomorrow and see what happens
After a little digging i see that its because Charmonium provides outdated night-config packages specifically version 3.6.6 but forgeconfigapiport depends on the same night-config packages but with version 3.8.0 and because Charmonium is in default mods dir, older packages are loaded first, and then for some reason they are not getting replaced by the new ones. (automodpack should somehow handle that)
So when PassthroughSigns is getting initialized it calls forgeconfigapiport which then calls methods from night-config which doesn't even exist yet in the older version which causes game to crash. For the time being easiest solution is to recompile Charmonium for it to provide newer version of night-config to fix the crash. I've created pull request to do that and also since it has MIT license I've uploaded compiled one to my proton drive
Hello, so for the last few days, i got an issue, that looks like that has been a recurring problem "how automodpack loads certain mods", i have a server where ive been tweaking with several mods, like a lot, but in the last batch i installed the sinytra connector mod crashes, i first thought it was the connector bug, and i went to their github but couldn't find a fix, so i made two instances of the client side, one with the automodpack and one without it, well without the automodpack the game ran smoothly, but with the automodpack same error "Connector Error no existing paths: [ Forge 1.20.1.jar]", using forge 47.3.0, minecraft 1.20.1 and automodpack AutoModpack 4.0.0-beta14 forge, it the worst cases the mods working sinytra are merely client side and visual enhancements, i think (i haven't tested it) i saw that you can disable automodpack on client so you can join the server (obviously having the same matching mods) but only on fabric?, thats the only way i can think to at least fix this kinda bug, i ve read that is kinda more complicated on forge for the way it is coded
Huh connector error? That's seems different, could you @DuskCrow19 create a new issue and provide a log please?
i saw that you can disable automodpack on client so you can join the server (obviously having the same matching mods) but only on fabric?
Sorry that's completely wrong, thanks for bringing it to my attention, updated wiki, it should work perfectly fine also on forge.
hello, i have the same issues, when i put my mods on the mods folder as a client, the launcher crashed
im using the latest beta version 1.21.1 for fabric
Has there been any progress regarding this? I presume there isn't a way to have multiple versions of a dep loaded for a mod so they don't fail on load.
@Mentalgen No, i will work on this when i get some more free time.
What it requires to work is to add more logic to my mod de-duplication code right now it only checks if there's mod which has the same mod id in the modpack and if so, we remove it from default mods, accounting to not remove client side deps.
It should check if modpack mods are dependent on any mod in the default mods folder and if so, then check if the that dependency version is lower than required/provided by modpack mod. if so then force move that modpack mod to the default mods folder (and add that mod to the ) or extract just that dependency.
Everyone is welcome to make pull request with that changes to speed up fixing it!
Hey @Skidamek had now the same Issue on Farmers Delight and Aether. with Automodpack it crash, without Automodpack, it does not Crash the client anymore.
you could look on the issues here https://github.com/MehVahdJukaar/FarmersDelightRefabricated/issues/107 https://github.com/The-Aether-Team/The-Aether/issues/2379
@suerion please try this build now it should not crash but if you encounter a boot loop (which is very possible) please send your client log and your automodpack-content.json file.
@Skidamek hope i could help, i'm using 1.21.1 Fabric on 0.16.9
Farmers Delight and Aether are installed
Okey, i had looked again on the Files, Log file does not include exceptions, that the client gives, but the client started not anymore yet
Here the Client Logger:
Tested, to delete automodpack-content.json and regenerate it with server new.
Deleted all Cached files on Client: (Clean Client)
Latest (automodpack-content.json should not up to date but is on latest? latest.log
Now i delete also the whole Modpack in the Modpacks folder logs will come after testing
I think yet are the librarys or fabric api not moved any more and a lot of mods moved without needed...
woah i dont need that deep testing, log is enough thanks. if you willing to spend more time testing next build is for you lol
Had again the issue, that Minecraft loaded in Vanilla Minecraft after issue with File movement on first start latest.log
second Start -> again start in Vanilla Minecraft
latest.log
Cleared Cache and all and it is again the same issue
But, it has loaded only the disabled files ;) the file movement is right now
The issue with the crash from automodpack is fixed again, but, now it crash again on Mixin Inject latest.log
Should be fixed at least on fabric right now. If anyone wants to test go ahead
edit: it was not fixed...
@Kamaad1 we are working and debuging right now on the fixes, and there will be an release, if it does work
@Kamaad1 dev build 99% fixes the issue, would be awesome to also get your feedback you can download build from there. We with @suerion tested and it seem to work pretty well now (if you are on fabric - but forge feedback would be also welcome). If everything goes well beta 19 with the fix is expected to be released tomorrow.
Fixed in beta 19. If someone is still encounters this on neo/forge please open new issue.