Minecraft Version

1.18.x

Version

1.100.0

Details

When I place turtle, add coal, and run comant tunel it crash
crash-2022-01-11_10.15.32-server.txt
.

Can we get this in a curaeforge release please? Would love to update my modpack with this fix.

Will get one in a day or two, bit usy with life

This looks like an incompatibility with the "adventure" library mod. Not sure what is the right way to fix it, but I will look into it.

I am getting the same crash. over and over again in the official servers for my modpack, AQM2

This is an issue with ComputerCraft's implementation of fake players not exactly matching the behavior of real players unfortunately. It's happened in a few other mods -- see gnembon/fabric-carpet#1142 for one example.

This is one of the many things that are pretty easy to miss when implementing fake players -- to avoid the issue in the future, I'd like to see Fabric API implement fake players. See FabricMC/fabric#1980 for my issue on that side. I'm hoping someone with relevant experience will have the time to contribute a fake player API, which would give all mods using fake players consistent behavior that library mods such as adventure-platform-fabric can reason about.

A fake player api would be a nice thing long term, but in the short term could adventure-platform-fabric implement a null check for the channel and pass on tracking players with null channels? I could make a stub channel implementation for our fake player, but I feel that is likely to just bring up more bugs further down the road. I'm not familiar with what adventure is doing so if this doesn't make sense let me know.

I'm not really interested in working around issues with a billion different fake player implementations. If you and other mods that work with fake players can agree on some other common API that's not Fabric API, I'd be willing to adjust around that and whatever its quirks are, the same way I would for Fabric API.

However, I already know of 3 separate fake player implementations, there are likely more I haven't heard of yet, and it's not sustainable to throw workarounds in when that much fragmentation exists in the implementation of the same concepts.

From my browsing, I see that both create and computercraft are incompatible because of this lack of null checking on your end. Carpet mod implemented a fix that I will investigate. However, I believe their fake players are supposed to have some level of networking, whereas ours would ideally have none. So, their fix might not apply to our situations (or create's).

Ultimately, a fix on our end would involve much more work than adding two null checks on your end. The null checking on your end would also fix both outstanding incompatibilities in one go. So if carpet mod fixed it themselves, and you add null checking for computercraft and create, that would cover all the billion 3 fake player implementations in question.

I looked into the issue with Carpet mod and the fix that was done. It's the exact same problem as Create and ComputerCraft. While the fix would would work here, it has the same end result as Adventure null checking and passing on null channels. If your mixin breaks three mods all in the same easily fixable way, it should be on you to fix that.

Mojang quite clearly indicated in the package-info that the channel field is non-nullable. If you choose to violate the contracts provided by Vanilla, that's on you to fix, sorry.

I'm not really interested in working around issues with a billion different fake player implementations. ...I already know of 3 separate fake player implementations, there are likely more I haven't heard of yet, and it's not sustainable to throw workarounds in when that much fragmentation exists in the implementation of the same concepts.

There have been three fake player implementations so far, and all were supplying a null channel (it makes sense for a fake connection). That is a strong trend and not "fragmentation" from your mod's perspective. The broken contract is no big shame to me when we're working outside Mojang's code intent. I think the way you are exaggerating the circumstances is very silly. Nonetheless, I will implement the same fix as Carpet to close this issue. Thanks for linking to their thread.