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.
It turns out my earlier commits didn't completely fix things because
certain implementation details were missing. I had assumed they were
done. Also, some of the information I had regarding the default
schematic orientation was wrong. This commit remedies most of those
problems with a robust rotation implementation. However, I haven't added
the code for linking Warp Doors yet, and there is a bug with tile
entities getting reversed in East/West oriented rooms. Not sure why
that's happening.
It turns out that rotation hadn't been implemented in the code I moved
during my last commit. I've changed things slightly to implement
rotation. I also renamed some coordinate variables to prevent confusion.
Fixed reference to CommandRegenPocket - should be CommandResetDungeons.
Autofixed indentation in SchematicLoader. I wanted to commit that change
before doing any more code changes but I forgot. Then I fixed the code
that calculates the coordinate offsets so our dungeons rotate right. It
was pretty simple - all I had to do was move the xCooe and zCooe
calculations into the loops so they're recalculated to account for
rotation. I rearranged the loops for optimal performance.
Temporarily patched up CommandDeleteAllLinks,
CommandDeleteDimensionData, and CommandDeleteRifts so they'll compile.
I'll be fixing some things for Steven and I'll come back to those
classes to finish overhauling them.
Improved CommandPruneDimensions. Cleaned up the code and improved
performance by using a HashSet instead of an ArrayList to list dimension
reachability. Added an optional argument that sets whether we should
delete the folders of pruned dimensions.
Renamed CommandRegenPocket to CommandResetDungeons. Changed command name
accordingly. Added a message for the user listing the number of dungeons
that were reset. Modified DimHelper slightly to add support for this.
Added error condition if user specifies arguments for the command.
Made progress on overhauling and prettifying our commands. There are
still more changes to be done for this to be functional. I need to do an
intermediate commit because I want to merge in recent changes by Steven.
Improved code in PocketGenerator. Restricted Monolith generation to the
chunk in which populate() is being applied. We should not be generating
Monoliths outside that chunk. Changed condition that would exit the
function if the next available space for a Monolith was above Y = 245.
Exiting the function at that point made no sense.
I've realized that this placement algorithm has probably been patched up
several times and that's resulted in nonsensical code. For instance, the
loop continues as long as you continue finding higher points to place
Monoliths. That would suggest you intended to make columns of them. But
since the loop chooses random columns on each iteration goes back to Y =
0, you're really just jumping around and placing Monoliths in random
places, while using irrelevant checks to decide whether to continue. I
really recommend coming up with a different algorithm. I haven't
replaced it completely in case it would break something.
