Leaderboard

EntityPlayer.getUUID(GameProfile) returns the UUID of the profile if present, otherwise reroutes to EntityPlayer.getOfflineUUID(String). EntityPlayer.getOfflineUUID(String) returns a UUID generated from a username provided prefixed with OfflinePlayer. Entity::getPersistentID and Entity::getUniqueID both return the same in case of EntityPlayer - and that would be the result of EntityPlayer.getUUID(GameProfile). GameProfile::getId returns the UUID of the profile, or null if it is not present(could not connect to Mojang's servers). So there are really 2 cases: The player is logged in and in that case return the UUID from Mojang's servers The player is not logged in and in that case return a UUID generated based on their name.

Code? Crash log? We aren't psychic.

You go to minecraft.curseforge.com, create an account, create your project, and then upload the built mod jar.

The player's inventory is stored in the EntityPlayer#inventory field, which is an instance of InventoryPlayer (an implementation of vanilla's IInventory interface). Forge patches EntityPlayer to add the EntityPlayer#getCapability method, which exposes various IItemHandler wrappers of the InventoryPlayer (main, equipment or joined depending on the EnumFacing). These don't store the inventory contents themselves, they simply provide access to the underlying InventoryPlayer through the IItemHandler interface. You can use a SlotItemHandler with one of these IItemHandler wrappers instead of a regular Slot with the InventoryPlayer to achieve the same result (access a player inventory slot in a GUI).

You still have the same issue. Upon deserialization your EnergyManager from NBT you set the energy to 0 as the capacity is 0(as you initiate the container field to have 0 capacity in the parameterless constructor). Then after you are done setting the energy to capacity(which is 0) you read the capacity. The deserialization order is mixed.

It's important to distinguish between physical sides and logical sides. Proxies handle physical sides, but they don't handle logical sides. Client-only classes like GUIs, models and renderers can only be accessed on the physical client, but sending messages to players should happen on the logical server (not just the physical server). Forge's documentation explains this in more detail here. The common type of your proxies (the type of the @SidedProxy field) should be an interface rather than a class. There's no need for a common proxy class because proxies are only for sided code; common code belongs in your @Mod class and other common classes.

EntityPlayer already provides CapabilityItemHandler.ITEM_HANDLER_CAPABILITY itself, so it never delegates this to the attached ICapabilityProviders. You need to create your own interface that extends IItemHandler, register a capability for it and provide that from AbilityProvider instead. AbilityProvider.handler is a static field, which means it's shared between all instances of AbilityProvider (and thus all instances of EntityPlayer you attach it to). It needs to be an instance field instead. Your IDE should warn you about accessing a static field through this.

Oh good. You're asking us how to bypass a mechanic you wrote and provided dick all in code for us to even have a clue.

Fluid textures go in src/main/resources/assets/<modid>/textures/<path>, where <modid> is your mod ID and <path> is the path component of the texture ResourceLocation. The UniversalBucket instance is stored in the ForgeModContainer#universalBucket field. Use ForgeModContainer.getInstance to get the ForgeModContainer instance. In 1.11.2, use UniversalBucket.getFilledBucket to get an ItemStack of the UniversalBucket filled with the specified Fluid. In 1.12+, this has been deprecated in favour of FluidUtil.getFilledBucket. Keep in mind that vanilla recipes don't support ingredients with NBT in 1.11.2, you'll need to create your own recipe classes (you'll probably want to extend an existing recipe class). In 1.12+, use a minecraft:item_nbt ingredient in a JSON recipe to create an NBT-sensitive ingredient. Edit: Fluid textures go in src/main/resources/assets/<modid>/textures/<path>, not src/main/resources/assets/<modid>/textures/blocks/<path>.

No I can't. I have to assume the opposite, because if I assume that your superclass does something, then I can assume your code works perfectly.