Much less janky so new features should come a lot faster
Less dependencies so reduction in JAR size
Faster and less memory intensive
Modern support coming soon
Feel free to contact us if you cannot find a new API when migrating your project
Most APIs are now independent Gradle subprojects, and under org.polyfrost.oneconfig.api.*
Commands
Now under org.polyfrost.oneconfig.api.v1.commands
Now uses a modular factory-based, tree driven system.
Commands can be created using annotations, with just @Command and @Parameter now; or using a brigadier-style builder, or using a Kotlin DSL
Config
Now under org.polyfrost.oneconfig.api.v1.config
Now uses a modular factory-based, tree driven system.
Decoupled into three parts, backend, which stores and loads configs, collectors, which turn Objects into trees, and frontends, which display trees.
Many of the annotations have been minorly changed to now fit with the new design
Now only serialises objects if they are told to, instead of by default serialising all as it used to be
Added accordions instead of sections
No longer dependant on using the annotations and can be created programatically using a builder-style system
Increased the usefulness of the migration system, which is now more of a compatibility layer to show non-oneconfig configs in a window,
the original migration system removed for now, we may reconsider adding this in a more refined way
Can now read and write to .json, .toml, .yaml files without an accompanying config class registered directly (i.e. can read any file and edit it, extended by metadata system)
Complete redesign of the frontend system with PolyUI
Object serialiser and type adapter interface for complex types
old config values are now removed automatically so they don’t build up across updates
if config files are modified while running they are automatically updated in game
Support for adding metadata to otherwise plain trees, e.g. the system can read any file it supports, and then another provider can provide names, descriptions, etc. for the config frontend through merge
UI
Now under org.polyfrost.oneconfig.ui.v1
Removed entirely NanoVGHelper, RenderManager, asset handling, etc, replaced with PolyUI, our new UI framework which is much easier to use and understand, with a declarative Kotlin syntax, similar to Flutter
It is strongly recommended to use Kotlin
Rewrite entirely of the frontend and complete redesign for better UX
TextRenderer has been removed as it was janky and deprecated
OneScreen replaced with PolyUIScreen, making it easy to use PolyUI in Minecraft
Internal asset library has been removed, along with other UI based utilities - most of which have a PolyUI alternative (largest frontend changes occurred here)
If you need a NanoVGHelper-style renderer still, you can use LwjglManager.getRenderer(w, h) - Usage of PolyUI is strongly encouraged however
Events
Now under org.polyfrost.oneconfig.api.v1.events
Now uses our own modular system
Event registration is no longer required to be by annotation, can be done programatically like Fabric
Many events are the same. isCancelled -> cancelled
Objects which provide events must now make it clear if they are able to be removed at a later point
Notifications & Utilities
Notifications changed to use PolyUI
Deprecator promoted to public API
Removal of deprecated and/or slow methods
new TickDelay() -> EventDelay.ticks()
Removal of reflection, replaced by MethodHandle based utilities MHUtils (for speed and modern java version compatibility, as reflection in modern versions is not supported)
Minor changes to the frontend APIs, otherwise identical
mouse delta methods have been removed because they were badly designed
HUD
Now under org.polyfrost.oneconfig.api.v1.hud
Completely redesigned into a much more usable system
You can no longer automatically add HUDs to the screen, the user must add them themselves
Utilises PolyUI, but legacy draw method is still provided for compatibility (discouraged)
it is strongly recommended to use Kotlin for PolyUI
invalid positions are now not possible when the user repositions the HUD
shouldShow() is replaced with the hidden property, which can be updated in the update method, there is no longer a dedicated method called every frame for this (was slow)
HUD inspector and positioning system completely redesigned and is now a lot more powerful, utilising the Config system
Extension of the Config system, so a HUD is just a normal config essentially
OneConfig -> TwoConfig changes list
General
Commands
Config
mergeUI
Events
Notifications & Utilities
HUD