[1.16.4] Obtain String from ForgeConfigSpec

[Geolykt]

I've been stuck on this for a while now, so how do I obtain a String of a ForgeConfigSpec (and is that even the correct class to use?).

Now the issue is that the exact path of the String is not known at compile time and will be only known to the runtime after the config has been built via the ForgeConfigSpec.Builder, this also removes the possibility from using the builder to obtain the instances. Since the ForgeConfigSpec has getByte, getInt, getEnum, etc. methods I doubt that there is anything that would hinder me from obtaining a String of it, however a getString method is missing and using getRaw or getOrDefault throw a ClassCastException since the get, getRaw and getOrElse methods don't return T (so String in my case) but from some reason return ForgeConfigSpec.ValueSpec. However ValueSpec is pretty useless for me since that also doesn't have the needed methods to convert it's content to a String (#get(null) or #get("") could be one, but I won't attempt that since that would be super strange if it were to work).

 

So how do I actually obtain a String?

Edited December 17, 2020 by Geolykt

[DaemonUmbra]

Have you looked at how Forge does its configs?

[Geolykt]

Not really, where would the usages be? Type/Call hierarchy of my IDE isn't that helpful.

[DaemonUmbra]

Look for the ForgeConfig class

[Geolykt]

Unfortunately it appears to not be what I am looking for and just reinforces my opinion that I should use a non-forge library and even non-toml language instead.

Now of course I could use integer identifies instead, however it would still mean that I have somewhere around 360 references to unused variables, or make use of two configurations and some unsightly tricks.

I basically currently have a

bots:
  - host: localhost
    user: Username
    nick: Nickname
  - host: localhost
    user: botV2
    nick: AnotherBot

configuration in yaml (well, it's a bit bigger, around 40 variables per bot), porting it to TOML is kindof difficult since TOML doesn't have a notion of arrays. As such I have thought to just index these via the username, which is why I cannot make use of the builder to obtain an instance

[Geolykt]

Update to the issue (for future users) It appears that using ForgeConfigSpec#getValues(), which returns a UnmodifiableConfig, which can then be used instead of the ForgeConfigSpec.

Now, instead of using the returns as is, you'd need to cast the returns to ConfigValue<String> (although String can be replaced with every other Object you want to have) and then invoke the get method on it to get the actual values of the ForgeConfigSpec. It's honestly a bit of a strange way of accessing the values, but at least makes some sense.

Hopefully that will be clarified in the javadocs someday.

Edited December 17, 2020 by Geolykt
removed accidental emoji

[DaemonUmbra]

Do you not see the public static fields in ForgeConfig that are holding the config instances, and the public fields in those config instances you can .get()?

[Geolykt]

Yeah I see it clear as day, but these are exactly what I CANNOT use. I CANNOT make use of the builder to obtain these values as it would require the contents of the config to be known at build time (however it isn't and would throw an exception - I think (wouldn't make sense otherwise)) or that I guess the indexes (which can be done via numeric indexes - no biggie there), which would result in unused instances (that will not be automatically GC-ed - so you'd need to write code to remove it).

Basically, I CANNOT make use of the builder to obtain the values, but only make use of the ForgeConfigSpec.

[Geolykt]

True. I think I should learn more about TOML first, heh