Fixed rifts not moving correctly when moving dungeons to stay inside
world bounds
Regular pockets stay in world bounds.
RiftRegenerator no longer NPEs
Fixes#48, #63
Changed SchematicLoader to use new dimHelper functions to move links
around. This should have allowed us to shift dungeons safely.
Unfortunately, Minecraft still crashes, so the link functions aren't
working as advertised. Please figure out what's going on. >_< The code
is done, it's just link issues that prevent it from working.
Completed changes so that our code uses registerDungeon() (formerly
registerCustomDungeons() ) to register all dungeons, both bundled with
the mod and custom ones. Made some changes to the code to hide
implementation details from other classes. Also, I had some problems
with old dungeons being mixed into the renamed ones. I had to remove
fallingTNThall from the schematics folder and deleted the WIP folder
because I think we have completed versions of those schematics already.
Some of our dungeons have pre-filled chests and the contents are more
generous than our current loot system (e.g. ruinsO has a prefilled
chest). I'll have to wipe all the chests later.
Forgot to fix a reference to DungeonHelper in CommandCreateDungeonRift
during the last commit. Made some further improvements to DungeonHelper
to avoid exposing internal variables.
Removed hardcoded references to all our internal dungeons. The code will
be replaced by reading from a list in the next commit. Renamed
customDungeons to untaggedDungeons and removed registration of tagged
dungeons into that list. Now all tagged dungeons (custom and internal)
are listed in registeredDungeons. Fixed the comparator used to sort
dungeon names so that it sorts them case insensitively.
We now check whether structure generation is allowed. This can be
configured on servers and when creating single-player worlds. If set to
false, Rift Gateways will not generate. Rift clusters still generate.
That was an intentional feature - we could make the setting disable
those as well if we want.
DDProperties will now throw an exception that should crash Minecraft if
the user tries to use invalid block IDs for worldgen blocks. Should save
everyone some suffering.
Added code to SchematicLoader to adjust the Y coordinate of the
destination link into a dungeon before the dungeon is created.
IMPORTANT: The code is commented out at the moment because it causes a
link-related NullPointerException. A link needs to be updated through
DimHelper but the code is hard to follow so I've decided to just not
touch it - Steven will have to do it.
The function adjustDestinationY() checks if the given entrance location
would place any portion of the dungeon outside the vertical bounds of
the world. If so, it corrects the location while moving it as little as
possible from its original place.
Also added some checks to make sure that any schematic we load has an
entrance door. Otherwise, load defaultBreak instead. And I cut down on
the absurd number of compiler warnings in dimHelper. <_< Stop accessing
static fields as instance fields!
Added validation to SchematicLoader that prevents dungeons beyond
certain maximum dimensions from being loaded. Our current limits are the
same as the largest dungeon we could export. Rewrote
generateDungeonPocket() to handle that possible failure better.
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.
Fixed bugs and made minor changes to Schematic. I've tested that it
works properly now. It still needs to perform additional DD-specific
functions and must be integrated to dungeon importing.
Improved the Schematic class. Added support for reading schematic files.
That functionality still needs to be integrated and tested. Made minor
changes to WorldOperation and its derived classes. Also fixed a few bugs
in Schematic's export functions that were found during testing. The
exporting code still doesn't do all the changes (e.g. block
standardization) that had been implemented before.
Separated part of the dungeon-exporting logic into a new class:
Schematic. Also created a few classes to implement important operations.
Some parts of the original exporting logic are missing now, such as
mapping certain blocks to standard IDs. That will be reimplemented in
the future. Importing schematics is not supported yet. I need to test
what's done so far.
Renamed MobObelisk to MobMonolith. Renamed LimboSkyProvider and
PocketProvider to have Xs at the ends of their names. This is temporary
so that I can change the name's capitalization. Windows considers the
names the same because it's file naming is case insensitive.
Overhauled the way in which CommonTickHandler triggers tick-based
actions such as Limbo decay, spawning Monoliths, and regenerating rifts.
Now CommonTickHandler implements an interface called IRegularTickSender,
which indicates that it will periodically call on classes that implement
IRegulatTickReceiver to perform some task. I added classes for each
regularly scheduled task we were performing: MonolithSpawner and
RiftRegenerator, plus converted LimboDecay to a normal class instead of
a static class. Modified several classes so that they have access to
the MonolithSpawner instance to request MonolithSpawning when needed.
This improves the structure of our code and gets us away from the way we
did things before, which was accessing a public static list inside
CommonTickHandler from other classes and adding arrays to specify chunk
coordinates. We should not be exposing the internal state of classes
like that! And we should be using clearly defined objects to pass
information.
Moved CommonTickHandler into the ticking package in preparation for the
next change. Renamed CommandStartDungeonCreation to CommandCreatePocket,
since creation pockets of variable sizes will be its future role now
that it's not strictly necessary for exporting. Renamed
CommandEndDungeonCreation to CommandExportDungeon, since we no longer
have a dungeon creation process like before.
Minor change. Renamed all the functions in LimboDecay to begin with
lowercase letters, as is the usual style for Java development. It
slipped my mind for some reason. Uppercase starting letters is the usual
style for C# development.
Removed the code in DungeonHelper and CommandEndDungeonCreation that
would force the player to use "override" with when exporting dungeons
that DD did not recognized as having been built in custom dungeon
pockets. This restriction is no longer necessary now that we don't need
pockets with standardized orientations or Eternal Fabric boundaries.
Added support for the doMobSpawning game rule. Jaitsu requested this so
that he could disable Monoliths while testing the mod. I think it's a
fair idea - you can't disable Monoliths without also disabling every
other mob except the animals.
Added an interval to CommonTickHandler so that fast decay operations are
performed less frequency. The previous rate was unnecessarily fast. This
will also reduce the performance impact of fast decay considerably,
although testers did not report any noticeable performance decreases.
Reimplemented Limbo Decay in two forms. Firstly, Unraveled Fabric
accepts random ticks now and has a 50% chance of searching the 6 blocks
against its faces for blocks to decay. The average time for this decay
to occur is about 2 minutes and 17 seconds. The decay progresses a
little slowly because of having to go through stages. We might want to
consider decaying straight into Unraveled Fabric, or at least having
fewer stages. This approach is better than randomly decaying isolated
blocks because it looks like decay is spreading from the Unraveled
Fabric.
Secondly, every tick, we pick a random block from each active section in
Limbo and turn it into Unraveled Fabric immediately. Note that a section
is a 16x16x16 block cube inside a chunk. This is "fast decay", and it's
meant to stop players from avoiding Limbo decay by building floating
structures. It's not immediately obvious if you place a single block,
but if you build a 5x5 block platform, the average time for some block
to get converted drops to about 8 seconds, and it spreads from there.
Most of the logic for this is in a new class: LimboDecay. It's worth
studying whether this new implementation affects Minecraft's
performance. I'm not completely sure whether that would be an issue. The
frequency of either decay type can be decreased to improve performance.
Removed the code associated with Limbo decay from EventHookContainer,
LimboBlock, and CommonTickHandler. DimHelper still has blocksToDecay
since removing it could cause deserialization failures. However, nothing
should actually use that list. I also removed several unused or
redundant methods (e.g. overriding methods and putting in exactly the
same code as in the super class), fixed indentation and renamed cryptic
variables. We should have a rule against allowing cryptic variable names
like "par2", even if they're inherited from Forge. I'll implement proper
limbo decay in the next commit.
Fixed a bug in DungeonHelper that could cause dungeons to get clipped
during export if they extend past Y = 127. We used
world.getActualHeight() to obtain the height of the pocket, which should
be 256, but getActualHeight() returns 128 for dimensions with no sky.
Pocket dimensions are set to have no sky, so this becomes an issue.
I believe I've fixed the cause of a NullPointerException that some
players have been experiencing. It seems to have been caused by
unregistered block IDs being present in Limbo. Possibly because people
removed mods and they had generated structures in Limbo. Or the players
had placed blocks and then removed the mods, or changed block IDs
around.
This fixes issue #47.
Added code for SchematicLoader so that hoppers will rotate properly.
This was probably not considered an issue before we had support for tile
entity exports and imports. Now it's critical that we support hoppers.
There are other blocks that are still not supported - we should really
fix this in the future so that all blocks will rotate. The code for this
is overly complicated - we should look into a simpler method.
Fixed Ancient Fabric and Eternal Fabric being vulnerable to explosions.
I also noticed that a lot of DD blocks have unusual stats. I'm not sure
whether those stats were assigned intentionally or simply because of
copying and pasting code, but the values are certainly counterintuitive
when you consider some of the block materials.
