YetAnotherConfigLib (yacl) is just that. A builder-based configuration library for Minecraft.
LGPL-3.0 License
Bot releases are hidden (Show)
Published by isXander 9 months ago
Published by isXander 11 months ago
Published by isXander 11 months ago
Updates to support 1.20.4.
Published by isXander 11 months ago
Updates to support 1.20.3.
Published by isXander 12 months ago
As you can see, a lot of the contributions to this release are from other people! That's incredible, and I'm very
thankful for the community commitment to this project!
This release is a beta release, which just means that I'm not 100% sure that everything works as intended.
I encourage developers to at least try this build out, and if there are no problems, you're safe to release (I hope!).
optionIf
!Home
and End
keys. (#108)Ctrl + Left/Right
(you can now jump over words, without selecting it). (#108)NumberFieldController
increasing their values by a power of 10 when clicking on the screen. Issue @ #103 PR @ #108
-Dyacl3.debug.imageFiltering=true/false
which applies experimental filtering to imagesbuild.gradle
.https://maven.quiltmc.org/repository/release/
https://oss.sonatype.org/content/repositories/snapshots/
Published by isXander about 1 year ago
ConfigClassHandler#save
and ConfigClassHandler#load
and deprecated ConfigClassHandler#serializer
.
ConfigSerializer#load
for ConfigSerializer#loadSafely
.SerialEntry
, called required
.
SerialEntry
, called nullable
.
Published by isXander about 1 year ago
ConfigClassHandler#save
and ConfigClassHandler#load
and deprecated ConfigClassHandler#serializer
.
ConfigSerializer#load
for ConfigSerializer#loadSafely
.SerialEntry
, called required
.
SerialEntry
, called nullable
.
Published by isXander about 1 year ago
The artifact for this release is
dev.isxander.yacl:yet-another-config-lib-fabric:3.2.0+1.20
(assuming Fabric)
Starting this update, the previous config api is now deprecated.
The new API is much more modular, and is now fully API-safe.
public class MyConfig {
public static final ConfigClassHandler<MyConfig> HANDLER = ConfigClassHandler.createBuilder(MyConfig.class)
.id(new ResourceLocation("my_mod", "my_config")) // unique ID for your config
.serializer(config -> GsonConfigSerializerBuilder.create(config)
.setPath(FabricLoader.getInstance().getConfigDir().resolve("my_config.json"))
.setJson5(true) // json5 support, with GSON!
.build())
.build();
@SerialEntry(comment = "optional comment!")
public boolean myOption = true;
public static void save() {
MyConfig.HANDLER.serializer().save();
}
public static void load() {
MyConfig.HANDLER.serializer().load();
}
}
As you can see from the above example, it's syntactically quite similar
to the old API, but with a few key differences:
The new API can now fully auto-generate your config into a YACL GUI with annotations.
I have been very wary of this feature, since usually it can be very limiting, destroying most
of the core values of the powerful YACL builder interface. However, I believe I've found a great
modular way so that developers can extend the auto-gen feature with their own custom annotations,
adding support for their own custom controllers!
public class MyConfig {
public static final ConfigClassHandler<MyConfig> HANDLER = ConfigClassHandler.createBuilder(MyConfig.class)
.id(new ResourceLocation("my_mod", "my_config")) // unique ID for your config
.serializer(config -> GsonConfigSerializerBuilder.create(config)
.setPath(FabricLoader.getInstance().getConfigDir().resolve("my_config.json"))
.setJson5(true) // json5 support, with GSON!
.build())
.build();
@AutoGen(category = "my_category", group = "my_group")
@Boolean(formatter = Boolean.Formatter.YES_NO, colored = true)
public boolean myOption = true;
public static Screen createScreen(Screen parent) {
return MyConfig.HANDLER.generateGui().generateScreen(parent);
}
}
Above is an example of auto-generating a BooleanController
. Notice how
the field does not require @SerialEntry
. These are completely separate,
and you can use both at the same time.
For the full range of auto-gen annotations, check the source!
Documentation for the new API is still a work in progress. For now, it's best
to look at the following class: dev.isxander.yacl3.test.AutogenConfigTest
(not available on the artifact).
This is bringing the off-branch hotfix 3.1.1 to the main branch.
Crendgrim has PRed a dropdown controller! Which is in this release!
This adds two new controller builders, DropdownStringControllerBuilder
and ItemControllerBuilder
.
The latter renders the item in the dropdown, and suggests only the items.
Published by isXander about 1 year ago
The artifact for this release is
dev.isxander.yacl:yet-another-config-lib-fabric:3.2.0+1.20.2
(assuming Fabric)
Starting this update, the previous config api is now deprecated.
The new API is much more modular, and is now fully API-safe.
public class MyConfig {
public static final ConfigClassHandler<MyConfig> HANDLER = ConfigClassHandler.createBuilder(MyConfig.class)
.id(new ResourceLocation("my_mod", "my_config")) // unique ID for your config
.serializer(config -> GsonConfigSerializerBuilder.create(config)
.setPath(FabricLoader.getInstance().getConfigDir().resolve("my_config.json"))
.setJson5(true) // json5 support, with GSON!
.build())
.build();
@SerialEntry(comment = "optional comment!")
public boolean myOption = true;
public static void save() {
MyConfig.HANDLER.serializer().save();
}
public static void load() {
MyConfig.HANDLER.serializer().load();
}
}
As you can see from the above example, it's syntactically quite similar
to the old API, but with a few key differences:
The new API can now fully auto-generate your config into a YACL GUI with annotations.
I have been very wary of this feature, since usually it can be very limiting, destroying most
of the core values of the powerful YACL builder interface. However, I believe I've found a great
modular way so that developers can extend the auto-gen feature with their own custom annotations,
adding support for their own custom controllers!
public class MyConfig {
public static final ConfigClassHandler<MyConfig> HANDLER = ConfigClassHandler.createBuilder(MyConfig.class)
.id(new ResourceLocation("my_mod", "my_config")) // unique ID for your config
.serializer(config -> GsonConfigSerializerBuilder.create(config)
.setPath(FabricLoader.getInstance().getConfigDir().resolve("my_config.json"))
.setJson5(true) // json5 support, with GSON!
.build())
.build();
@AutoGen(category = "my_category", group = "my_group")
@Boolean(formatter = Boolean.Formatter.YES_NO, colored = true)
public boolean myOption = true;
public static Screen createScreen(Screen parent) {
return MyConfig.HANDLER.generateGui().generateScreen(parent);
}
}
Above is an example of auto-generating a BooleanController
. Notice how
the field does not require @SerialEntry
. These are completely separate,
and you can use both at the same time.
For the full range of auto-gen annotations, check the source!
Documentation for the new API is still a work in progress. For now, it's best
to look at the following class: dev.isxander.yacl3.test.AutogenConfigTest
(not available on the artifact).
This is bringing the off-branch hotfix 3.1.1 to the main branch.
Crendgrim has PRed a dropdown controller! Which is in this release!
This adds two new controller builders, DropdownStringControllerBuilder
and ItemControllerBuilder
.
The latter renders the item in the dropdown, and suggests only the items.
Published by isXander about 1 year ago
ImageRenderer
APIThe ImageRenderer
API has been rewritten internally to use a dual-thread
initialization. Before, GL calls were made on a separate thread, which silently
threw errors. Sodium 0.5 introduced an option called No Error Context
, which turned
these warnings into complete JVM crashes.
Because of this, this rewrite was unavailable.
In the process of a huge YACL update, this commit was buried under a lot more changes
that are not ready for production yet, so I decided to branch from 3.1.0 and cherrypick
this commit to fix the issue.
Most likely not, declaring images through OptionDescription.Builder
is unaffected as that
is part of the safe API. However, if you use the ImageRenderer
directly to create your own
custom renderers, you will have to update your code to use the new API.
Most likely, yes. Zoomify and a few other popular mods use the ImageRenderer
API directly,
these mods will need updating, and will fail to load the images or even crash if they are not updated.
Published by isXander about 1 year ago
ImageRenderer
APIThe ImageRenderer
API has been rewritten internally to use a dual-thread
initialization. Before, GL calls were made on a separate thread, which silently
threw errors. Sodium 0.5 introduced an option called No Error Context
, which turned
these warnings into complete JVM crashes.
Because of this, this rewrite was unavailable.
In the process of a huge YACL update, this commit was buried under a lot more changes
that are not ready for production yet, so I decided to branch from 3.1.0 and cherrypick
this commit to fix the issue.
Most likely not, declaring images through OptionDescription.Builder
is unaffected as that
is part of the safe API. However, if you use the ImageRenderer
directly to create your own
custom renderers, you will have to update your code to use the new API.
Most likely, yes. Zoomify and a few other popular mods use the ImageRenderer
API directly,
these mods will need updating, and will fail to load the images or even crash if they are not updated.
Published by isXander about 1 year ago
ListOption
changesA PR by Crendgrim - thanks a lot!
minimumNumberOfEntries
maximumNumberOfEntries
builder methods.insertEntriesAtEnd
builder method.ImageRenderer
changesAdded a tick()
method to image renderers that allows to update the image in a regular interval.
Published by isXander about 1 year ago
ListOption
changesA PR by Crendgrim - thanks a lot!
minimumNumberOfEntries
maximumNumberOfEntries
builder methods.insertEntriesAtEnd
builder method.ImageRenderer
changesAdded a tick()
method to image renderers that allows to update the image in a regular interval.
Published by isXander over 1 year ago
Published by isXander over 1 year ago
Published by isXander over 1 year ago
Published by isXander over 1 year ago
IntegerFieldController
and LongFieldController
not allowing negative values.ButtonOption
changing the 'EXECUTE' text with ButtonOption.Builder#text()
Published by isXander over 1 year ago
ButtonOption.Builder#text()
Published by isXander over 1 year ago