Keybounce noticed that he was having a persistent item ID conflict with
DD's Golden Doors - the normal doors not the dimensional variant. I
discovered that we have been assigning them the same ID as the Golden
Door block ever since they were first introduced 7 months ago. It didn't
break immediately since Forge adds +256 to item IDs.
* Changed saving code to create backups by moving existing files rather
than creating copies and deleting the originals.
* Removed final call to PocketManager.save() in PocketManager.unload().
Since we no longer check if the caller is the client or server and
unload() must be called from both, this prevents clients from trying to
save pocket data locally. A final save() call wasn't needed anyway.
Added a flag to NewDimData so that we can avoid writing dimensions to
disk if they haven't been modified. They're still rewritten when the
server shuts down.
* Fixed comments messed up by auto-formatting
* Minor formatting changes
* Combined two conditions in the door-placement code into an equivalent
condition
* Switched to deleting dimension data when a dimension is removed
instead of trying to figure out which dimensions were removed later
* Fixed a bug with blacklist paths
* Rearranged saving code slightly to avoid the potential performance
impact of repeated calls to getAbsolutePath()
Made saving a bit more robust, now we only delete ones that where not
modified. Also overhauled door placement, its all handled by the
eventHandler now.
Made saving a bit more robust, now we only delete ones that where not
modified. Also overhauled door placement, its all handled by the
eventHandler now.
* Changed DDTeleporter to stop us from generating exits to Witchery's
Spirit World - this would cause people to lose their items upon leaving
the dimension.
* Changed GatewayGenerator to stop us from generating gateways or rift
clusters in the Spirit World
Changed FillContainersOperation so that empty dispensers are not filled
with a stack of arrows on import. Just in case someone needs to use
empty dispensers in their design. As far as I can remember, this won't
affect any of our dungeons - arrow traps are rare. The only dungeon that
I can remember is one by Balgor and it was exported with all of its
dispensers loaded.
* Added a small treasure room that opens when the puzzle is solved and
made the exits in the corners slightly more apparent by placing redstone
lamps.
* Tweaked the redstone a little to correct for a brief signal cutoff.
* Tried to add fireworks that would shoot out when the puzzle was
solved, but it was too hard to secure them against theft while also
getting consistent explosions.
Updated the dungeon pistonFallRuins so that it causes less extreme lag
by slowing down and spacing out the timing for the piston traps. Also
reinforced the dungeon against tampering and added lava inside each
piston drop.
XombyCraft has been kind enough to research which provider and biome IDs
are used by major mods. He found some ranges of free IDs and suggested
changing our defaults to sidestep conflicts with Biomes o' Plenty.
Fixed a nasty crash to desktop. It happens when ChickenChunks is
installed and a new world is generated with HardcoreLimboEnabled = true.
It appears that ChickenChunks forces a chunk to generate in Limbo if
LimboProvider.canRespawnHere() = true, which is the case if hardcore
Limbo is enabled. Our Monolith and gateway generation code runs as a
tick handler instead of through standard world gen calls. I believe
Limbo is unloaded immediately after the chunks are generated because no
players are around. That would cause DimensionManager to return null for
Limbo because it's not loaded, which would crash our code. We probably
dealt with this for Monoliths by adding a check. Now it happened again
because we didn't take precautions while calling the gateway generation
method. I've added code to forcefully load Limbo if it's not loaded.
Changed the condition on LimboProvider.canRespawnHere() so that players
can respawn in Limbo even if LimboEnabled is false. LimboEnabled only
controls whether players are sent to Limbo when they die in a pocket. It
does not prevent players from ending up in Limbo because of Monoliths.
If Hardcore Limbo is enabled, it stands to reason that people should be
respawning in Limbo anyway.
After finally getting the dungeons to load, I've determined that only
half of the rooms should be included. The three remaining rooms should
definitely stay. That's not much for a pack so I'm going to make some
modifications to the schematics and include them as part of Ruins.
