-
-
Notifications
You must be signed in to change notification settings - Fork 29
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.
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
[1.19.2 Fabric/Quilt 3.0.1] Mod Load Order Issues and Client Restrictions #93
Comments
looks like i did the best anticheat XD |
Thanks, you got the point, i thought this update maybe a bit controversial one... Well it is what it is.
I know what can i do to don't need to copy mods to default It would be great if someone who knows more about UNIX systems and relaunching JVMs/Minecraft than I do could help fix issue #87. Once that's done, fixing this problem will be a breeze. Thanks! |
Temporally fixed in 3.0.2, should be ok for time being. I will improve that in future |
Hey @JLUsr, i was thinking about that and i made a decision to remove relauncher and copy mods to main minecraft folder kinda like it was before what do you think about that? This segregation to folders and auto relauncher is cool but due to many issues you having i think would be better to change that, no? |
I think that is probably for the best. The relauncher also made it difficult to keep track of console logs when using something like PrismLauncher and the management for mods on the client side for individual users/clients is just a lot simpler when the mods are copied over to the main minecraft folder. |
Describe the bug
Fabric/Quilted Fabric API and other dependency mods end up having issues with the way/order mods are loaded now.
To Reproduce
Steps to reproduce the behavior:
Trinkets
on the server AutoModpack is hosted on.Trinkets Curios Theme
on the client connecting to the server AutoModpack is hosted on.Dependency for mod 'trinkets-curios-theme' on trinkets versions [>=3.4.0] (0 valid options, 0 invalid options)
Even if you install
Trinkets
on the client, the jar gets detected by AutoModpack and as a result, its contents are cleared so that it doesn't attempt to load from the default/.minecraft/mods/
folder, and themods
folder generated by AutoModpack. This also applies to things like Fabric API and Quilted Fabric API making it nearly impossible for the client to use any client-side mods that have dependencies on mods being used by AutoModpack.Expected behavior
Files within the
/.minecraft/mods/
folder should be prioritized over the mods generated by AutoModpack.AutoModpack and Minecraft Version you are using (please complete the following information):
Additional context
Let me start by saying that I absolutely love this mod and the intentions behind it. The new 3.0.1 update has a very nice appearance too. I can see that the new system has reduced duplicate files on both the server and the client side of things; however, this has inadvertently caused restrictions on the clients' freedom.
Honestly, I think it might be better to use the old system of having mods generated by AutoModpack be copied into the
/.minecraft/mods/
folder (or add another folder and option in the config to switch between the new, more integrated, system and the old, more segregated, system for managing files/mods/configs and the like). I personally miss the ability to define[CLIENT] mods
and because of this issue I also haven't been able to test if it's possible to define custom changes to things like the clientsbin
folder or setting upglobal_packs
resources for the client to use (though this seems possible based on thesyncedFiles
parameter in the config).The text was updated successfully, but these errors were encountered: