OneConfig V1

[Wyvest]

OneConfig -> TwoConfig changes list

General

• Refactor to org.polyfrost.oneconfig
• Rewrite to all APIs and most utilities
• Removal of NanoVGHelper, addition of PolyUI
• OneColor -> PolyColor; OneKeyBind = KeyBinder.Bind
• 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