Skip to content
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

Closed
JLUsr opened this issue Feb 3, 2023 · 5 comments
Closed
Labels
bug Something isn't working

Comments

@JLUsr
Copy link

JLUsr commented Feb 3, 2023

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:

  1. Install something like Trinkets on the server AutoModpack is hosted on.
  2. Update AutoModpack on the client by connecting to the server AutoModpack is hosted on.
  3. Install something like Trinkets Curios Theme on the client connecting to the server AutoModpack is hosted on.
  4. Attempt to launch the client, you should get something like 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 the mods 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):

  • Tested on Fabric and Quilt 1.19.2 with AutoModpack 3.0.1

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 clients bin folder or setting up global_packs resources for the client to use (though this seems possible based on the syncedFiles parameter in the config).

@Skidamek
Copy link
Owner

Skidamek commented Feb 3, 2023

looks like i did the best anticheat XD

@Skidamek
Copy link
Owner

Skidamek commented Feb 3, 2023

Thanks, you got the point, i thought this update maybe a bit controversial one... Well it is what it is.

[CLIENT] mods got deleted because it's not longer needed. Now anything put into servers' folder ./automodpack/host-modpack/... works like previous [CLIENT] mods.

I know what can i do to don't need to copy mods to default ./.minecraft/mods/ to make it work.
However having modpack mods in different directory still makes some problems e.g. with relaunching in #87
I would love to hold modpack files in different folder it just makes it better in many cases, like much easier updates because thanks to that, the old shity delmods.txt could got retired and all modpack mods are in one folder and thanks to that we can easily see that if there is some mod which doesn't exists on server's modpack-content.json got removed from modpack, so we can delete that from dedicated modpack mods folder and don't think of some mixed mods from modpack with default mods like it was before. For sure there could be different solution to make it also work. But solution to having modpack mods in default ./.minecraft/mods/ has much higher chance to broke more things, delete files which shouldn't be deleted etc.

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!

@Skidamek Skidamek added the bug Something isn't working label Feb 3, 2023
@Skidamek
Copy link
Owner

Skidamek commented Feb 5, 2023

Temporally fixed in 3.0.2, should be ok for time being. I will improve that in future

@Skidamek Skidamek closed this as completed Feb 5, 2023
@Skidamek
Copy link
Owner

Skidamek commented Feb 12, 2023

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?

@JLUsr
Copy link
Author

JLUsr commented Feb 12, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants