1.20.x ForgeConfigSpec revisit

[SrRapero720]

thats a collection of changes for ForgeConfigSpec, just to enhance it with some additions

[autoforge]

@SrRapero720, this pull request has conflicts, please resolve them for this PR to move forward.

[LexManos]

What is the use of FloatValue vs DoubleValue?
Also MapValue isn't used, and has issues with toml style layout. What are you wanting to use that for?
All the other 'fixes' are just automated code 'cleanup'. Which doesn't really matter.

[SrRapero720]

What is the use of FloatValue vs DoubleValue?

Only purpose was avoid downcasting java.lang.Double to double and then cast to float
you cannot directly cast java.lang.Double to float

Also MapValue isn't used, and has issues with toml style layout. What are you wanting to use that for?

Thats why i keep this as a Draft, i was looking on nightconfig capabilities and i discover it has not support for Map's
i add it just blueprinting any "MapLike" config, but yeah is not doing nothing ATM until i figure out the most optimal way to support Maps without really support Maps

All the other 'fixes' are just automated code 'cleanup'. Which doesn't really matter.

Yep

[SrRapero720]

i decide to stop from where i was.
i want to backport this, so breaking changes is outside of this PR scope

SUMARY

• Added FloatValue, ByteValue and ShortValue
• Added primitive cache fields on primitive values + methods with primitive returns (see Autoboxing)
• Added method to get Ordinal on EnumValues
  • Justification: Allows you to use ForgeConfig directly on render methods with no performance impact (specially if your mod is full client-side rendering based.
• Addec ConfigUpdateHandler, with the only purpose to notify any changes on config values using ConfigValue#set()
• Removed hell spaces on brackets
• Usage of Java 17 features (such as if (specValue instanceof Config specConfigValue) {)
• Basic cleanup

[SrRapero720]

my first intention was add support of Map<String, String> using a List<> and custom parsers to store maps as list values (such as key_string[;]value_string[;]) but might be a bad idea and honestly looks horrible and no very well understandable

[SrRapero720]

i will add some extra changes, but not hard breaking

[PaintNinja]

There's too many vaguely related features in this one big PR. Please split it up into smaller PRs.

As for getting ordinal on EnumValue directly for render methods, this isn't recommended for performance reasons. You should instead read the enum ordinal from the config once and store it in a static final. You can use the deferred holder class idiom to achieve this in a way that only reads the value on first use:

record MyEnumThing() {
    static final int ORDINAL = ENUM.get().ordinal();
}
static int getEnumThingOrdinal() {
    return MyEnumThing.ORDINAL;
}

This allows the JIT to properly inline the value from the start.

[PaintNinja]

Labelled as a breaking change because this PR promotes a userdev-only error to also happen in production

[SrRapero720]

marked as draft until i have time to address everything

[autoforge]

@SrRapero720, this pull request has conflicts, please resolve them for this PR to move forward.