Mod Name

CustomNPCs Unofficial

Mod Homepage

https://www.curseforge.com/minecraft/mc-mods/customnpcs-unofficial

Minecraft version

1.21.1

Logs

The latest.log is here, and you really don't want it (it's borderline unreadable), but the debug.log is here.

The issue

There's actually two issues with this mod.

The first one you will encounter is its AWs failing to load and hard-crashing the game.
This is actually because the mod for whatever reason is shipping an ancient mcmod.info and accesstransformer.cfg — if you go in and delete those the mod will load further.

The second one involves networking (yes I know, everyone's favorite).
If you now load into a world you'll find that the mod 'works' — all of its items are there and besides some strange bits in the logs the mod looks like it's fine.
Looks can be deceiving though and in fact all of the mod's packets are broken; if you grab an NPC Wand, place an NPC (by right-clicking the wand on the ground) and try to right-click it with the wand, you'll find that the GUI that normally opens doesn't. Instead, you're presented with an empty list in a different interface.

I spent hours investigating this issue and originally chalked it up to FFAPI networking jank but it looks like it's a different kind of jank.
The log contains many instances of lines like the following:

[net.minecraft.client.multiplayer.ClientPacketListener/]: Unknown custom packet payload: minecraft:customnpcspacketsync
[net.minecraft.client.multiplayer.ClientPacketListener/]: Unknown custom packet payload: minecraft:customnpcspacketnpcupdate
[net.minecraft.client.multiplayer.ClientPacketListener/]: Unknown custom packet payload: minecraft:customnpcspacketnpcedit
[net.minecraft.client.multiplayer.ClientPacketListener/]: Unknown custom packet payload: minecraft:customnpcspacketguiopen

The problem (as far as I understand) is that all of these packets are in the minecraft domain — a ridiculous concept that some may even call 'taboo'.
The reason these payloads are 'unknown' is that NeoForge assumes all minecraft packets are not modded, and hands them over to vanilla.
Vanilla, of course, has no idea what a customnpcspacketsync is, and proceeds to make it everyone else's problem.

To verify that this is the problem, I wrote the following mixin to give the packets non-minecraft namespaces:

@Mixin(CustomPacketPayload.class)
public interface MixinCustomPacketPayload {

	@Inject(at = @At("HEAD"), method = "createType", cancellable = true)
	private static void survivcompatfixes$fixCustomNPCsPacketIds(String id, CallbackInfoReturnable<CustomPacketPayload.Type<?>> cir) {
		if (id.startsWith("customnpcs"))
			cir.setReturnValue(new CustomPacketPayload.Type<>(ResourceLocation.fromNamespaceAndPath("customnpcs", id.substring("customnpcs".length()))));
	}
}

Applying this mixin completely fixed the issue, confirming that the issue is indeed the minecraft namespace.

Since (I assume) the mod works on Fabric, it seems that FFAPI needs to catch any packets that make it to the unknown payload stage, check if they're secretly known packets, and then force NeoForge to process them. Alternatively, it could relax the non-minecraft requirement, although that might have unintended side-effects for NeoForge mods.

As for the earlier problem, I'm not sure what can be done about it — I guess Connector could hide the accesstransformer.cfg from FML when loading Fabric mods (since they should never contain this file anyway)?