Quote from Divinius
As Mike_Lemming pointed out a few posts above yours, this mod adds features that aren't in the older mods. And yes, if someone "re-invents the wheel" but does it in a much better way with more features and stuff, then yes, it should be promoted. Big-time long-standing mods that everyone already knows about don't NEED to be promoted. Small ones like this, that few people have ever heard of, but that may actually be BETTER than the big-time mods, are exactly the type of thing that should be promoted.
Of course, I agree on that. =) I just didn't get the impression that this mod does anything novel relative to the others.
0
The current best version is in the OP. There is no ETA. I'm considering shuffling our plans around to speed that up, but even so, it's likely not going to be 2 weeks.
1
I believe that you're running a development version of Dimensional Doors, not a recommended version. The specific version that you downloaded is not ready to be used. If you want to test out the newer features we mentioned recently, you should use version 2.2.4-350. Otherwise, please use the recommended version (2.2.4-349) available on the first post in this thread.
0
No, they don't reset. They're just like normal pockets. Although I'll note that there are commands for server admins to wipe dungeon pockets, so on servers, it's not necessarily safe to build a house inside a dungeon. If you did do that, you could protect that pocket with a Golden Dimensional Door. A loaded pocket cannot be deleted. Also, you would want to make sure that you have direct access to that pocket, since the preceding rooms in the dungeon would be removed and the room could become unreachable.
0
0
No. Currently, it would be impossible, because the data for any links leading to a door is completely separate from the data of the link starting at that door. We can't efficiently search for those inbound links to modify them. Yes, the mod could be changed so those searches could be done, but then just allowing that could be used to interfere with links that you shouldn't be able to modify.
Even if you could move links pointing into the door, the door's link wouldn't move with it. Supporting that would require additional changes to how the mod works, so that doors can tell that their links are in the wrong spots and attempt to move them. Overall, given the risk of bugs involved, I'm not sure I'd ever want this to be possible. Perhaps I could take the risk for the MC 1.7 version.
I'd really recommend against moving doors with mods right now. As other people have posted, the results can be unpleasant, although nothing should crash.
0
Nope.
1
Given recent discussions about how DD handles dungeons, it might be a good time for me to ask for volunteers for something. It would be good to have some help with building a set of dungeons following a particular theme. This is somewhat secret, so anyone who's interested in knowing more and volunteering can ask me via PM.
0
I believe he has stated things: http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/1287583-dimensional-doors-v2-2-3?page=196#c3945
Also, you can't be that guy. He came by a few weeks ago: http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/1287583-dimensional-doors-v2-2-3?comment=3890
0
Doesn't matter, as long as you export with DD. It'll correct all the block IDs before storing the schematic. Consider that we have to do the same when we load up any dungeon too. Otherwise things wouldn't work on servers with altered IDs. It won't correct IDs of things inside containers, though. Hopefully you aren't filling chests with Rift Blades. =P
Plus that would be an issue with servers that are configured not to have Rift Blades as loot.
0
It crossed my mind. I think the reason we don't do it is because it might be problematic whenever we update the mod and add more dungeons, or change them. DD would have to be able to differentiate between dungeons that were changed by users, or removed, and dungeons that were edited in the mod itself or didn't exist before a certain version. On the plus side, this JAR-changing stuff only has to happen on the server. Clients don't need access to dungeon schematics.
You might be able to override the default dungeons by placing folders with the same names in the custom dungeons folder. I'd need to look at the code again to see how I handled that conflict, but I might've specifically made it so a conflict gives priority to the custom files. I know I wrote a comment somewhere in the loader describing this scenario.
0
Excellent. I think a lot of people don't consider that because they expect that internal dungeon packs must be hardcoded - that they wouldn't have a config file like regular packs. Fortunately, that's not the case. Bundled dungeons use the nearly the same functionality available for custom dungeons. You could even change the default dungeons by fiddling around with the contents of the JAR file and then repackaging it, without changing the code.
0
Yes... It is.
0
Please read the guide at this point. =P
0
Yep. I tested. They can probably see through any liquid.
0
Houses can be built up to 3 rooms deep with this scheme. The Entrance can lead to MiddleRooms with more doors, or EndRooms that should have no more doors. You could also make Entrances and MIddleRooms without additional doors, to make single-room or two-deep houses. The rules could be tweaked in various ways, such as adding weights to the Entrance rule. While you could change the MiddleRoom rule to read "MiddleRoom -> MiddleRoom EndRoom", that might create deep houses with many levels, which would prevent the DuplicateSearchLevels setting from working. Also, if you exhaust your pool of EndRooms, then the system might choose a Village at random. So I don't recommend creating loops like that.