Fixed a bug in DungeonPack that would trigger a rare ClassCastException
during dungeon selection. We were comparing instances of DungeonType
against WeightedContainer<DungeonType>. This wouldn't break dungeon
generation because DD falls back on selecting a random dungeon if
rule-based selection fails. It would allow duplicate dungeons to appear
in the same chain, though.
DDLoot: Implemented a custom version of MC's generateChestContents() for
our own chests. It avoids two notable bugs that affect MC's version.
FillContainersOperation: Changed code to use
DDLoot.generateChestContents()
SchematicLoader: Fixed a bug in the way we calculated a seed for
selecting our dungeons that would cause certain seeds to dominate all
the others. Under certain circumstances, the function would only return
-1. That would make our dungeon selection severely biased. That was
resolved and the code was specifically tuned for seeding Java's Random
even for doors with nearly identical positions. The result was an
apparent major improvement in the randomness of dungeons.
ruins\rules.txt: Changed the dungeon generation rules to precisely match
the complicated scheme we had before. We're still using simple rules to
choose dungeons - I used a program to derive the effective distribution
of dungeon types that the old code would produce and converted it into
the current rule system.
1. Integrated support for dungeon pack config options into the code
(i.e. we actually DO what the settings specify)
2. Added random transitions from one dungeon type to another. Dungeons
might also begin with a non-default pack.
3. Fixed a config reading bug that caused settings to be ignored and
some invalid settings wouldn't trigger exceptions. Also fixed other
dungeon pack bugs.
Added code for parsing dungeon pack config files. The settings for our
built-in dungeons are now read from a file instead of being hardcoded.
One or two settings aren't being accessed yet and we still don't search
for other dungeon packs in the custom dungeon folder. That'll come in
another commit.
Completed a basic version of configurable dungeon chains. Almost all of
the final funcionality is present. However, the configuration is
hardcoded at the moment, not read from a file. This was done for testing
purposes. I'll add reading from config files soon.
Dungeon packs are partially implemented. Built-in and custom dungeons
are currently thrown into the default pack, Ruins. The next step is to
generalize the dungeon registration code in DungeonHelper so that we can
detect dungeon packs, read their config files, and register dungeons
with their corresponding pack. dd-export will need to support packs as
well. dd-rift will have issues dealing with duplicate dungeon names
across packs, but this isn't a major concern and can be dealt with in
the long term.
Completed enough of the implementation and integration to compile DD.
Some portions of the code are only for testing and will be removed
later. The configuration for default dungeons is hardcoded - we can
parse config files once we're certain that dungeon chains work. At the
moment, dungeons generate but it doesn't seem like the rules we set are
being followed properly.
Renamed OptimizedRule to DungeonChainRule, and renamed the old
DungeonChainRule to DungeonChainRuleDefinition, to match the role of
each class better. Added some hax to DungeonGenerator to get packs
integrated - the implementation will be much cleaner once the new save
format is done.
Started implementing our support for dungeon packs. The code is not
usable yet and the mod is not functional at this stage. A few additional
changes should make it testable. A significant obstacle to implementing
dungeon packs easily is that DungeonGenerator doesn't have some
necessary information and shouldn't be modified. Even if it is modified,
old serialized instances wouldn't have the new fields initialized. I'm
having to create workarounds until we implement the new save format.
DungeonPack handles all of the logic of selecting a dungeon and
verifying whether its type is valid. It relies on DungeonChainRule and
OptimizedRule to check which dungeons should be generated next given a
list of the dungeons in a chain. DungeonType maps types in packs to ID
numbers and provides a reference to the pack that owns the type.
DungeonPackConfig will carry config information to be passed to the
DungeonPack constructor.
Added support for rotating the metadata of powered tracks and detector
tracks. Also made a minor change to DungeonSchematic to protect its
internal state.
Simplified metadata rotation code by only having a single function that
rotates metadata by 90 degrees clockwise and applying it repeatedly for
180 and 270 degree rotations. Removed flipDoorMetadata() from dimHelper
and replaced all references to it with references to BlockRotator. This
makes all our rotations reference a single function. Replaced hardcoded
rotation in DungeonSchematic.
Added support for wood (tree trunk) and quartz pillar metadata
rotations.
Converted the doors in our schematics into doors from DD. Also converted
mangled block IDs into Fabric of Reality and wiped all tile entities
from Steven's schematics to remove prefilled chests that had been
included somehow. Changed DungeonSchematic to expect mod doors now. This
means we can include Vanilla doors in our designs and they will not be
converted anymore.
This process was done by automatically re-exporting all of our dungeons
multiple times, so it serves as a good test that importing and exporting
are working properly. We confirmed by thorough testing that our
schematics load properly into WorldEdit. MCedit, unfortunately, does not
handle them right. We believe this is a bug in MCedit, NOT with us.
Made a minor change to DungeonSchematic so that it replaces foreign mod
blocks with the standardized FoR ID on export. Previously it used the
Forge-assigned ID, but since that happens after ID standardization, it
could cause us to export non-standard IDs.
Fixed the bugs that caused doors not to appear right in dungeons. First
there was a bug with filters that caused them not to replace blocks
properly. I made some changes to SchematicFilter and its derived classes
so that the implementations are a little more intuitive. That should
prevent those bugs in any future derived classes. Then doors wouldn't
rotate properly. DD was never designed to rotate dimensional doors. I
added code to BlockRotator for that and shifted some code from
DungeonHelper to BlockRotator. More coherence, less coupling!
Improved DungeonSchematic to the point that it can replace
SchematicLoader as our method of loading dungeons. Some of the code was
copied over rather than refactored to save time. It's been subdivided so
make it much more readable. Also, we can reimplement portions of it as
WorldOperations later on further remove redudancy. Testing shows that
there is one problem left to fix: door blocks are not being set up
correctly at the moment. Rifts are being set up properly and attaching
doors to rifts will show that dungeons continue to generate fine.
Added classes to support DungeonSchematic and its additional filtering
logic on import and export. SpecialBlockFinder handles listing the
entrance, other doors in the dungeon, and end portal frames.
FillContainersOperation is a WorldOperation that fills chests and
dispensers. BlockRotator is a temporary class to hold
transformMetadata() and transformPoint() until we rewrite that code
later.
Stripped out most of the code from SchematicLoader to ensure it's no
longer used. The only remaining function sets up dungeon pockets. We can
phase it out in a later version so as not to delay our release. Removed
references to SchematicLoader in mod_pocketDim since it no longer needs
to be instantiated.
Created DungeonSchematic, a class that extends Schematic and adds
DD-specific functionality such as methods for filtering the schematic's
block before importing and exporting. Testing confirms that
DungeonSchematic works well so far, although it still lacks critical
features.
Made some minor changes to Schematic and copied
SchematicLoader.setBlockDirectly(). I realized during testing that
setting blocks without using that function could cause problems. First,
it's possible that the blocks would not be placed if chunks weren't
created. Second, there are issues with blocks updating if we use World
to set them, even if block updates are disabled. That causes some
torches to break and other weird problems.
Added classes to support block filtering operations applied to
Schematic. These are used to implement ID standardization and removing
mod blocks when importing.
