warjort

As it says in your log This appears to be a known issue: https://github.com/ToroCraft/ToroHealth/issues/131 As one person says on the bug report,

Read the sticky post at the top of this forum.

There are a few methods available. There is AABB which lets you calculate an intersect(). For the entity you would just use entity.getBoundingBox(), the other one would be whatever part of your block you want to check. There is a pretty complicated entity.collideBoundingBox() that lets you pass an intersection of shapes. Or you could just do your own (optimised?) calculation based on the entity.getBoundingBox()

Overwriting vanilla blocks can break other mods that have used mixins to do more refined changes to them. Using mixins is another way to get the behaviour asked for on this thread. But it means it will only work for the blocks that have been modified in advance while the original poster wants to define them dynamically using tags.

If you do use that approach, I think you want to further iterate on chunk.getSections() to avoid looking parts of the chunk that are just void/air and are not really there.

Spitballing: An alternate approach (not using random ticks) would be write your own WorldTickEvent handler that randomly changes blocks. Your world tick handler would iterate over the loaded chunks and choose random blocks in each, applying whatever logic you want. The issue is how to know the loaded chunks. This would probably involve some book-keeping on your part where you keep track of this yourself using the ChunkEvent.Load/Unload event?

How would minecraft know to call code on a block that doesn't exist yet?

You can do additional checks yourself in that method.

If you don't like mixins you can always use an access transformer.

The dropItem is only for when your block lands on say a fence and turns into a item. It doesn't stop the block getting placed otherwise. There doesn't appear to be an event where you can handle this. The one thing that behaves like you want is the Anvil and then only if the anvil's damage goes to zero from fall damage. This all hardcoded by mojang. If you use a mixin accessor to change the private field cancelDrop to true it should do what you want (that is what the anvil code does).

AFAIK, there is no general event for random ticks on any block? The only thing I can see is forge's CropGrowEvent which only applies to StemBlocks.

It looks like you really want to know when an entity is attacked from your code? You might be able to do some tracking yourself with forge's LivingHurtEvent and looking at the DamageSource. Maybe storing the state using a Capability on the entity?

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.