I modified the way SchematicLoader handles blocks with metadata.
Previously, we would always copy metadata over without additional
checks. If we converted a mod block into Fabric of Reality, metadata
would have no effect because FoR did not have subtypes. Now that FoR has
subtypes, loading metadata blindly could cause unexpected effects, such
as generating Ancient Fabric instead of FoR. I changed the code so that
we only count a block as "changed" if we change its block ID and we
don't want to preserve the original metadata. In that case, the metadata
is set to 0.
Changed transformMetadata() from a public instance function to a private
static function. I was curious as to whether it was being used by code
outside SchematicLoader. The code compiles so it must be local-only. In
the future, when we switch from using this function to the rotation
class, the compiler will warn us that this function is no longer being
used. Then we'll remember to remove it.
Renamed block 1973:1 to Ancient Fabric. Renamed block 220 to Eternal
Fabric. I assigned new names so that we didn't need to use the long ones
we had before (e.g. "Fabric of Reality Permanent/Pushable"). Also
removed unused imports from various classes along the way.
Removed unused import from DDProperties. Changed argument lists of
CommandDeleteRifts, CommandDeleteAllLinks, and
CommandDeleteDimensionData to read "???" since we want to get this
update out and those commands are used infrequently. We'll fix them to
have proper information for the next update.
Made some minor changes such as removing unused imports and fixing up
code to remove warnings. Stop calling static methods as if they were
instance methods!!! @_@
Removed a comment from SchematicLoader.transformPoint() that is no
longer relevant. It refers to counterclockwise rotations even though our
rotations are commented as clockwise now.
Rewrote the code that changes the position of a tile entity to be
expressed in the schematic coordinate system. The new code should be
equivalent but easier to understand.
Added support for exporting tile entities as part of custom dungeons.
I've produced a schematic as a test that shows items are exported
properly and they're recognized in MCedit. I still need to add support
for loading tile entities in imported schematics.
Changed DungeonHelper.exportDungeon() to use Minecraft's NBT tag classes
instead of using JNBT. The implementation is actually slightly simpler
than our original JNBT version. I also fixed a bug in the way the
extremes of the bounding box search were calculated that caused yEnd to
have an incorrect value. Exporting works properly now. Confirmed with
tests.
Fixed the selection of boundaries for custom dungeons. The code had a
bug that would clip off a portion of dungeons during exporting. Also,
permafabric is not used to mark the edges of the dungeon anymore. That
means dungeons can contain permafabric now without getting cut off, and
the permafabric shells will be included as part of the export.
Changed SchematicLoader so that schematics that have entrances that are
not facing North will still be rotated properly. This involves a
workaround for transformMetadata() since it assumes schematics are
always saved "facing" North.
I've tested this and it's working perfectly, with one exception. If you
create a rift with dd-rift to a dungeon that wasn't saved pointing
North, the rifts sometimes appear beside the player, instead of in the
block where the player's head is. Sometimes you'll appear in the dungeon
facing the right way. Other times, you'll appear inside a wall adjacent
to the entrance or near the entrance facing the wrong way. I have not
managed to narrow down why this happens.
Rotations in SchematicLoader are understandable now. I changed all the
code to use transformPoint() and made sure that the rotations in there
are correct. Testing shows that rooms are being generated correctly. I
also edited portions of the code for clarity and removed some debug
prints. The loading process now allows permafabric to generate - it was
previously converted into regular fabric of reality. For the moment,
the code is stuck to assume that the entry direction is North. I'll
remove that constraint in the next commit.
