Partially overhauled our command classes. Added DDCommandBase - it
extends CommandBase and acts as a new base class for our commands. It
removes a little redundancy in our code and provides increased
convenience. Removed the static fields for our commands in
mod_pocketDim. There was no point in keeping them when nothing was using
them. Changed in-game command names to be shorter yet relevant.
Converted all commands to singletons so proper instances can be
retrieved if necessary. Migrated some of the custom dungeon start/ending
logic to DungeonHelper and made customDungeonStatus private. Except for
data objects, we shouldn't be exposing state variables like that without
any kind of checks. I've rewritten the code in some commands but it's
been quite tiring. Still need to fix up lots of things.
Optimized the selection of random dungeons with weights applied. We now
have a class called WeightedContainer for taping into Minecraft's
weighted selection code without having to extend the WeightedRandomItem
class. Using that, we no longer need to keep a list with duplicate
dungeons to achieve weighted selection, so I removed that variable.
Fixed the bug that caused the dungeon creation tutorial to be listed as
a schematic. We were listing all files in the custom schematic directory
as a schematic, even though that file wasn't. I added filtering so that
we only look at files that end with ".schematic". Also improved dungeon
listing by sorting the name list in alphabetical order. That makes the
list much easier to read through.
Added a workaround so that the dungeon list produced by
CommandAddDungeonRift does not have repeated names. Also cleaned up the
code a bit - it's a mess in there. Part of the rewrite eliminated the
bug that caused some dungeon names to be preceded by a backslash (or
slash). I've noticed a different bug now - the dungeon tutorial file is
being included in the list of dungeons. I'll be fixing that in the next
commit.
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.
