Replaced all instances of Hashtable in our code with HashMap. I had
never given that much thought until Steven mentioned it. HashMap is a
better alternative for our code.
Tweaked the code that copies the dungeon export tutorial. I'm not sure
it worked all the time before. It didn't seem quite right. I've
confirmed it's working better now. Also cleaned up copyfile a little.
Separated exportDungeon() from registerCustomDungeon() - exporting a
dungeon no longer automatically registers it. Also changed
exportDungeon() so that it returns a boolean indicating success or
failure, instead of an instance of DungeonGenerator that was never being
used. I modified CommandEndDungeonCreation so that it can warn you if
exporting the dungeon failed (if exportDungeon() returned false), and
also, to register the dungeon after it's exported since it's no longer
automatic.
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.
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.
