[FABRIC] Outvoted

Describe the bug
Running outvoted on a server causes some configs for other mods to be duplicated inside config/outvoted/.

To Reproduce
Steps to reproduce the behavior:

Run fabric-server with outvoted installed.

Expected behavior
Outvoted should only create its own configs inside config/outvoted.

Screenshots/Logs

[fedora@cdc smp-fabric-modded]$ ls -l config/outvoted/
total 64
drwxr-xr-x. 2 fedora fedora 4096 Aug  2 21:30 VillagerNames
-rw-r--r--. 1 fedora fedora  814 Aug  2 21:30 adventurez.json5
-rw-r--r--. 1 fedora fedora  589 Aug  2 21:30 bettermineshafts-fabric-1_17.toml
-rw-r--r--. 1 fedora fedora  880 Aug  2 21:30 betterstrongholds-fabric-1_17.toml
-rw-r--r--. 1 fedora fedora 1608 Aug  2 21:30 bosses_of_mass_destruction.json5
-rw-r--r--. 1 fedora fedora 1436 Aug  2 21:30 common.json
-rw-r--r--. 1 fedora fedora 2330 Aug  2 21:30 conjuring.json5
-rw-r--r--. 1 fedora fedora  409 Aug  2 21:30 dragonloot.json5
-rw-r--r--. 1 fedora fedora 2192 Aug  2 21:30 eldritch_mobs.json5
-rw-r--r--. 1 fedora fedora 1600 Aug  2 21:30 hookshot.json5
-rw-r--r--. 1 fedora fedora 1825 Aug  2 21:30 npcvariety.json5
-rw-r--r--. 1 fedora fedora   81 Aug  2 21:30 redbits.json
drwxr-xr-x. 2 fedora fedora 4096 Aug  2 21:30 sihywtcamc
drwxr-xr-x. 2 fedora fedora 4096 Aug  2 21:29 sihywtcamd
-rw-r--r--. 1 fedora fedora   85 Aug  2 21:30 voidz.json5
-rw-r--r--. 1 fedora fedora  172 Aug  2 21:30 xp_storage.json5

Version (please complete the following information):

Minecraft Version [1.17.1]
Mod Version [2.0.0-alpha.10.fabric]

Oh that's weird. Does it break any of the other configs or is it just a duplicate?

From what I can see all the configs are created correctly, just in the wrong directory.

The main problem it's causing for me is the need to find what mods configs end up in outvoted, and edit the file there instead of in the config/ dir. In the context of creating a modpack or maintaining a server this is quite annoying.

I think I have found what causes the issue:

Outvoted/common/src/main/java/io/github/how_bout_no/outvoted/mixin/MixinUtils.java

Line 16 in a2cb930

    
           @Inject(method = "getConfigFolder", at = @At("RETURN"), cancellable = true, remap = false)

That mixin seems to stick and the new folder gets applied to any mods loaded after it.

One simple fix I've found is to simply remove MixinUtils.java from loading, and use the same code as the client to generate the config. This will however create a client config on the server as well, but it does not seem to cause any other issues. I'm unsure which git-branch you're tracking for new changes, so if you tell me which you prefer between architectury-dev and arch-1.17 I can submit a pull request.

I certainly overlooked my mixin implementation, since in dev of course I don't have other mods loaded. The original point was to achieve a similar folder structure on the server as the client without the client config present as cloth config didn't allow me to do that. I was considering just removing MixinUtils and rename the config files but that would require each user to do extra steps. So I guess just using the client config code would work, although it won't be as pretty 😄

You can pr to either branch. arch-1.17 is currently just for the Fabric 1.17 version, while architectury-dev is for both the 1.16.5 versions.

Submitted for arch-1.17 since that's the one I've actually tested 😅

No problem, I'll mirror the fix to the lower versions. Fix will be included in alpha 11 for 1.17.

Great! Also I have to say that I agree with you that this fix isn’t the prettiest and that the intended old behavior probably should be targeted.

Implemented in Forge alpha 10 and Fabric alpha 11

Share to