HN
Comments
Affects 20w22a. Fortress spawns fortress mobs in the inner bounding boxes, but you get regular nether mobs in extended bounding box.
Say I know a chunk that is somewhere in my structure. I'll use my world as the example. I know that chunk 209 279 is in the bounding box...somewhere. I open up the chunk with NBTExplorer and find the references. In my case, I find 2 interesting tags: "monument", with nothing in it, and "Monument", the old one with the intact integer tag.
So we open the tag in "Hex View". We see 00000000 D2 00 00 00 18 01 00 00
These are the co-ords of the origin chunk, but they are both listed in pairs from least to most significant, AND they are in "signed twos complement" form. In this first example, both coords are positive, so it's just a straight conversion. We just have to re-arrange them.
x is 000000D2, or 210
z is 00000118, or 280
[media]And if I check that chunk, I find the data including the bounding boxes.
[media]Every single chunk that has the structure should have that "References>Monument" tag, so I have to delete the existing "monument" tag that has "0 long integers" and rename the one named "Monument" to "monument". Again, this must be done for all chunks that contain the bounding box. This is going to take a long time for a nether fortress. It has a lot of chunks in it
And for that origin chunk, I just have to rename the parent folder in Starts>Monument to "monument". ALL of the information for ALL the corridors and crossroads and rooms in a nether fortress is contained in that one chunk, so at least this part is easy.
–
My monument was an easy example because the coords were both positive. Now for a negative example. I have a pillager outpost that is in the chunk -268 -52. When I check the reference tag, I get.... 00000000 F4 FE FF FF CD FF FF FF.
I ain't the greatest at working with negatives in signed twos complements, so I just looked up a calculator real quick. https://www.rapidtables.com/convert/number/hex-to-decimal.html
reading right to left again, x coord is FFFFFEF4 which the calculator tells me is -268 in decimal. Ok
y coord is FFFFFFCD, which calculator tells me is -51. Ok.
So it turns out that the origin for this outpost was in the chunk next to it, -268, -51.
–
For a third example is a reference that shows 00000000 8A FF FF FF 0C 01 00 00.
Bunch of F's means that the x is negative and the z has 0s so it's positive. Read the two coords in twos complement hex as FFFFFFA8 and 0000010C, plug em into calculator and get -118 268.
Honestly, I'd wait for mojang to fix this bug before upgrading to a later snapshot, but I've left these examples here in case they are helpful. This work-around is complex and tedious, and should be done on a backup of a backup in case something goes wrong.
Managed to fix a pre-21a monument with the following steps:
Looked up the chunk coordinates (not block coordinates) of the structure, and checked which region file it exists inside. Then double checked that that chunk had a Monument tag in structures>references. Example: In my world, there was a monument which covered many chunks, including 209 279.
I had to run the reference tag through a hex converter to figure out which chunk was the monument's origin. In the references>Monument tag of chunk 209 279 was the decimal string 1202590843090, which means it was looking for information about the monument in chunk 210 280. (1202590843090 translates to 0x118000000D2. D2 is hex for 210 and 118 is hex for 280)
I went to chunk 210 280 and found the information for the monument in structures>starts>Monument. This is how ALL structures work. The information about the bounding boxes, their layout, and shape is always found in the [starts] folder of chunk that is the origin of the structure during generation. All other chunks in which the structure exists have a tag in [references] that says "yeeaaaa. check the starts folder of the origin chunk found at #### for information about a structure that exists in my chunk"
I renamed the structure>starts folder from Monument to monument.
I then looked up the block coordinates of the bounding box to find the opposite corners of the structure, looked up what chunks those correspond to, and painstakingly renamed all the [references] tags from Monument to monument, making sure that they still pointed to chunk 210 280. I had to do this for every single chunk in which the monument exists, including the chunk with the origin. Note, I had to delete the existing lowercase monument tags that had nothing in them, since the game complains if there are duplicate tags:
And that's it. I got my guardian temple back and both its capacity to spawn guardians and its capacity to not spawn any other hostile mob.
Basically, this proves that it is possible to restore structure functionality for structures that already exist. But it's a method that requires you to tinker with game files which is dangerous for anyone who doesn't know what they are doing. Plus it is tedious. Even for something as small as a guardian temple. Imagine fixing a nether fortress.
If mojang is insisting on making all structure names lowercase, then the game needs to automatically convert existing structure data without modifying it; maybe in the "Optimize World" menu.
This is NOT a duplicate of MC-184740. This bug appeared in 20w20a/b, or last week. 184740 only started this week due to the changes in structures using all-lowercase. Newly generated structures in newly-created chunks in 20w21a do properly spawn mobs, but fail to spawn mobs in the nether fortress extended bounding box. This is not the same issue.
Also, to add, this command DID work in 1.13 to make paintings invulnerable, preventing careless players or ender pearls from breaking them. I cannot remember at what point this bug popped up, but it has been present ever since.
Can confirm, fortress mobs will only spawn inside the "room" bounding boxes now, and on top of this, non-fortress mobs are now able to spawn inside the extended bounding box. This behavior is different from how these structures behaved for the last 8 years.
Can confirm. I used to make my paintings invulnerable to prevent them being destroyed in adventure maps. At some point in either 1.14 or 1.15 running a command similar to one specified in the bug report resulted in the behaviour as described. Not all paintings would pop, but some would (including some 1x1) and in many cases they would simply disappear without dropping as an item.
This is an intended texture. The quartz brick is meant to resemble english bond bricklaying, and not resemble stone bricks.
Depending on how the mod or datapack is created, the custom head may ask the skin server what the head should look like. There are ways to have the head store its own texture (and thus it will not change its texture), but that's something you/your server admin/the datapack maker/the mod maker need to sort out
Following up. Nothing in the change log pointed to fortresses being able to start generating in every biome, but now there are other things to consider.
I rendered the same seed in 20w16a. Fortresses as rare as in 20w15a.....but now there are bastions and ruins which also need space to generate (and can generate everywhere), and so the density/rarity of fortresses seems to make sense now. Attached a render for comparison to previous versions.
[media]Is 20w16a affected? I don't know. It partly depends on how mojang wants the nether to look like, and it partly depends on someone in the community identifying an extreme edge case. I certainly didn't add 20w16 to the list.
Just wanted to expand a bit with a bit of data. Here are 2 images of the seed -8263492127909406043 as seen through MCA selector. This program allows you to render and see what is already generated and does not affect natural world generation.
This is the seed in 1.15.2: There are 9 fortresses that generate within this area. This is roughly 1800x by 1000z.
[media]This is the same area in the same seed in 20w15a. There are only two nether fortresses that are able to generate (top right, middle bottom[hard to see though])
[media]
Essentially, in this example, it is an 80% reduction in the density of fortresses, which is quite severe. (Although admittedly abstracting from a SINGLE data point is never a good idea). The reduction would make sense if it is making space for new types of structures, but at this date, this is a rumor.
The behaviour in your world is exactly as described by Slicedlime. The origin point for the fortress in your seed is at 3395 -4744, give or take 4 blocks. (The origin point for all nether fortresses is in that room with the lava "well")
In 1.15.2, as expected, that entire chunk occurs in minecraft:nether
In 20w06a, and 20w09a that chunk occurs in minecraft:warped_forest
Fortresses cannot generate if their starting points are in warped_forest or crimson_forest, as described by Slicedlime. You will sometimes see those fortresses in those biomes, it is because they began generation in nether_wastes or soulsand_valley and expanded into an adjacent biome.
So this is the behaviour expected of the world generator.
=====
Do I personally think this behaviour is detrimental and should be considered a bug? Personally, yes. It has the potential of being a severe restriction in how common nether fortresses are. The warped forests and crimson forests are fairly common biomes, and there is not much harm in having fortresses generate inside them. I also think the fortress bounding box should override the spawning restrictions of the biome in the same way that spawners work normally in a mooshroom biome, phantoms spawn in a mooshroom biome, and infested blocks will still generate in a stronghold in a mooshroom biome.
However, I recognize that at this point that this is on the fence between a bug report and a feature request.
[media]I guess it would appear so. The fortresses' starting points all appear to be in crimson forest biomes. I guess this one can be closed then.
My world was converted directly from 20w15a to 20b, and then pre4 and 7 (Meaning that I skipped the problematic 21a). My structures are all fine.
For you to fix your world, there are a few options:
Upgrade your world from 1.15.2 or any snapshot prior to 21a. DO NOT use 17a. That one was also buggy as heck.
If the structures have never been built on by you, and you just want them to work, delete the chunks which contain the structure and it will regenerate normally. World generation will put the same structure in the same place in the overworld. I don't recommend this in the nether. Nether generation has changed several times. This can be tricky because some structures (like outposts) are much bigger than they look like in the game files.
If you built some kind of farm, you can save the structures with structure blocks, delete the chunks, regenerate the area, and then paste the structures back in using structure blocks. Alternately, you could use a mod like litematica.
You could manually edit the files themselves.
Note that mojang likely did not intend to fix every possible way that this issue occurs, because their main focus is to make sure that a transition works between stable versions, meaning 1.15.2 -> 1.16. Snapshots, on the other hand, are unsupported; hence warnings by the devs about only playing snapshots on backups of your main world, warnings about them being buggy, warnings about potential to damage world, and warnings about the inability to downgrade.