Overhauled RIftGenerator. The code is significantly more readable now.
It's commented and much more compact. I also removed all fields from
RiftGenerator - they were unnecessary and using them increased the risk
of buggy code. Made the code rely solely on the Random instance provided
by MC, meaning our rifts and gateways will be tied to the world seed.
Tweaked the code slightly so that clusters of rifts and gateways can
never generate in the same chunk. This was previously possible, although
highly unlikely. It's a work of art now. <3
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.
Although fields were created in DDProperties for Monolith spawning and
Rift generation, they were mislabeled as reading the "World Rift
Generation Enabled" property. I gave them proper names. I also changed
the fields and names to be more intuitive and rewrote the descriptions.
For instance, "MonolithSpawnDensity" is a misnomer because as density
increases, there should be more Monoliths, not less. Now the properties
clearly state how they affect a feature. I rewrote the conditions that
used each property to correspond with those simplified descriptions and
gave the properties default values that will match the generation rates
seen before.
I also made the rift generation code less cryptic and fixed a bug; there
was a check that compared if a dimension was a pocket dimension by its
name to prevent rift generation. That name check was wrong - it would
never work. Now we check if the provider is an instance of
pocketProvider. That will continue working even if we change the way
that pocket dimensions are named.
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.
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.
