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.
Created NewLinkData and replaced references to the original LinkData.
Moved it to the mod_pocketDim.core package. Added Point4D, an immutable
point type for 3D integer coordinates with an added dimension ID.
Added code so that the mod loads dungeon packs stored in the custom
dungeons folder. Changed the code for loading bundled dungeons so that
they're loaded as dungeon packs. This means dungeon packs are now fully
integrated into the mod. The changes were tested and seem to be working
perfectly.
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.
This is used for the code that determines where to come out of Limbo in. It tries to search from the top down to find a solid block to stand on. Isn't complete, though. This code does need some considerations put in, though... I'm concerned about Natura's clouds, for instance.
Made some changes to EventHookContainer.onWorldLoad() to remove
redundant code that encouraged bugs. Unfortunately, a lot of
link-related code needs to be rewritten to get rid of bugs, so that'll
come after dungeon packs are completed.
Changed how Random is initialized in SchematicLoader to prevent issues
with dim doors in the same chunks leading to the same dungeon. The
selection seems much more varied now. Also changed the hardcoded config
for the default dungeon chains to the one we'll be using later (from a
file). For testing purposes.
Decreased the default chance of a gateway generating. This won't affect
users unless they clear their config files. The decision is based on
user feedback and recent experiments on how common gateways could be.
Modified RiftGenerator to correct for the rarity of Rift Gateways in the
Nether. Our config settings allow us to set the probability that we will
attempt to generate a gateway in a given chunk. However, that doesn't
guarantee that a gateway will generate.
I collected a lot of data and determined that generation succeeds in the
Nether only about 15% of the time. That's compared to 30% in the
Overworld when counting oceans (which always fail) and about 75%
(sometimes higher) when traveling mainly on land.
RiftGenerator now corrects for this by multiplying the chance of
attempting to generate gateways in the Nether by 4. Gateways in the
Nether are still relatively rare and hard to find, but you'll
occasionally come across them now. Also reorganized the code a little
for clarify.
Exit doors are safer now, but only dungeon exit doors will stop you from
falling into liquids.
Doors you place in pockets you make will happily drop you into lava, but
not spawn you inside of it.
Dungeon gateway orientation fix
Removed excess .schematics and fixed one of them.
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.
