Setting a value then saving it will cause all values to revert to their original state when the screen was first opened. Closing then reopening the screen will read the updated value.

https://user-images.githubusercontent.com/19187704/208584816-dbf99a98-10a0-4767-b48a-98c5c2bcc4db.mp4

MC 1.19.3 YACL 2.1.1

In my language, the word "Cancel" has many meanings, and the one that is currently being used does not match the situation in which the mod uses it.

The situation is similar with the "Done" (Готово) button: this variant is allowed, but only if you did not need to save changes with a separate button before clicking on it (this is exactly what appears in YACL).

Hello! I recently noticed this library on Quilt's discord server.

I would like to use it - but for a server side mod. Your readme says,

• Client sided library. YACL is built for client mods only, making it a smaller size.

I would like a lot to use it for my server-side mod. Is it possible? If not, will you add support for it? If not, why?

I just read the documentation, it seems to me like the readme isn't updated? I can't see what's the problem to use it server-side.

P.S. the mod is mandatory on the server, and optional on the client - I plan to use the mod's config loading on the server, and saving on client (obviously, I can't have a screen on server) - is there a problem with that?

It's not that great being forced to use java.awt.Color. Maybe just use ints and accept a java.util.Function to convert back and forth a custom class. When using GSON, it causes some reflection exceptions with AWT colours. I did manage to fix this with an extra class, though.

Wasn't sure about boolean names, as true=prav by the translation, but prav is more used as right (~wrong), that's why I've gone with da (=yes)

also wasn't sure about the GUI word, slovenian counterpart is GUV which no one uses, though GUI is not really used well. I'd propose using the word meni (=menu), though this differs from original then.

Not sure if this is an issue for YACL or XSO, but maybe add a little bit more padding to the sides of this menu.

Instead of this:

It could be like this: (this is done with image editing, so the background is a bit odd but I think you get what I mean)

This would be great to improve the user experience

I saw you mention on Discord that 2.1.1 is a breaking change that requires downstream changes.

This should be retracted and re-released as 3.0 so anyone who is using wildcards aren't caught by surprise.

This morning, I installed v2,1,1 on my 1,19.3 Fabric instance. After playing for a while, I noticed something strange: the Configuration button is now missing from Mod Menu!

For demonstration, here's some screenshots with Cull Less Leaves, which uses Yet Another Config Lib.
Here's what we got with the previous version of YACL:

And here's what we get with the latest version of YACL:

As you can see, the configuration button for Cull Less Leaves is now gone. I don't think I need to explain why this is kinda unhelpful.

I have confirmed that the only thing that changed was YACL. Nothing else changed. I also rolled back and re-updated my version of YACL and the results are consistent.

Not sure if this is relevant, but just in case, the version of Mod Menu I'm using is v5.0.2.

Incompatible mod set!
net.fabricmc.loader.impl.FormattedException: Mod resolution encountered an incompatible mod set!
A potential solution has been determined:
	 - Replace mod 'YetAnotherConfigLib' (yet-another-config-lib) 2.1.0 with version 1.4.3 or later that is compatible with:
		 - minecraft 1.19.2
Unmet dependency listing:
	 - Mod 'YetAnotherConfigLib' (yet-another-config-lib) 2.1.0 requires any version between 1.19.3 (inclusive) and 1.20- (exclusive) of 'Minecraft' (minecraft), but only the wrong version is present: 1.19.2!
	at net.fabricmc.loader.impl.FabricLoaderImpl.load(FabricLoaderImpl.java:190)
	at net.fabricmc.loader.impl.launch.knot.Knot.init(Knot.java:148)
	at net.fabricmc.loader.impl.launch.knot.Knot.launch(Knot.java:68)
	at net.fabricmc.loader.impl.launch.knot.KnotClient.main(KnotClient.java:23)
	

Curseforge told me to update, and the website shows tags for 1.19.2 as well, so I was confused as to why this wasn't support

In some mods, there's only one category. It would be nice to hide the sidebar and maybe move the buttons into the centre like with cloth and other libs.

Implements mutable list options where you can create, remove and shift entries in a list.

API

Lists hack option groups with their own implementation for this, so each individual list takes form as a whole option group.

ListOption.createBuilder(String.class)
    .name(Text.of("List Option"))
    .binding(/* gets and sets a List, requires list field to be not final, does not manipulate the list */)
    .controller(StringController::new) // usual controllers, passed to every entry
    .initial("") // when adding a new entry to the list, this is the initial value it has
    .build()

Implementation details

When implementing this, it was vital to me that all controllers work with lists, not ones specifically designed for list entries. This was achieved quite easily by having each entry being its own option with an empty name and tooltip with its own controller, that pairs with its list "parent" to actually modify the option.

Option groups were taken advantage of and hacked into its own option, only minor changes had to be made to get this to work with value application.

Applicable controllers have been modified to expand their inputs to near full width when no name is present.

Screenshots

Why?

I have seen many mods want to make YACL an optional dependency so if the user decides they want to configure with a GUI, they can, if not, they will configure with the config file. This prevents the mod author from utilising YACL's config API, because it is in the same jar.

How it would work.

YACL would be split into two modules: gui and config. GUI would depend on the config module and the mod jar would publish with both modules.

• Client-sided mods would depend on YACL like before, with both modules.
• Server-sided mods would depend and include on YACL's config API, and depend on YACL's gui.

Other benefits.

This will also allow for #41 because split sourcesets will no longer be needed.

Why?

One more obstacle YACL needs to cross before it can become the de facto standard for client modding is cross-compatibility with forge. Countless mods that have showed interest switching to YACL already use Architectury, which limits them to libraries that also have cross-compatibility (unless they want a different UI per loader).

Problems

Architectury doesn't support split environment source sets

A feature of Loom that YACL relies on is split environment source sets. This allows for a clear split between client and common code. YACL utilises this with its config library which is available on all environments for mods that opt for json configuration on the server and a UI configuration on the client.

Forge's slow updates.

In the past, Forge has taken days to release a version for a new Minecraft version. On fabric, I'm used to releasing updates to my mods minutes after release. Depending on forge for builds prevents being able to push out Fabric builds because Gradle will fail because it can't find a forge version.