Repurposed Structures log spam
While being in the nether my logs are spammed full of this warning message:
[23:35:10] [DH-World Gen Thread[0]/WARN]: Repurposed Structures: Detected a mod with a broken basalt columns configuredfeature that is trying to place blocks outside the 3x3 safe chunk area for features. Find the broken mod and report to them to fix the placement of their basalt columns feature.
I reduced my mod list down to this on 1.20.2:
- Distant Horizons
- Fabric API
- MidnightLib
- Repurposed Structures
I had this happen on the Iris build as well.
I found a potential solution to just set the log file on read only or somehow stop Minecraft from logging. But I would prefer to still be able to use the logs.
35 Replies
Sounds like the issue is that Repurposed Structures is doing feature generation incorrectly or something idrk. Maybe you can try reporting it to them as well?
Yes I was planning to if I didn't get much from here. But I asked it here because it only happens when DH is active.
no, it means RS detects other world gen mods with a broken generation
probably do a binary search on world gen mods, but with RS installed to check which one trips that error
/binary
Try a binary search and figure out which mod is causing it.
So disable half of the mods, see if issue is still there, if yes disable half again etc etc until you find the mod that's causing the issue.
Distant Horizons
Fabric API
MidnightLib
Repurposed Structures
This is the full mod list.
Maybe it's just RS but it seems to only happen when both DH and RS are installed
I tried without DH tping to a basalt biome and upping the render distance to 32 and it didn't happen
Maybe it missed the structure I could try again
With DH it happens after a few seconds in the nether
weird
unless RS detects some shortcuts DH made for world gen tasks and freaks out
cuz DH has to use MC vanilla world gen code to gen LoDs
That seems to be possible. At the start I tried using a python script to figure out what mod was causing it by just reading every file for basalt columns and variations but I didn't find anything. I'm pretty sure basalt columns are a vanilla structure.
I could try using the script to see if I can find the file that's generating the warning but I think it's probably compiled so it probably wouldn't work
if RS got github page, perhaps edit source
ohh good idea
yung's better dungeon just fixed the similar error, you could look there then see with RS
I'll look into it and report back! thank you!
oh wait yeah I'm blind
I thought that was DH error message for some reason
ohhh I see. it's RS complaining in a DH thread.
I've been talking to the RS Dev: "The only way my logging happens is if the basalt feature is being generated for a chunk BEFORE structure starts are generated for a chunk which should be impossible. Unless the placedfeature’s start point is being placed outside the currently generating center chunk for the generation stages
Idk if this helps anything
According to the dev the fix from yungs just stops the logging but not the issue?
It's not just RS. Yungs generates the exact same warning for some reason https://github.com/YUNG-GANG/YUNGs-Better-Dungeons/issues/62.
GitHub
Issues · YUNG-GANG/YUNGs-Better-Dungeons
Minecraft mod that adds actual dungeons to the game - Issues · YUNG-GANG/YUNGs-Better-Dungeons
Could it be that the worldgen code checks the generated chunks to see if the structure starts are generated but since they are only generated in lod it trips?
RS Dev:
I am going to the chunk itself and asking the chunk it’s chunkstatus
If the chunk says it’s status is before structure start, I print out the log message
Geesus Christ, the faq validation is the worst I have ever seen my god
Anyway, I’m the dev of repurposed structures
Minecraft worldgen is done in a specific way that no features should generating in chunks BEFORE the chunk passes the structure start phase
This means this should never be able to be triggered
https://github.com/TelepathicGrunt/RepurposedStructures/blob/8c0e38008be4ed2984a151437bb3928741bb6cfd/common/src/main/java/com/telepathicgrunt/repurposedstructures/mixins/features/NoBasaltColumnsInStructuresMixin.java#L37
To the dev of distant horizon, how exactly does that mod work. Did you put something out a week or more ago that is somehow generating features in chunks without promoting the chunk status of the chunk? If so, why? That shouldn’t be possible and greatly concerning to me.
@James Seibel (GMT-6)
I’m not the one who built that part of the world generator but structure start should be done long before features.
https://gitlab.com/jeseibel/distant-horizons/-/blob/Data_Source_Rewrite/common/src/main/java/com/seibel/distanthorizons/common/wrappers/worldGeneration/BatchGenerationEnvironment.java#L620
Unless something got goofed up where the chunk’s state isn’t being set after said step (which is possible).
GitLab
common/src/main/java/com/seibel/distanthorizons/common/wrappers/wor...
This is a mod that adds a Level Of Detail (LOD) system to Minecraft. This implementation renders simplified chunks outside of the normal render distance allowing for an...
That seems to be what is happening. Chunk is not updating to the new status. I adjusted my logging to print out the chunk status, the placefeature, and the stacktrace
The logging code
@Hencoat (Renowned Author) pulling you here so you dont need to check other discords for updates
Thanks @TelepathicGrunt, appreciate you being so proactive about this!
I should probably ping the Cataclysm dev as well since his mod is doing the same thing
The bug is Distant Horizon is generating the chunks through their stages but the chunk's chunkstatus is not being updated as it does so.
The logging worked as it was pointing out a possible bug/issue
I just checked each stage of DH's world gen and we are updating each chunk's status.
Unless
ProtoChunk.setStatus is the wrong method or there's some other conflicting issue I'm unaware of.
Is the chunk you're updating, the same chunk from LevelAccessor when given the same chunk pos
like same instance
Wait… what levelaccessor is that? Is that the actual MC level or is that whatever the world generator has access to?
it's the levelaccess that is passed to the placedfeature's generate methods
In this case, it should be
DhLitWorldGenRegion regionHmm. Then those chunks should be updated with the DH world gen. Unless you’re trying to access chunks outside of DH’s range (I don’t remember what happens then, we either return null or an empty chunk).
Where are the chunks you’re pulling relative to the generating chunk?
I inject at head of canPlaceAt to detect when the basalt feature is about to be in bounds of my structure to cancel its generation.
https://github.com/TelepathicGrunt/RepurposedStructures/blob/8c0e38008be4ed2984a151437bb3928741bb6cfd/common/src/main/java/com/telepathicgrunt/repurposedstructures/mixins/features/NoBasaltColumnsInStructuresMixin.java#L31
Vanilla's basalt feature does count on every layer which has a 0-15 spread built-in
https://github.com/misode/mcmeta/blob/d24ffa5d56a7859f960914f256fb1694b8e8dbaa/data/minecraft/worldgen/placed_feature/large_basalt_columns.json#L5
And the basalt feature itself has a 2 to 3 spread
https://github.com/misode/mcmeta/blob/d24ffa5d56a7859f960914f256fb1694b8e8dbaa/data/minecraft/worldgen/configured_feature/large_basalt_columns.json#L9
So technically the canPlaceAt can be given a position up to 2 to 3 blocks outside the currently generating chunk. In vanilla worldgen, this is ok as the surrounding 8 touching chunks (3x3 chunk area centered on generating chunk) are all at or past the CARVERS chunkstatus iirc. Vanilla has to do that because stuff like trees or ores or anything bigger than 1 block wide ends up bleeding into side chunks due to the 0-15 block x/z randomization most placed features have can put them right on the edge of the currently generating chunk.
I could just not log anymore to stop the spam. But I don't know what the future consequences could be of ignoring that the surrounding chunks could be in the wrong chunk status as lots of features and mods could be making assumptions about those side chunks that Empty status could possibly break.
Well DH already breaks a couple large assumptions that world gen mods make (feel free to correct me on these my knowledge is from 1.16):
- single threaded execution
- the existence of adjacent chunks in the level (since the world gen area DH uses is 4x4 chunks)
Since DH doesn’t save anything to MC’s region files I’m not worried about accurate world gen (it just needs to be “good enough”), speed is generally more important. So if we have weird world gen that isn’t an issue in my book.
That being said; I could look into returning empty chunks with the expected generation step for anything outside of DH’s generated section (4x4 chunks). That might help with your specific issue.
The reason I had the chunkstatus check originally was because Terralith or some other worldgen datapack mod was using basalt features. But messed up the placement modifiers so the basalt feature was trying to generate outside the 3x3 chunk area. Which causes my
structureManager.getStructureAt call to crash (or was it a deadlock? Can't remember)
So I got irritated and added the chunkstatus check with logging to track down the problem mods/datapacks which worked and got them fixed. So ideally if you return chunkstatuses that matches the center chunk, it should prevent issues with people who may not have the chunkstatus check but are calling structureManager.getStructureAtFair enough. I’ll see what I can do.
#progress-update
I'll remove the logging on my end too since there hasn't been a basalt issue since that one time that drove me nuts.
I took a look at returning empty chunks with the current world gen status and that looks like it's likely to cause a lot more issues than solve.
If you want to keep your state check then I'd recommend using
getChunk(int chunkX, int chunkZ, @NotNull ChunkStatus chunkStatus, boolean returnNullIfChunkDoesntHaveStatus) and setting returnNullIfChunkDoesntHaveStatus to true and adding a null check.
That way you can differentiate a missing (un-generated) chunk vs a malformed chunk.