I based this on #40, so please look at that first.
This is basically a continuation of #31.
Changelog
remove mappedEnchantment*, use enchantmentDataMap directly
The data in mappedEnchantmentColors, mappedEnchantmentIndices was redundant to what's in enchantmentDataMap and mappedEnchantmentTargets wasn't being used.
use "modern" IO (Path, Files), use try-with-resources
This is probably the biggest part.
try-with-resources ensures the reader/writer/Closeable is always being closed.
Path is basically the "modern" File while Files (note the 's') has tons of useful one-liner methods like readString() that simplify a lot of common operations without sacrificing performance.
strictly distinguish between loading and saving (e.g. don't call saveConfig() from loadConfig())
This was really confusing to read, I wouldn't be surprised if there was a bug somewhere in there.
To "compensate" for this, a saveConfig() was put in the title screen mixin, which will generate the default config on first load (and also add new enchantments to the enchantment_data.json).
extract registry access into populateEnchantmentData() and rename loadConfig() to loadAndPopulateConfig()
This is to make the prerequisites for loading more clear:
Other mods need to have their enchantments registered before the title screen mixin (and thereby populateEnchantmentData()) is executed.
extract setting defaults into loadConfigDefaults()
combine StoredEnchantmentData and EnchantmentData, mark non-stored fields transient, remove fromStoredData(), toStoredData()
Wanted to do this back then, this makes reading and writing the enchantment data much easier.
The only thing that one needs to be careful of when using Gson or other serialization methods is that you cannot assume that constructors are being called, not even default constructors.
This is basically the reason why populateEnchantmentData() starts with putting data into EnchantmentData.
initialize DEFAULT_ENCHANTMENT_COLORS directly
Map.of() (for up to 10 entries) or Map.ofEntries() are just a really nice way to define immutable maps.
I also used List.of instead of Arrays.asList so that all values in ModConstants are immutable.
I based this on #40, so please look at that first. This is basically a continuation of #31.
Changelog
mappedEnchantment*
, useenchantmentDataMap
directlyThe data in
mappedEnchantmentColors
,mappedEnchantmentIndices
was redundant to what's inenchantmentDataMap
andmappedEnchantmentTargets
wasn't being used.Path
,Files
), use try-with-resourcesThis is probably the biggest part. try-with-resources ensures the reader/writer/
Closeable
is always being closed.Path
is basically the "modern"File
whileFiles
(note the 's') has tons of useful one-liner methods likereadString()
that simplify a lot of common operations without sacrificing performance.saveConfig()
fromloadConfig()
)This was really confusing to read, I wouldn't be surprised if there was a bug somewhere in there. To "compensate" for this, a
saveConfig()
was put in the title screen mixin, which will generate the default config on first load (and also add new enchantments to the enchantment_data.json).populateEnchantmentData()
and renameloadConfig()
toloadAndPopulateConfig()
This is to make the prerequisites for loading more clear: Other mods need to have their enchantments registered before the title screen mixin (and thereby
populateEnchantmentData()
) is executed.extract setting defaults into
loadConfigDefaults()
combine
StoredEnchantmentData
andEnchantmentData
, mark non-stored fieldstransient
, removefromStoredData()
,toStoredData()
Wanted to do this back then, this makes reading and writing the enchantment data much easier. The only thing that one needs to be careful of when using Gson or other serialization methods is that you cannot assume that constructors are being called, not even default constructors. This is basically the reason why
populateEnchantmentData()
starts with putting data intoEnchantmentData
.DEFAULT_ENCHANTMENT_COLORS
directlyMap.of()
(for up to 10 entries) orMap.ofEntries()
are just a really nice way to define immutable maps. I also usedList.of
instead ofArrays.asList
so that all values inModConstants
are immutable.I'll probably add some more comments.