Another person was having trouble getting their structure mod to work as it kept crashing on a server. They were using worldgen json (template pools) and it works perfectly in single player. But when launching and running a server, the json never gets parsed.

I ported my tutorial mod to 1.17 to see. And sure enough, the template pool registry never gets the entry for the json file. Thus crashing my mod on servers.
https://github.com/TelepathicGrunt/StructureTutorialMod/tree/1.17.x-Fabric-Jigsaw/

I did a quick test and slapped in a biome json to override the Plains biome and make it purple with cactus. I comment out my structure, launch the server, connected to it, and sure enough, the Plains biome is not purple and doesn't have my changes. Thus, it is clear worldgen json is not being read when launching a server despite it working back in 1.16.5 and in 1.17 single player.

This bug is going to keep a lot of mods from being able to update to 1.17 as it effectively means running the mod on a server is a crash.

More testing, the dimension and biome jsons do work. just template pools aren't and I double check to make sure that their format did not change. Plus the fact that loading template pools and putting it into the registry is working in single player and is something that my mod and others do not handle. It's what vanilla is suppose to do when given the mod's data folder.

I launched a dedicated server outside dev with no mods on and just this datapack:
test.zip

The Datapack overrides the Plains Village center pool to spawn a small house. First I ran the Fabric server without fabric API and it works. Then I ran it with Fabric API and now the pool overriding failed to apply. Thus we can conclude the issue is Fabric API and not any sort of Mojang code.

Without Fabric API

With Fabric API

This is actually the same issue I was having in #1471. Something in the networking module in fabric api seems to be overriding all biome modification. If you run your datapack without this module the villages spawn correctly.

Some people might have already noticed, but its not just fabric mods with worldgen json. Datapacks with custom worldgen stuff also break because of fabric api. So fabric "api" is breaking vanilla features that work in vanilla server. And it happens even without any mods that use fabric api. Not very nice. This doesn't affect my server much because I only had one mod that needs fabric api. I still think this issue is very bad.

For example this datapack that is supposed to add some 1.18 features to 1.17 gets broken just by having fabric api on a fresh fabric server. The datapack is supposed to add lush caves and dripstone caves, but with fabric api it doesn't.

Hmm, so for networking, this datapack override works when networking api is removed while other independent apis are present?

Yes, I have found that after removing the networking api, and keeping all the other independent apis intact the datapacks load there respective structures / biome changes.

Luckily I have a 1.17 plain loader environment set up. I shall carry out a test with the networking api immediately.

Networking alone does not cause the problem in #1478 (comment).
Also changing biome sky color (changed desert sky color to badlands foliage color) works with only networking api

So something is missing here. Are you having the api on the server and using vanilla client or using api client connecting to vanilla server? Or just playing a local game?

the API has to be on the server for it not to work.

Hmm, tested with biome and dimensions standalone and they seem to not be the cause. With the full API though, this appears broken indeed.

However, for the sky color one, I cannot replicate it with full api (I changed plains sky color to badlands foliage color and it works just fine in superflat preset world (faster generation) on fabric server). @MrTalk Mind share a setup of yours?

Another potential criminal would be the resource api; I recall it caused problem with mod tags. What others do you think can be the culprit?

Dont use the superflat/single biome worldtype. The fixed biome source (single biome) is broken and doesn't properly handle biomes which could be messing with your testing. Use MrTalk's datapack but use default worldtype to check the biome to make sure the issue cannot be reproduced.

Hmm, interesting!

So for MrTalk's improved cliff and cave pack: I want a seed and a given location that has lush caves biome. The vanilla locatebiome command cannot find rare biomes like the badlands, so this fixed seed would allow more reliable testing.

Hmm, so it's a vanilla client to a fabric server?
These are the scenarios I am thinking about:

Game type:

• integrated server (client local world)
• dedicated server with fabric api, vanilla client

API type:

• only base (required dependency) and networking
• dimension and its dependencies
• biome and its dependencies
• full API

My current guess is the biome or dimension apis' injection system might have broken this. Same may be said for loot table, where mods can modify player-specified loot tables unexpectedly.

Is there any other configuration to test against?

My test involved launching a fabric server with fabric api. Put the datapack I linked here onto server. And then connecting with a fabric client. But since worldgen is handled entirely serverside, that datapack will always break on server with fabric api regardless of who is connected

So this only happens with dedicated servers and not with integrated ones (local singleplayer games)?

Yes, it works with singleplayer. Test on a server. (test with runServer)

Hmm, if both are replicated with a fabric dedicated server and a fabric client, then they are still disjoint problems:

1. Will test the biome color again, using the changed desert color (patched https://www.planetminecraft.com/data-pack/caves-amp-cliffs-expansion-pack-20w20a-compatible/)
2. Will test your provided test pack.

Hmm, when testing your provided pack with only loader and no mods (only fabricloader 0.11.3, java 16, mc 1.17), it seems that your provided pack appears in the datapack list; its structure is loaded but the structure pool appears not.

Can you test and check if this (or both problems) happen with only the loader, without the API?

it works with loader and no fapi

I was not able to reproduce this with Fabric API 0.34.10. I created a world in singleplayer with these datapacks datapacks.zip , one of which combines the Mojang caves and cliffs pack with the caves and cliffs expansion pack linked above. I then moved that world file over to the server, and launched the server with fabric API and Lithium.
I spotted no chunk borders, was able to see cave biomes in newly generated chunks. The other dimensions were able to generate properly and the overworld's custom biome distribution was preserved.

Have you tried creating the world purely on the server?
Stoneholm (underground villages) has some issues so you could try using that mod on a server.

@frqnny In both Vanilla and Fabric I have issues with generating custom worlds with datapacks. I place the datapacks in the proper world folder, then generate the world for the first time on the server, yet the worldgen related datapacks are ignored until the next server start.

Is this an issue during world creation then?

To try to reproduce this, I did generate a world purely on a server without FabricAPI. As I expected from Vanilla behavior, the server didn't generate anything defined by any of the datapacks I linked above. I then restarted the server, still without FabricAPI, and generated new chunks which resulted in the generation I expected. I then restarted the server one more time with FabricAPI, and still saw the generation I expected.

I am not running into the issue the issue author is having.

I don't know where I can get individual modules to test this but we should test without networking, biome api, resource loader, and content registries. (we wouldn't be able to test with mods but we confirmed this is a data pack issue)

@TelepathicGrunt I did replicate this issue.

1. I created a world in singleplayer with the datapack, the plains village was properly replaced.
   
   

2. I created a fresh world in a server running fabric API, I then restarted the server with the proper datapack. Villages generated in the spawn chunks were not replaced, as they had no chance to be, however freshly generated villages were not replaced.
   

3. I then restarted the server on the same world without running FabricAPI, generated new chunks, and the villages were properly replaced again.

@dewbsku Download this datapack
test.zip

Test it on single player. Go to a plains village. It will be the custom house. Make a world on server with fabric api. Close server after world is made. Put the datapack into the world's datapack folder. Launch server so it reads datapack. Go to a new plains village. Datapack did not take effect as village is still vanilla village instead of the custom house. The template pool failed to replace on the server.

Maybe MrTalk's situation is different or flawed but this template pool issue does exist and is easily reproducible with my instructions as shown in my picture

Someone please provide a seed+location for this, plains villages are super rare, especially with fabric api test mods enabled.

This should reproduce the issue easily:

1. Download and load the incendium nether datapack on a server: https://www.planetminecraft.com/data-pack/incendium-nether-expansion/
2. Run /give @s jigsaw{BlockEntityTag:{joint:"rollable",name:"starmute:floor",pool:"starmute:castle/floor_l1",final_state:"minecraft:basalt",id:"minecraft:jigsaw",target:"starmute:floor"},display:{Lore:['"(+NBT)"']}}, then place it oriented to the side, set levels to 7, set keep jigsaws to off, and hit generate to gen a castle.
3. Observe that nothing generates with fabric api installed and this is logged in console: [Server thread/WARN]: Empty or non-existent pool: starmute:castle/floor_l1

I've narrowed this down to the fabric registry sync module.

Edit: After further investigation, the second redirect mixin in MixinMain causes it.

This should now be fixed with 0.35.1. Many thanks for all the help with tracking down this silly mistake.

Please let me know if you have any further issues with this.