warjort

First thing to check if you have a problem with software is that you have the latest and greatest. 🙂

Have you tried doing what it says? 1) Close the ide 2) If you have started gradle from the command line run gradlew --stop 3) Use task manager or whatever is relevant for your OS to stop any java processes that are still hanging around after a few minutes Assuming that doesn't that doesn't fix it, repeat the above process then The easiest way to make sure this is not a problem is just delete the whole gradle cache YOUR_HOME_DIRECTORY/.gradle/caches This means it will redownload everything including gradle itself. There is also a .gradle folder in your project folder (note the . in front of gradle), but this is likely not relevant to this problem - you can delete it if you want

The error is caused by something taking a long on the server thread. Minecraft deliberately crashes when this occurs. There is no mod code visible for the server thread stacktrace. It shows somebody opening a chest which contains an exploration map. Minecraft then looks to be in worldgen to find somewhere where the map should point to. It could be one your worldgen mods causing this, but the crash shows it generating a vanilla buried treasure structure. So this could be a vanilla bug? NOTE: That crash is just a snapshot of what the server is doing when the 60 seconds is up. It does not show what is was doing for the 60 seconds before. You can use a mod like this: https://www.curseforge.com/minecraft/mc-mods/spark to get more accurate information about badly performing mods or vanilla processes.

This a problem with the Theabyss (The Abyss?) mod. Make sure you have the latest version then contact the author.

This is an issue with JEI make sure you have latest version for 1.16.5 then contact the author.

Look at your image. You are showing /Applications/Minecraft/Contents/mods Your mods folder is Take a screenshot of the contents of second one. Although we can guess, you have been downloading your mods into the first folder when you should be putting them in the second one.

Or even simpler, just reject re-entrant calls? private boolean inTick = false; @Override public void tick() { if (inTick) return; inTick = true; // Your code inTick = false; }

Click on the link above about capabilities and read it, in particular the attaching and the simple example at the end which has serialization.

I added a !stopped checked to avoid duplicate logging.

A "dirty fix" is to catch the StackOverFlowException and then disable your block. Print an error in the log when this happens. Maybe give some indication graphically that the block is not working. At least that way you won't break people's worlds. If it crashes as soon as they get in the game, they can't fix it. Something like: private boolean stopped = false; @Override public void tick() { if (stopped) return; try { // Your normal code } catch (StackOverFlowError e) { if (!stopped) log.error("Detected tick accelaration conflict, stopping! x=" + worldPosition.getX() + " y=" + worldPosition.getY() + " z=" + worldPosition.getZ(), e); stopped = true; } } I added a !stopped checked to avoid duplicate logging.

You are still going to get the same problem if somebody else makes a block like yours and somebody places that block next to yours.

I would make your check if (!(tickableBlockEntity instanceof TimeGemBlockEntity)) { for (int i = 0; i < this.speed && !tickableBlockEntity.isRemoved(); i++) tickableBlockEntity.tick(); } so 2 of your blocks placed next to each other don't tick each other. Otherwise you will have the same problem.

Read the error message. You have recursive death. Your tickableBlockEntity.tick() call is calling tick() on yourself, and so round and round it goes... 🙂 You also only need one isClientSide check. tick() is the main entry point. The others are redundant.

In game you just use a normal boolean field like normal in your capability class. Its only if you want to send it across the network or save it you need to turn it into a ByteTag (there is no BooleanTag). Wrapping it in a CompoundTag would future proof it, so you can add other data/tags later. A plain byte tag is 1b, the compound tag gives it a name {name:1b} in future it might be {name:1b,another:"foobar"}

Don't use OnlyIn. That is meant to mark vanilla code so you know which side it belongs to. What you did is remove the method from the class on the client version of minecraft. In your tick method add an isClientSide check. Ticking in the client is usually only used for modifying variables related to animations.

There are at least 2 different ways to do this. net.minecraft.world.entity.ai.attributes.Attributes This is not something I've not played with. So I can't say much about it. The basic idea is each entity has a set of attributes. Which can also have permanent or transient AttributeModifiers. These modifiers are linked to ArmorItems or MobEffects, or they could be "ad hoc". Forge has some events that let you configure attributes for entities: EntityAttribute(Creation/Modification)Event. Of course you need to register any custom attributes you make. From what I can tell, these attributes are meant to be number ranges. Forge's capabilities: https://forge.gemwire.uk/wiki/Capabilities These are much more general and let you attach any data to most important in game things, but they also provide an "interface" for mod communication. It is good to learn this system, things like item handling across mods or FE (forge energy) uses capabilities. The major drawback with capabilities is they don't automatically synchronize with the client, so you have to do this yourself. Which is something people can struggle with until they understand it. The issue is due to capabilities being flexible, forge can't really know what/how/when you want to synchronize.

EntityType.spawn() e.g. as used by SpawnEggItem

ServerLevel.setBlockAndUpdate(). You need the BlockState not the block. If it is standard minecraft format you can use NbtUtils.readBlockState(CompoundTag) If it is a BlockEntity then you also need to do Level.setBlockEntity() again if it is standard nbt you can use BlockEntity.loadStatic()

Of course you could just not include a goal for attacking players. But then they would be completely docile towards the player even if the player attacks them.

On the NearestAttackableTargetGoal you can use an entity predicate. For an example, look at the ai config in IronGolem.registerGoals(). Doesn't attack players unless they make it angry.

You are ticking the block on the client where there is no area calculated.

Since this keeps getting reported but only with that Better Minecraft Modpack. I think the problem is probably something broken in the config for that modpack that is confusing curseforge?

Those item registrations only happen at startup. Your durability is fixed then. If you want something more dynamic you would need to do something like this in your item class:

I don't know if this is the place to teach about minecraft's rendering system? There's no docs, most people learn it by looking at the minecraft source. Quick answers to your questions: PoseStack is a stack of transformation matrices. The idea is you can push a new context on the stack, transform the pose (translate, scale, etc.), then pop to restore the previous state. The buffers are what is sent to opengl. Typically you don't use them directly, instead you use helper methods and pass it a buffer, e.g. ItemRenderer.renderItem() takes a buffer as parameter. If you do want to use them directly you can find some simple examples of what can be done in net.minecraft.client.gui.GuiComponent. NOTE: Like the names suggest, these method are for drawing the gui, you will typically be passed a buffer to use in world rendering. You can still create your own. For "attaching" look at EntityRenderEvent.AttachLayers. You can getRenderer() of the entity type you want to modify and addLayer()

net.minecraft.nbt.NbtIo - utilities for file <-> nbt