poopoodice

What I was trying to say is, apparently the ifPresent() check failed, therefore you are printing a default value (got from orElse()). Here you should use orElseThrow so there will be an exception when the entity does not have the capability (to notify you that somethings wrong with your capability). No, the capability is added during the attaching event. And if I understand it correctly, LazyOptional.of(MOD_CAP::getDefaultInstance); this will provide an instance from the factory that you have passed in the third parameter when you register the capability, and you are currently splitting up your capability into ModCap and ModCapMethods, which for me it seems a bit redundant (a class can have multiple interface implementations), and might be the cause of the problem.

.orElse(new ModCapMethods() This won't assign the living entity a new instance of your capability. This means System.out.println(target.getCapability(ModCap.MOD_CAP).orElse(new ModCapMethods()).get()); If the capability does not exist on the entity, it prints the default value (of the new instance). By using orElseThrow you can get notified whenever you are accessing an entity that does not have the capability (which should not happen). At the moment it seems like the entities does not have your capability, is the capability correctly registered, and capability correctly attached?

Use updatePostPlacement and check if the bottom block is air, if so return air's default state (check bush block).

((PlayerMentalInterface) cap).setMental(currentMental); This is not right, you need to get the capability out of the lazy optional (use orElseThrow ), not casting it. You might find this thread helpful:

If you look into Minecraft.java, you will notice that it has an annotation: @OnlyIn(Dist.CLIENT) and according to forge doc: Annotating a method or field with the @OnlyIn(Dist) annotation indicates to the loader that the respective member should be completely stripped out of the definition not on the specified physical side. Usually, these are only seen when browsing through the decompiled Minecraft code, indicating methods that the Mojang obfuscator stripped out. There is little to no reason for using this annotation directly. Only use it if you are overriding a vanilla method that already has @OnlyIn defined. In most other cases where you need to dispatch behavior based on physical sides, use DistExecutor or a check on FMLEnvironment.dist instead. In other word, Minecraft.java does not exist on server side! You know what will happen when you have an non-existence reference.

That's right. That me briefly explain the situation here: You want to sync the mental value of the player on server to client, and you had sent a packet that contains the value, in order to use it and render images on the screen. To get the value when rendering the screen, you are going to access the capability of the client player, therefore you need to assign the value from the packet to the client player's capability. So: (make sure you do this on client using dist executor!) MyCap cap = Minecraft.getInstance().player.getCapability(....); cap.setMental(valuefromserver); where cap is the client player' capability, and valuefromserver is the mental value got from the server player's capability that you want to assign(Sync) to the client. Then you can use the same way above to access the value stored in the capability of the client player to render the images. Also make sure you only send the packet when there's data change.

Handle is called when the client has received the packet, so there should be where you sync the data (what you've done in the previous post is correct), which you should get the client player and its capability to sync in here. Also: You can get the context from the supplier (given in the second parameter of handle(...), then call Context#setPacketHandled)

It seems like you are syncing an int to the client? You can use dist executor to make sure you are on the right side and get the capability from the client player (using Minecraft.getInstance().player), then you can set the value got from the packet (msg.currentMental). Also make sure you have packet set handled Context.setPacketHandled()

People are allowed to have their own opinion. Some people thinks those tutorials are shit, some people does not, and they can surely decide what they want. I think what Ash was trying to say is some of the people can't do anything when there's no tutorial specific for their target. For example "render a sentence above all entities that have *condition checking* in my own capability", you may find some tutorial of this, but usually you can't because it's a combination of multiple things (in this case capability and rendering). Hence they asks: "how do I do this, do that", and when the other people provide answer like: "you need to store information on entities using capability, and check how vanilla render the named entities", they get confused because they are used to someone gets them step by step, even better - copypaste code. And eventually it brings more questions, questions that are asked without researching or trying. If you want to make this forum better to reach your expectations, this forum is opened to everyone, and that includes you . Arguments are fine, but please don't insult people.

This has been asked multiple times

Wrong supplier imported. Correct one: import java.util.function.Supplier

The forth parameter is a function that gives you the buffer to read, change it to decode.

Isn't fuel stuff handled through getBurnTime ?

You should throw an exception if the player does not have the capability because what you do here drugUse.orElse(new DrugUse()) is pointless because if the player does not have the capability you are always accessing data of a new instance of your capability. Also is the event correctly registered?

You have all your tool tier efficiency 0.

If you look into the blit you are using you will notice that it passes 256 as its last two parameters, which is the texture size.

Just check vanilla for examples, as it is always up to date.

How about isBurnable() in Item.java?

See how you bind your own texture here? mc.getTextureManager().bindTexture(MENTALICON); You need to rebind the vanilla texture back after you finished your rendering, what diesieben gave you was the resource location of the texture.

I think it's in the render method in EnderDragonRenderer. (where it does death checking EnderDragonEntity.deathTicks > 0)

I don't know if you had noticed but I don't think this is where crash occurred. java.lang.ClassCastException: com.halestormxv.mysterium.data.explosium.DefaultEntityExplosium cannot be cast to com.halestormxv.mysterium.data.location.IEntityLocation at net.minecraftforge.common.util.LazyOptional.ifPresent(LazyOptional.java:161) ~[?:?] {re:classloading} at com.halestormxv.mysterium.effects.EffectRemembrance.savePosition(EffectRemembrance.java:91) ~[?:?] {re:classloading}

https://mcforge.readthedocs.io/en/latest/concepts/sides/ The event is triggered on different sides, therefore it prints 4 times.

Don't know if it matters but you shouldn’t be checking for Air element type, also you’ve disabled blend in the loop which I think you meant to put it outside the loop?

It's on forge eventbus not mod. https://mcforge.readthedocs.io/en/latest/events/intro/

public static final RegistryObject<EntityType<CrawlerVenomEntity>> CRAWLER_VENOM = ENTITY_TYPES.register("crawler_venom", () -> EntityType.Builder.<CrawlerVenomEntity> <----- create(CrawlerVenomEntity::new, EntityClassification.MISC) .size(1.0f,0.5f) .build(new ResourceLocation(MajCraft.MOD_ID, "crawler_venom").toString()) ); https://www.tutorialspoint.com/java/java_generics.htm