warjort

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

That's not specific, that's the whole thing. 🙂 You would be better looking at some vanilla examples, e.g. the CustomHeadLayer which renders if the entity is wearing a skull It sounds similar to what you are trying to do.

You seem to have described how to implement it? Explain which part(s) you are having problems with. Showing the relevant parts of your code would be useful for this.

I am not sure how that would fix it? The problem seems to be curseforge is not downloading the forge jars for some reason - probably due to OS file permissions on the (parent) folders of the curseforge installation folder? java does not seem related to this (curseforge is written in c++). But it is their software so what do I know? 🙂

you have firstperson for minecraft 1.19 but are using 1.18.2 firstperson-forge-2.1.0-mc1.19.jar I also don't see NotEnoughAnimations in your mod list. Maybe I missed it? It says that is a dependency on the mod page.

If you know the problem mods, you should report it to the mod authors. You should also report it to the modpack author in case they have seen the problem before. Other things: It is not a good to use spaces in a folder name. Often mod developers don't handle this properly. You don't seem to be logged in properly?

See: https://forums.minecraftforge.net/topic/113178-better-minecraft-forge-125-exit-code-1/ I wish somebody would report this to curseforge so they can fix it. 🙂

Maybe you can contact mojang to see if they have a problem with their local server.

Where are you located? Maybe the "shard" server in your region has a broken file. But if that was true, I would expect a lot of people complaining about broken minecraft installs. 🙂