warjort

I am saying there is no data to access for entity/entity collisions, minecraft does not track it. And doing an entity search during rendering will likely affect fps.

Your mod works fine for me with a production server and client. But I can get the same error as the one shown in your log if I try to connect to a production server from a client started with gradlew runclient I guess there is a difference in the network packets sent by dev and production versions that means they cannot to connect to each other? I don't know if this bug or expected behaviour, I have never tried it before? BTW how is your .git 1G in size? 🙂

Do you know a good example? I just tried to find a good example in well known mods and they seem to use a variant of the RegistryEvent/manual register like botania, except mekanism which has its own specialised FeatureDeferredRegistry implementation.

Pretty sure it does it that way because it shares the same code with the fabric implementation which doesn't have deferred registration.

It depends what version of forge you are using. The old way (1.18 and before) is to use BiomeLoadingEvent. Then use event.getGeneration().addFeature() to add it to the appropriate GenerationStep. For an example, here is Botania adding mystical flowers and mushrooms to the vegetation step https://github.com/VazkiiMods/Botania/blob/0cfa08ebb4828aa48b3231d6db6dd3b70dc7942b/Forge/src/main/java/vazkii/botania/forge/ForgeCommonInitializer.java#L250 Of course you need to register your features to make them useful, see https://github.com/VazkiiMods/Botania/blob/0cfa08ebb4828aa48b3231d6db6dd3b70dc7942b/Xplat/src/main/java/vazkii/botania/common/world/ModFeatures.java 1.19 (still in beta) has overhauled this to use BiomeModifiers:https://forge.gemwire.uk/wiki/Biome_Modifier

You can override BlockBehaviour.entityInside() on your block to detect this. Look at BasePressurePlateBlock (activates the plate) or BaseFireBlock (sets entity on fire).

Entity.horizontalCollision is for colliding with blocks. Minecraft doesn't really do entity/entity collision, except in special cases like item pickup. Those are not events with state stored in the entity, its a special process that uses one of the level.getEntities() search methods. Those won't be appropriate to call during rendering.

This is not a forge issue. You have a problem with your java installation. You should reinstall it, but java 7 is very old. Too old for the currently supported forge versions, 1.16.5 needs java 8 and later versions need java 16 or 17 Curseforge has an option in the minecraft java settings to automatically download and use a java version that is suitable for the version of minecraft used by the modpack. Enable that and see if it fixes your problem.

If you can reproduce the problem somewhere else, post the log from when you try to place the block. It might show an error or other useful information.

There is no error in that log you posted. One thing to try is to move your enchanting table and book shelves to somewhere else. Say 100 blocks away. Or just create a new world and see if you have the same problem. If that fixes your problem then there is something wrong with that chunk where you have the enchanting table. The fact you originally noticed the problem when it didn't respond to you placing a block and the enchanting table is not recognising the book shelves suggests it is not a graphical glitch. It sounds like a "ghost block" but mojang are supposed to have fixed that problem, and usually relogging fixes it anyway. It is caused by the client and server disagreeing on whether a block exists in a location.

This is happening in your constructor when you register with the EventBus. Forge is examining your class and it is finding a reference to ClientLevel either in one of your fields or method signatures during the classloading. It might not be direct, it could be referencing one of your other classes that needs to load ClientLevel. Obviously, ClientLevel doesn't exist on the server so it crashes. The usual way to solve this is to move the field or method to a different class that only gets referenced/loaded from inside your client method.

There is no such event on the client side. See this old discussion: https://forums.minecraftforge.net/topic/66022-playereventplayerloggedinevent-doesnt-work/ for a workaround. Basically you can detect when a player enters a dimension.

You need forge 42 or before.

https://forums.minecraftforge.net/topic/113073-minecraft-crashes-saying-error-javalangillegalstateexception-render-layers-can-only-be-set-during-client-loading/ at the bottom.

https://forums.minecraftforge.net/topic/113073-minecraft-crashes-saying-error-javalangillegalstateexception-render-layers-can-only-be-set-during-client-loading/ at the bottom.

You probably want to read this? https://github.com/thedarkcolour/KotlinForForge/blob/1.x/README.md

minecraft 1.16.5 needs java 8 not java 17

Now you have a conflict between DataFixSlayer and LazyDFU, you can't have both. DataFixSlayer is probably the one you want to remove. Again it wasn't in your original modpack. Do you remember which mods you added to the modpack? If you are going to add mods to a modpack, it is better to do it one by one so you can easily see which of them are compatible.

NOTE: I never looked at this before, this is my quick assessment. The answer to your question is kind of complicated and inconsistent. Some places use entity.getY() -1.0D while the main LivingEntity.getBlockPosBelowThatAffectsMyMovement() uses getBoundingBox().minY-0.500001D So if you are not a full block, it will probably look at the block below, but not always if you are bigger than half a block. How the boat handles friction is a different story. 🙂 Overriding is probably difficult since the checks are calculated using the entities location to find the relevant block. This is only indirectly related to your block given that the entity will be standing on top of your bounding box. This means there is no place where it looks at your block during the calculation.

So the opposite of what I said. 🙂 I wonder how many other modders don't realise code executed directly in the setup event is potentially not threadsafe? It kind of breaks "the principle of least surprise". The only mention in the javadoc is a throw away "This is a parallel dispatch event". You might not appreciate what it is telling you since it just looks like a redundant restatement of the parent class. The ParallelDispatchEvent has no javadoc itself explaining how it works. I'd always assumed ParallelDispatchEvent was an "executor" for parallel work, given the methods look like they say they "queue work on a parallel dispatcher", hence my misunderstanding above. -- End Rant --

Here's an example of Botania spawning a pixie (you can ignore the bits about the sword and the potion effect). https://github.com/VazkiiMods/Botania/blob/f419d200f480515d596125c078f59fe868513ea0/Xplat/src/main/java/vazkii/botania/common/handler/PixieHandler.java#L77 NOTE: How it must be done on the server side. !player.level.isClientSide

Pretty sure sulfuric and radon are both ports of phosphor. You won't be able to run them together, e.g. they can't both redirect that method. https://github.com/Asek3/Radon/blob/663c52618a07d1c8fb62111be8a49e5ce5000f5b/src/main/java/net/caffeinemc/phosphor/mixin/client/world/MixinClientWorld.java#L20 https://github.com/Someone-Else-Was-Taken/Periodic-Table-Reforged/blob/351d42880003941a1eebd3b41a769da287c4bede/Legacy Phosphor/src/main/java/me/jellysquid/mods/phosphor/mixin/client/world/MixinClientWorld.java#L21 I don't see radon in the modlist of your original modpack (better minecraft plus), so I guess you can remove that mod?

As I understand it, it is used to run setup tasks in parallel (including with other mods in the same loader stage) if you have something that takes a long time. Using it for simple tasks like that simple rendertype registration likely takes more work in terms of the overhead of scheduling the tasks on different threads? And like you say, it could cause problems if the code being called is not threadsafe. setRenderLayer() is a synchronized method added by forge so it wouldn't cause an issue for that.

You already have them downloaded in your mods folder jei-1.16.5.7.7.1.152.jar and RoughlyEnoughItems-6.5.436.jar You need to remove one of them.

The environment variable the OS uses to find executables. echo %Path%