Animefan8888

That's been confusing a lot of people. So a LazyOptional is an object that stores a value optionally and has many methods to allow you to interact with is such as LazyOptional#ifPresent which will run a NonNullConsumer (which you can just pass in a lambda) that will run only if the LazyOptional holds something. So what I do for the LazyOptional is just do private LazyOptional<SomeData> instance = LazyOptional.of(CAPABILITY_INSTANCE::getDefaultInstance); This will create one instance of the default instance when it is first needed. IE the first time you try to access it.

This tells me that the capability provides some "feature" or "data" that you can interact with in the form of the Class type interface. What if you want this data to behave differently for different objects? You don't want to have to create another capability do you? Like case in point the IItemHandler capability. It needs to perform differently for a chest than it does to a furnace. The furnace will not allow the player to insert items into the output slot. This needs to be handled. Whereas all slots are accessible in a chest. It means to make is accessible. The term refers to the ICapabilityProvider object you attached in the AttachCapabilitiesEvent. You need to make the method getCapability return your data object stored in the ICapabilityProvider instance you have made. Attaching it means you have given it to the Entity/World/ItemStack/TileEntity/etc.

A capability is a way to attach data to an object that doesn't belong to you. IE the player. It's actually incredibly simple. You need a Capability instance with the @CapabilityInject annotation above it. You need to register your Capability using CapabilityManager.INSTANCE.register(Class<Some Base class where your capability data will be stored>, new IStorageInstance, new Callable) The IStorageInstance has two methods that save and load data for the capability. The new Callable needs to create an instance of your base class. Then you also need to use the AttachCapabilitiesEvent to attach it to the object you want to attach it to. You use AttachCapabilitiesEvent#addCapability(ID, new ICapabilityProvider) The ICapabilityProvider is the object that provides the way to get the Capability data from the object it is attached to.

You would end up loading the chunk basically every time you issue the command. Though I guess one chunk and only to teleport the Entity out of there wouldn't be that bad.

That idea would work, but here's another idea. Don't let the entity become unloaded in the chunk. Remove the entity from the chunk before it unloads. Then make sure to save them in a World Capability. This might be better??? Because loading chunks is actually quite intensive.

The problem is that your Entity is not being spawned on the client. The packet I told you to look at is responsible for spawning the entity on the client. You need to create your own, that spawns the entity on the client. If you can't figure that out I don't know what else to do because I'm not giving you the code.

There isn't one. What is it you are trying to do?

I didnt say use it... you need to make your own packet.

Have you changed your mods.toml file?

Use a Capability or just the ItemStacks NBT tag. You can't just store a value in the @Mod class and use it for a timer that is player specific like right clicking. There is only one value on the server.

Edit your original post.

BlockEvent.EntityPlaceEvent PlayerEvent.ItemCraftedEvent BlockEvent.Break LivingDamageEvent and check if the LivingDamageEvent#getSource().getTrueSource() is an instance of CreeperEntity LivingDeathEvent and check if the LivingDeathEvent#getEntityLiving() is an instance of PigEntity and also check LivingDeathEvent#getSource().getTrueSource() is an instanceof PlayerEntity. You would have to use the PlayerTickEvent and use World#getEntitiesWithinAABB to check for ChickenEntity

Post your code and your mods.toml file.

You could watch mine. I don't think diesieben would find too much fault with mine as the stuff there is the basics and I spend a lot of time on here. But I'm not saying there won't be any mistakes.

This is because the EntityType field in your entity called type is being set to the TRIDENT EntityType. You need to make sure that it is set to yours. Also you will need to override createSpawnPacket in your Entity class because the vanilla one is only set up to handle the creation of vanilla entities. To implement your own look at SSpawnObjectPacket which handles the vanilla entities. This is the same problem with your ThrowableEntity so do that too.

Does this mean entities are not automatically synced to the client anymore when they are spawned on the server? And you have to create a packet for this yourself?

You've gotta interpolate the position of them. Using the partialTicks value in the event and the Entity#posX/Y/Z and Entity#lastPosX/Y/Z

No it won't. You'll have to teleport it out before the chunk unloads. Nope because they are unloaded. Yes if you give that entity a UUID that is also saved and loaded. And you access that data when the Entity joins the world(EntityJoinWorldEvent). But then you will have to make sure to save the entity that you have an instance of when it changes and hasn't been synced because the entity in question hasn't been reloaded. Let's just ask this question. What are you trying to do?

If you mean you have an instance of an Entity then yes you should. It shouldn't be Garbage Collected, but it won't be the same entity as the one that is loaded later when the chunk is loaded.

Looks like you need to GLStateManager.translate in the post event to the player in question because it is translated back before the post event is fired.

Post all of your code that is in the Pre and Post event.

How about you make your own thread and post your code so we can give you appropriate help.

The RenderPlayerEvent is called for all Player entities. You'll just have to do what you have been doing just twice and differently. IE if eventPlayer is clientPlayer // Render what you have else // Render with different settings that make it look correct.

Ok you'll have to render it different if it isn't the client player than you would if it was the client player. @Lyon