Improvement: Config System#298
Draft
beanbag44 wants to merge 46 commits into
Draft
Conversation
# Conflicts: # src/main/kotlin/com/lambda/util/EntityUtils.kt # src/main/kotlin/com/lambda/util/InputUtils.kt
… by reflections from the parent init
# Conflicts: # src/main/kotlin/com/lambda/Lambda.kt # src/main/kotlin/com/lambda/config/codecs/BindCodec.kt
# Conflicts: # src/main/kotlin/com/lambda/module/modules/client/ModuleNotifier.kt
… the Module constructor
…giving the right reset / undo commands when clicked
… from group/tab to group/tab
# Conflicts: # src/main/kotlin/com/lambda/graphics/mc/renderer/ChunkedRenderer.kt # src/main/kotlin/com/lambda/module/modules/debug/BlockTest.kt # src/main/kotlin/com/lambda/module/modules/debug/RenderTest.kt # src/main/kotlin/com/lambda/module/modules/movement/ElytraFly.kt # src/main/kotlin/com/lambda/module/modules/render/Nametags.kt # src/main/kotlin/com/lambda/module/modules/render/Search.kt # src/main/kotlin/com/lambda/module/modules/render/Tracers.kt
# Conflicts: # src/main/kotlin/com/lambda/graphics/mc/renderer/ChunkedRenderer.kt # src/main/kotlin/com/lambda/module/modules/render/Search.kt
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Replaces the old group system with annotation-based grouping and adds a second type. The old group name was used for tabs, now, @group(groups) is used for actual drop-down groups, and @tab(tabs) is used for tabs (the old group functionality). With the more strongly integrated layering, groups and tabs are now serialized, allowing duplicate setting names within the same config as long as they are separated by a layer.
The old system had a patchy style of grouping settings; however, now it is supported directly inside the Config's, with systems in place to ensure they're easy to create and use. Previously, you had to include a prefix parameter in every SettingGroup and apply it to the start of each settings name to ensure if you had two groups of the same kind, the names wouldnt conflict. You also had to use a helper .index() call at the end of every setting so that when using the ConfigEditor api, it could distinguish the settings inside and out of any given group. Now, SettingGroup has been renamed to SettingBlock to avoid confusion with the grouping system, and none of these problems are present.
Lots of the issues previously encountered were fixed mainly by the annotations enforcing use of reflections for gathering setting metadata. This is what helped make SettingBlock integration much easier; however, it tightened the restrictions as to where you can register settings from. All settings must be class-level values or variables to be found via reflections, and subsequently registered.
Removes all SettingCore child classes and moves the logic into Setting child classes instead. Im not sure why i initially put the logic in the SettingCore classes as it made handling listeners and the automation configs a lot more difficult, and in some cases outright causing unfixable problems.
Moves from Gson to Jackson as it has support for updating already initialized objects rather than creating new instances. This allows us to keep our singleton-based configs while moving away from serialization and deserialization inside the classes themselves. This means the Jsonable interface is also removed. Alongside the Jackson migration, we also have a custom Serializers and Deserializers class that searches the objects supertypes for the closest relevant (de)serializer, e.g., so we dont have to write them for each module. These serializers extend FallbackSerializer or FallbackDeserializer. The standard serializers still extend the regular Serializer and Deserializer classes.
Configs now only save modified settings. Settings have an open isModified value so settings like collection settings can check size and match elements to see if anythings changed
Left to do: Nullability in settings, (good for optional baritone dep), and arbitrary data storing in configs for when something needs to be saved, but doesnt need the overhead of a setting.