Naming chest for replacement.

[MikeyCarter]

Had a case where mcdungeon placed it's creation in such a way that corner overlapped with an existing structure. Any time I regenerate mcdungeon it wipes out the chests/signs of that structure.

Was thinking would it be possible to custom label the chests created by mcdungeon and thus only replace them?

Not sure how it can handle existing mcdungeons but the would stop this sort of thing from happening to others in the future.

[orphu]

Odd that it overlapped in the first place. Adding a tag would be a good idea for handling chests at the surface. Anything inside the underground chunks will be removed pretty much no mater what.

[sshipway]

Might be connected to the cache freshness issue where a user builds a new structure in a chunk previously cached as available, then deletes a dungeon elsewhere, causing the cache time to be updated so that when a new generate is done, mcdungeon does not realise that the cache needs to be rechecked and thinks this chunk is still available...
Another possibility (with villages etc) is that the structure extends into the chunk, but simply does not have any of the blocks which mark the chunk unavailable (eg torches) in that chunk. This would be rare but possible, depending on what the 'structures' setting has been set to, since the default checks for glowstone, wooden door and glass in a village. You could possibly workaround by adding chests and signs to the 'structures' setting in the mcdungeon config file and deleting the mcdungeon cache file, though this would also exclude unexpected chunks due to hidden chests and signs placed by minecraft itself.

This is my previous comment on the caching issue; it is in the thread discussing the KeyError which it turns out not to be related to: #256 (comment)

[orphu]

Ah, yes, that should probably be a separate issue. #265 is specifically for the KeyError generated by the button mechanism in secret rooms that happens occasionally.

It's possible this issue could have been caused by that. @MikeyCarter would need to say for sure.

[MikeyCarter]

Here's the area the got hit... small structure my daughter built. (signs were the first thing to catch my eye)

Here's X-Ray under it.

Also my bridge above got hit.

But the main reason for the enhancement. What if I now want to put a chest down anywhere above the mcdungeon? Any regen is going to wipe it out. If the placed chests had a custom tag then I can continue to build above the mcdungeon.

[sshipway]

With MC1.8, the new types of wooden doors probably need to be added to the 'structures' setting, since they won't be recognised otherwise. This may have been enough to protect your daughter's building. Adding droppers/furnaces etc could also be a good idea (as they don't generate natuarally in minecraft). This would solve your main problem of MCDungeon using chunks that contain preexisting structures, though it wont help with preserving selected changes done to the world after placement during a regen.

MCDungeon regenerates simply by regenerating over the top of whatever is there, so changes to a chunk will always be lost when you regen a dungeon. This would be expected since you don't want to preserve any other changes you've made... allowing chests to be preserved could be problematic if some of them are placed where there used to be a block.

From what you say, it sounds as if the sign and chest blocks are preserved (IE not overwritten) during a regen, but the block entities (sign wording and chest contents) are lost... this seems odd to me and might be an error in the underlying library? Is there anything in the regen code that explicitly deletes all block entities I wonder?

[JiFish]

With MC1.8, the new types of wooden doors probably need to be added to the 'structures' setting, since they won't be recognised otherwise.

These were added with 86273d1

[sshipway]

I missed that one! However it's not clear if the OP is using a recent enough version to include that update.

It is also possible that the OP's structure overlapped the edge of 2 or more chunks and it was just unfortunate that the door was in another chunk, so part of the structure was overwritten.

[MikeyCarter]

What happens if a user builds a structure in the chunk above and already placed mcdungeon, and you regenerate? Or the person is mining and places a chest above/below the corner of a mcdungeon, and you regenerate.

I was suggesting using the custom names tag or something to identify the entrance chests/signs of mcdungeon instead of clobber 0-256 blocks in the chunk.

[orphu]

I think it does clobber everything in the chunk, which could probably be fixed to only clobber things inside the dungeon itself. If you place a check below the corner (inside the dungeon) it will be destroyed. No way around that really.

[MikeyCarter]

Checking only on the entrance and inside the dungeon would definitely work. Probably simpler than the naming idea I had.

Also by default adding lit-pumpkins to the structures: check might be good. You have glowstone and Sea Lantern, but lit-pumpkins are easier to obtain when embedding floor lighting under carpet. (something I use all the time)

[JiFish]

Also by default adding lit-pumpkins to the structures: check might be good.

We definitely need to do this. Actually, I am surprised it is not there already.

[orphu]

I don't see a good way of fixing this one. regen will clobber everything in the bounds of the dungeon, and any other chests within the chunks of the dungeon.

Building structures inside the dungeon perimeter if you intend on regenerating the dungeon is not recommended. If you build there then don't regenerate or delete or it will destroy your structures.

[MikeyCarter]

Curious why naming the chest wouldn't be a good way to fix this. If the MC dungeons all have custom names in the NBT tags you can identify which chests are for mc-dungeon to touch and which one's it should leave alone. In 1.9 I think there's even this new tag feature.

[orphu]

I think Name tags get displayed for most entities (even if hidden is set), which is weird. I'll test that with chests. But it happens with items in item frames.

1.9 tags might work... correct me if I'm misunderstanding it, but we can set arbitrary key -> value pairs on things and Minecraft won't strip them out, right?

[JiFish]

My worry is this will lead to confusion and feature bloat. That is, "if my chest was kept - why wasn't my hopper kept?" And the like. Really, you should just expect anything in the dungeon's area to be destroyed on a regenerate. Maybe the real solution is do ensure a larger gap between dungeons and detected structures. But of course, that can never account for stuff the's built after the dungeon is generated. Just my £0.02.

[MikeyCarter]

Wow two people with the exact same thought. wink

My only thing was mcdungeon missed a pre-built house and put itself under it. So any chests in there on a regen was also included. Preventing it from happening again was already addressed.... but regular users wouldn't know the actual boundaries of the dungeon. (one reason I haven't put mcdungeon in my 1.9 world yet. Don't want a road check point or future house development to collide)

So really what I'm looking for is to have mcdungeon only update items in the dungeon or in the entrance. Not 0-256 block on the entire chunk.

[JiFish]

Wow two people with the exact same thought. wink

Accidentally used my work account. D'oh.

[sshipway]

I think getting MCD to avoid structures built after generation when doing a regen could be more trouble than it is worth, because (as mentioned) people will wonder, if it avoids X then why not Y as well? - and then wonder why the things they wanted removed were not, and so on.

A separate ticket I entered, #334 to store the random seed with the dungeon, might help here as it would then regenerate with exactly the same dungeon, so you could potentially have the option to not reset the chunks - and anything extra added would then be preserved.

Might also be a good idea to add Farmland and JackOLanterns to the excluded blocks, as this will help avoid Villages and user structures. Adding EndPortal blocks will also help avoid Strongholds.

[orphu]

JackOLanterns are there in dev branch. Farmland is a good addition. Strongholds are lit by torches, so they should be fine.