warjort

See MobEffect.getDisplayName()

I still have no idea what you are trying to do. Or what you are currently doing and which part does not work. Your problem is not your grammar. Your problem is you jump randomly from block placement, to grass colors, to ladders, to terrain generation and finally to chunk loading. The one part I do understand is the last part. See the Level.getChunk() methods for querying and loading/generating chunks. On your "pseudo levels", I think you are referring to the ProtoChunk vs the real runtime LevelChunk? e.g. look at the difference in setBlockState() for them.

Have a look at BoundTickingBlockEntity.tick() The error says your BlockEntity/Ticker has not been removed even the though the block has. It is minecraft:air As to why is anybody's guess since you don't show the code. If you just post random snippets probably nobody will look at it - we need to see all the context even if you don't think it is relevant. And probably try it for ourselves. Guess: You have network packets that are trying to manipulate the world in a non-threadsafe way off the main client/server threads? https://forge.gemwire.uk/wiki/SimpleChannel#Handling_Packets

The method you are using returns an unmodifiable list in its default implementation so you can't clear it. If you want to modify the actual data, you will need to use an access transformer to make the Item.category field public https://forge.gemwire.uk/wiki/Access_Transformers But there is no guarantee the Item actually uses that field. An item can override getCreativeTags() to do something else (vanilla items don't do this). You should probably also be aware that Mojang are changing how this works in 1.19.3 https://www.minecraft.net/en-us/article/minecraft-snapshot-22w42a

This isn't something I know a lot about, and you don't show your relevant code so I have no idea what you are really doing. Anyway (guessing): Blocks spawned using worldgen/structures are not "placed" so those events won't fire. e.g. floating sand or gravel created by world gen doesn't fall. Your tick event won't fire unless you also override isRandomlyTicking() or set the property in the block properties. Why is this not a block entity if it is a special block? You can use proper ticking. I believe the correct way to do what you are trying to do is using the TerrainAdjustment/Beardifier. But like I said, I don't know much about structures, except Mojang seem to change how they work with every release. 🙂

Post a link to your logs/debug.log, your question contains no useful information. But this is usually caused by trying to use both jei and roughly enough items or jade and wthit You cannot have these together.

It's an issue with netherdepthsupdrade not registering it's worldgen correctly. As was said above, the debug.log might contain some more information about why it is isn't registered. But you should check you have the latest of this mod then contact the mod author.

Optifine issue. Check you have the correct/latest version then to speak to them.

Issue with valhelsia core. Others have said it is a conflict with optifine.

That can't be without canary, it is still crashing in canary's code Also you should post a link to the debug.log not just the crash report. So we have all the information. Finally, there is nothing we can do to fix this. This is the forge support forum. As a curtesy we can tell you which mods are causing problems, but you need to contact the mod authors to get a fix/solution.

You can use parchment to get more meaningful names: https://github.com/ParchmentMC/Parchment/wiki/Getting-Started

The issue happens with BYG placing a tree, but the actual crash is in the canary mod. You should check you have the latest version of these mods then contact the mod authors.

Looks like you are missing the geckolib mod. https://www.curseforge.com/minecraft/mc-mods/geckolib

https://forums.minecraftforge.net/topic/117667-my-error-pls-helt/?do=findComment&comment=518124

And I got the highlighted chest. I am just intuiting what it supposed to do. You haven't explained it. But anyway, it's not really my task to debug your code. I only did the stuff above because what you were talking about didn't make sense and I wanted to know why.

This is the change I made to get 1.19.2 to work: diff --git a/src/main/java/tfar/quickstack/networking/C2SPacketRequestDropoff.java b/src/main/java/tfar/quickstack/networking/C2SPacketRequestDropoff.java index 7a1d17a..ee58ebb 100644 --- a/src/main/java/tfar/quickstack/networking/C2SPacketRequestDropoff.java +++ b/src/main/java/tfar/quickstack/networking/C2SPacketRequestDropoff.java @@ -58,6 +58,7 @@ public class C2SPacketRequestDropoff { } public void handle(Supplier<NetworkEvent.Context> ctx) { +ctx.get().enqueueWork(() -> { ServerPlayer player = ctx.get().getSender(); Set<InventoryData> nearbyInventories = getNearbyInventories(player); @@ -97,6 +98,7 @@ public class C2SPacketRequestDropoff { new S2CReportPacket(itemsCounter, affectedContainers, nearbyInventories.size(), rendererCubeTargets)); ctx.get().setPacketHandled(true); +}); } public void dropOff(Player player, IItemHandler target, InventoryData data) { @@ -172,6 +174,7 @@ public class C2SPacketRequestDropoff { Level world = player.level; DropOff.LOGGER.debug("World info: {}", world); DropOff.LOGGER.debug("Is client: {}", world.isClientSide()); + DropOff.LOGGER.debug("" + Thread.currentThread()); DropOff.LOGGER.debug("Scanning x({},{}) y({},{}), z({},{})", minX, maxX, minY, maxY, minZ, maxZ); var blockEntities = BlockPos.betweenClosedStream(minX, minY, minZ, maxX, maxY, maxZ)

Use java 17, mixin does not support java 19

You will need to debug that for yourself. Maybe the chunk you are referencing isn't loaded or you have "broken" the BlockEntity in your test world during some previous testing? I've just been testing with a chest and got it to work. Try creating a new test world so you know you don't have corrupt data. BTW: "Pinging" does nothing except adding noise the thread. If it really did something I would I turn it off. 🙂

I've just been testing your 2 branches. In 1.18.2 the thread is usually already the ServerThread so it works. But this isn't guaranteed, it could be a networking thread. In 1.19.2 the thread is usually a networking thread so it fails. When I wrap your handle() code inside a ctx.get().enqueueWork(() -> { // original code here }); it is always on the server thread and so works. So it looks like you didn't change your code properly, maybe you didn't save it? NOTE: You will need to fix this for 1.18.2 as well. As I said above, this code could run on "any" thread unless you force it onto the ServerThread.

The 1.18.1 Level.getBlockEntity() also has that thread check, so I don't see how your code works there? I suggest you add some logging or use a debugger to figure out what is really happening (on both versions).

You probably want to look at "handling packets" here: https://forge.gemwire.uk/wiki/SimpleChannel i.e. making sure you run on the correct thread so you are doing things in a thread safe way and not running concurrently with other stuff on the networking thread(s)

Issue with alex's mobs Try the latest version then contact the mod author. https://www.curseforge.com/minecraft/mc-mods/alexs-mobs/files

You could also trying building from the command line if you think intellij is the problem.

No. Forge Gradle makes a "direct" connection to these files. The only information shown in the log is that the connection timed out. Error getting artifact: net.minecraft:client:1.18.1:mappings@txt from MinecraftRepo java.net.ConnectException: Connection timed out: connect at java.base/sun.nio.ch.Net.connect0(Native Method) at java.base/sun.nio.ch.Net.connect(Net.java:579) at java.base/sun.nio.ch.Net.connect(Net.java:568) at java.base/sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:588) at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:327) at java.base/java.net.Socket.connect(Socket.java:633) at java.base/sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:304) at java.base/sun.security.ssl.BaseSSLSocketImpl.connect(BaseSSLSocketImpl.java:174) at java.base/sun.net.NetworkClient.doConnect(NetworkClient.java:183) at java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:532) at java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:637) at java.base/sun.net.www.protocol.https.HttpsClient.<init>(HttpsClient.java:266) -- snip -- The way it actually works is it first accesses this file that lists all available versions: https://piston-meta.mojang.com/mc/game/version_manifest_v2.json That file points to the following link for 1.18.1 https://piston-meta.mojang.com/v1/packages/989549ecba162cba2ec066e19a2f0364586f18bf/1.18.1.json which points to the link I posted earlier to get the client mappings. "net.minecraft:client:1.18.1:mappings@txt" https://launcher.mojang.com/v1/objects/99ade839eacf69b8bed88c91bd70ca660aee47bb/client.txt Can you access each of those links? Otherwise I don't know. It is some (unknown) issue with your or Mojang's network. Or something in between. e.g. if you accessing it from work or school which has a proxy.

Please in future put your code on github so we can see all the relevant context and make it easier to try it for ourselves. The registration is working fine for me. I changed your code a bit to make it easier to use (but I don't think this makes any difference): public static final ResourceKey<Registry<VeinType>> VEINS_KEY = ResourceKey.<VeinType>createRegistryKey(new ResourceLocation(MODID, "vein_types")); public static final DeferredRegister<VeinType> VEINS_REGISTRY = DeferredRegister.create(VEINS_KEY, MODID); I also added a programmatically registered entry: Then I list the registry at server started @Mod.EventBusSubscriber(modid = MODID) public class Events { @SubscribeEvent public static void serverStarting(ServerStartedEvent event) { var registry = event.getServer().registryAccess().registryOrThrow(VEINS_KEY); LOGGER.info("------------> " + registry.key()); registry.forEach(entry -> LOGGER.info(registry.getKey(entry) + " " + entry.weight)); } Then with a data/examplemod/examplemod/vein_types/myvein.json Which gives: [09:32:27] [Server thread/INFO] [co.ex.ex.ExampleMod/]: ------------> ResourceKey[minecraft:root / examplemod:vein_types] [09:32:27] [Server thread/INFO] [co.ex.ex.ExampleMod/]: examplemod:test 20 [09:32:27] [Server thread/INFO] [co.ex.ex.ExampleMod/]: examplemod:myvein 10 I guess the onAdd() doesn't work for datapack registries because they are "vanilla" and not real ForgeRegistrys? But I might be wrong about that.