Removed a line in CommandEndDungeonCreation that inserted a new dungeon
directly into DungeonHelper.customDungeons. This had a chance of causing
a duplicate listing. registerCustomDungeon() was already being invoked
before and if reading tags from the file name failed, the dungeon would
get added twice. This could explain some of the buggy dungeon listing
that would appear during testing.
Changed the function to use a Hashtable mapping dungeon types to their
respective lists so that it wouldn't be necessary to hardcode a
condition for each type. The code is much shorter now and we can add new
types with ease. The next stage will be to remove
weightedDungeonGetList, if possible, so that we don't have to construct
a list with duplicates just to have weights. The loop that repeatedly
inserted dungeons into that list has been removed anyway, but it
shouldn't affect anything since custom dungeon integration was broken
and weights were being ignored.
I changed the name filter for schematic names from
CommandEndDungeonCreation to DungeonHelper, and renamed it to
NamePattern. I also rewrote most of registerCustomDungeon() to be much
more concise. The changes are incomplete but I'm making an intermediate
commit. The aim is to change DungeonHelper into a proper singleton and
to eliminate the clunky sections that manually map dungeon categories to
their corresponding lists. Instead, I'll use data structures to
implement that far more efficiently.
Set various lists of DungeonGenerators to private - there was no need to
make them public fields. While cleaning up the code before, I
accidentally erased the default constructor, which handled loading a
reference to DDProperties. I've put the code back in so that the class
works correctly.
I was able to infer that HashMap schematic should have generic
parameters <String, Tag> and changed the declaration accordingly. All
generic collections in DungeonHelper are now parameterized properly.
Cleaned up the indentation and empty lines in DungeonHelper. Set
metadataFlipList and metadataNextList to have generic type Integer,
since they're used to store block IDs. Whenever possible, we should
always be using parameterized collections instead of leaving their types
unspecified. I'd like to fix up the schematic HashMap in the future -
unless it's necessary, we shouldn't be storing values of various types
in that collection. Strongly typed variables or a class with the
appropriate fields would be much cleaner.
Changed the formatting in DungeonGenerator. Autocorrected indentation
and removed extra empty lines to improve readability. None of the
variables were changed since that would break compability with previous
serialized instances.
Changed SchematicLoader to use DDLoot.DungeonChestInfo instead of
requesting a reference to the same data through ChestGenHooks. Exactly
the same data is being retrieved, but ChestGenHooks retrieves it by
performing a lookup on a map relating loot categories to loot info, so
it's slightly slower. No point in doing that if we have access to the
reference directly.
Decreased the weight of DD items very slightly to make them a little
more rare. Added a section to DDLoot.mergeCategories() that searches for
the enchanted book loot and fixes its weight to 3 (instead of the usual
1). This makes enchanted books slightly more common. I confirmed that
books are actually spawning in loot chests. There is the possibility
that there is a built-in chance of an enchanted book taking up a chest
slot but not actually generating anything.
Added a regex filter for bad schematic names in
CommandEndDungeonCreatoin. Names can only be made of letters, numbers,
and underscores now. This should prevent any nasty tricks people might
try to affect the underlying file system.
Changed DDLoot to use the correct item IDs when adding DD items to
chests. Moved loot chest registration from init() to postInit() in the
hopes that we'll be able to catch the loot of other mods that also hook
into Vanilla chests.
Dimensional dungeon loot chests are now registered with Forge. Other
mods can tap into our chests and our own generation is cleaner. The list
of items in our chests is generated in DDLoot.
Corrected typos in the names of two properties. Added properties for
toggling each item in our mod as dimensional dungeon loot. These
properties are not being used yet, but my next commit will actually
integrate them.
Fixed null DDProperties reference in DimData. Changed the code so that
it requests an instance in each of its functions instead of relying on
loading a reference when it's first instantiated. I'm not sure how the
null references are slipping through, that shouldn't be possible.
Moved all configuration variables from mod_pocketDim to DDProperties
(formerly DimDoorsConfig). Changed property names to be clearer in
config file, modified some comments, and generally cleaned up the config
file. Fixed some missing properties and variables that were reading from
the wrong properties. Modified the order in which mod_pocketDim
instantiated some of its static fields so that they would load after
properties are read. Almost all classes load after properties are read.
Fixed indentation across various files and replaced references to
properties in mod_pocketDim with references to DDProperties.
Added flag for disabling whether Stabilized Rift Signatures are
craftable. Autocorrected indentation in some areas. Renamed some
property keys in the config file, but the naming is inconsistent. Will
return soon to make all names consistent. Property values should be
removed from mod_pocketDim and moved to a file, e.g. DDProperties.
Configuration should either be loaded directly into the value variables
or be kept as a separate file, e.g. DDConfiguration. I favor for
integrating configuration reading into the same file as the values and
not declaring Property variables at all.
Changed the names of property variables in DimDoorsConfig to follow
better variable naming conventions. Removed a duplicate config.save()
call. Noticed that crafting Stabilized Rift Signatures can't be disabled
in the config file, will be adding that option in the next commit.
General note: we need a better way of handling item configuration.
Metaprogramming in Java would be a godsend.
