20 minutes ago, OrangeVillager61 said:

Alright, but how to send the villager instance, the number of emeralds to drop and the player in the same class or is that not possible?

 

Send the villager's entity ID in the packet.

 

Don't send the number of emeralds to drop, let the server determine that itself. Malicious clients can send whatever packets they want, they could tell the server to drop a hundred emeralds.

 

You don't need to send the player, the packet handler knows which player's client sent the packet.

25 minutes ago, OrangeVillager61 said:

Is this what you meant?

 

Only check the emerald count when the button is clicked (or when drawing the screen if you want the button to look different when there's enough emeralds), don't check it in initGui.

 

World#isRemote will always be true in a method called from a GUI, because GUIs only exist on the logical client.

 

26 minutes ago, OrangeVillager61 said:

How to send a packet to the server? I'm also particularly bad with packets and client-server connections.

 

Use the Simple Network Implementation to send packets.

8 hours ago, abused_master said:

Ok i have removed the static fields, as for my syncing all i really have is this:

 

You should also override TileEntity#getUpdateTag to return data that should be sent to the client with the chunk (usually the same data as the update packet).

 

Do you ever manually trigger the sending of the update packet with World#notifyBlockUpdate?

 

Are the contents of the fluid tanks ever used for rendering the block, or are they only rendered in the GUI? If they're only rendered in the GUI, you can sync them in the Container rather than the TileEntity's update tag/packet (and avoid re-rendering the chunk whenever you receive the update packet).

ClientChatReceivedEvent#getMessage returns the message as an ITextComponent. This could be an instance of any class that implements ITextComponent, e.g. TextComponentString or TextComponentTranslation.

 

What are you trying to achieve?

You should add the button once in an override of GuiScreen#initGui, after calling the super method. You're currently adding a new button every frame. Override GuiScreen#actionPerformed to perform an action when the button is pressed.

 

When clicked, the button should send a packet to the server that hires the villager after checking that the player is allowed to do so, e.g. they're within range and there are enough emeralds in the inventory. GUIs only exist on the client, the game state needs to be controlled by the server.

42 minutes ago, blahblahbal said:

So.. wait a minute, I have to have a PotionEffect extension as well? Or is that created with the custom potion class?

 

You don't need to extend PotionEffect, it works with any Potion (like ItemStack works with any Item). Just create an instance.

 

 

42 minutes ago, blahblahbal said:

I'm just really confused by all this stuff. I want to add a Spelunker Potion (basically reveals ores), but now that I get into it it seems really complex in 1.8.9. No wonder there aren't any tutorials.

 

The system became a lot simpler with the move from metadata bit-shifting in 1.8.9 and earlier to PotionTypes in 1.9.

38 minutes ago, blahblahbal said:

Though... how would I get the field of the custom potion if it's automatically created when I initialize the custom potion's class? Or do I have to create a field in ModItems, then somehow link it to the potion class?

 

In 1.8.9, create an ItemStack of Items.potionitem and set the "CustomPotionEffects" key of the stack compound tag to a list tag that contains a compound tag for each PotionEffect applied by the potion. You can use PotionEffect#writeCustomPotionEffectToNBT to write a PotionEffect to a compound tag. Set the metadata to 0x4000 (or any number that returns a non-zero result when bitwise AND-ed with 0x4000) to make it a splash potion.

 

In 1.11.2, create an ItemStack of Items.POTIONITEM, Items.SPLASH_POTION or Items.LINGERING_POTION and use PotionUtils.addPotionToItemStack to set the stack's PotionType.

 

 

38 minutes ago, blahblahbal said:

EDIT: If I run setupDecompWorkspace from Forge 2228 gradle, will it corrupt or otherwise render my 1.8.9 workspace unusable? I'm gonna try to update to 1.11.2.

 

No, you can have as many ForgeGradle workspaces as you want. I have a separate TestMod3 workspace for each Minecraft version, each of which is its own branch of the TestMod3 Git repository.

19 minutes ago, EnergyDroid8118 said:

[20:10:32] [main/INFO] [BetterFps/]: Patching Minecraft using Riven's "Half" Algorithm
[20:10:33] [main/ERROR] [LaunchWrapper/]: Unable to launch
java.lang.reflect.InvocationTargetException
...
Caused by: java.lang.VerifyError: Expecting a stackmap frame at branch target 49

 

One of your coremods is broken, possibly BetterFPS.

 

Make sure you're using the latest version of every mod.

 

If the issue persists, remove BetterFPS. If that fixes it, report this error to the author of BetterFPS.

It looks like you need to subscribe to PotionBrewEvent.Pre, check the input items with PotionBrewEvent#getItem, modify the output with PotionBrewEvent#setItem and then cancel the event. For the vanilla brewing stand, indexes 0-2 are the three input items (the potions to be converted) and index 3 is the ingredient item.

 

It may be easier to use Forge's brewing recipe system. You can use BrewingRecipeRegistry#addRecipe to add a brewing recipe for an input, ingredient and output or add an instance of IBrewingRecipe.

 

If you update to 1.10.2+, you can register PotionType conversions with the vanilla PotionHelper class.

The active hand isn't what you think it is. The active hand is the hand that's actively using an item (by holding down right click), e.g. blocking with a shield, eating food, drinking a potion, drawing a bow.

 

EntityLivingBase#getActiveHand, EntityLivingBase#getActiveItemStack, EntityLivingBase#getItemInUseCount and EntityLivingBase#getItemInUseMaxCount only return valid results when the entity is actively using an item, i.e. EntityLivingBase#isHandActive returns true.

 

When a player is placing a block, it's very unlikely that either hand will be active.

Your tanks should not be in static fields, each instance of the TileEntity should have its own tanks.

 

I'm not entirely sure what's causing that behaviour in the GUI, but it may be related to the static fields. How are you syncing the tanks to the client? Post the code that does this.

4 hours ago, N00bcak said:

Yes, i have tried everything. I put the json in the blockstates file, the renamed it to blocks, and i even tried to put it in items. Doesn't work. I even removed the folder and put everything together but it does not work. Is there supposed to be another json file in the items alongside the blockstates? 

 

I explain which models are loaded from where here.

 

You need a blockstates file for the block models. The item models can either be their own model files or specified by the blockstates file.

Your getCapability method is wrong. Please read my instructions carefully, I've told you exactly what you need to do:

 

10 hours ago, Choonster said:

Instead of casting this.item_handler directly to T and suppressing the unchecked warnings resulting from it, call CapabilityItemHandler.ITEM_HANDLER_CAPABILITY.cast with this.item_handler as the argument.

 

I didn't tell you to change the if statement, I told you to change the cast of this.item_handler.

 

TileEntity#shouldRefresh is the method to look at. This controls whether the TileEntity is re-created when the IBlockState changes.

1 minute ago, OrangeVillager61 said:

Oh, okay. Do I still cast this.item_handler to T since I get errors when I don't?

 

1 minute ago, OrangeVillager61 said:

Instead of casting this.item_handler directly to T and suppressing the unchecked warnings resulting from it, call CapabilityItemHandler.ITEM_HANDLER_CAPABILITY.cast with this.item_handler as the argument.

 

Capability#cast casts it for you without the unchecked warning.

1 minute ago, OrangeVillager61 said:

Okay, I understand the rest of the text, but I don't really understand this. Is the below what you meant?

 

Almost, but not quite. Instead of casting this.item_handler directly to T and suppressing the unchecked warnings resulting from it, call CapabilityItemHandler.ITEM_HANDLER_CAPABILITY.cast with this.item_handler as the argument.

 

Capability objects are singletons, compare them with the equality operator (==) rather than the Object#equals method.

 

CapabilityItemHandler.ITEM_HANDLER_CAPABILITY is a field of type Capability (more specifically Capability<IItemHandler>), there's no reason to cast it to Capability. In addition to that, there's no Capability#equals method with a Capability parameter; only Object#equals with an Object parameter. Only cast when it's required by the compiler.

 

Import classes like Capability and EnumFacing instead of using fully-qualified names. Forge only uses fully-qualified names in vanilla patches to reduce the patch size (by removing the need for an import statement).

Post the EntityTestbroom class, the issue may be there.

 

It's best to keep client-only code like model registration in dedicated client-only classes to help avoid issues like this, though PotterEntities.registerRenders probably isn't the cause of the issue.

 

Side note: RenderingRegistry#registerEntityRenderingHandler(Class<? Entity>, Render<? extends Entity>) is deprecated, call RenderingRegistry#registerEntityRenderingHandler(Class<T>, IRenderFactory<? super T>) in preInit instead.

You need to initialise the IItemHandler field with an instance of an IItemHandler implementation. The default implementation of IItemHandler is ItemStackHandler, which will probably suit your needs. The field should also be private.

 

Override EntityLivingBase#hasCapability (which implements ICapabilityProvider#hasCapability) to return true if the Capability argument is CapabilityItemHandler.ITEM_HANDLER_CAPABILITY or return the result of the super method if it's not

 

Override EntityLivingBase#getCapability (which implements ICapabilityProvider#getCapability) to return the IItemHandler instance if the Capability argument is CapabilityItemHandler.ITEM_HANDLER_CAPABILITY or return the result of the super method if it's not. Due to limitations of Java's generics, you'll need to call Capability#cast on CapabilityItemHandler.ITEM_HANDLER_CAPABILITY with the IItemHandler as the argument to cast it to the return type.

 

Calling the super method allows capabilities to be provided by super classes or attached with AttachCapabilityEvent.

17 minutes ago, OrangeVillager61 said:

Thank you so much! This fixed the bulk of my issues. However, my skill with GUI (especially with MC/Java) is limited and I have a major issue where when I put an item into the hire slot and the item disappears, I suspect that this may happen with the other GUI for the hired Villager which is supposed to act as a moving chest.

 

I also noticed that, I believe it's due to the IItemHandler returned by EntityLivingBase#getCapability being a wrapper of EntityLivingBase#handInventory and EntityLivingBase#armorArray.

 

EntityLivingBase#onUpdate replaces the contents of these each tick with the ItemStacks returned by EntityLivingBase#getItemStackFromSlot (which EntityLiving implements using its own lists: EntityLiving#inventoryHands and EntityLiving#inventoryArmor), so any changes made through the IItemHandler are overwritten the next tick.

 

I'm going to see if I can reproduce this and create a Forge issue/PR for it.

 

In the meantime, you should create your own IItemHandler field in IvVillager and expose it via hasCapability/getCapability. Currently you're using slot 0 of the combined armour/hands inventories, which is the feet slot.

Quote

 

[21:55:54] [Client thread/ERROR]: Exception loading model for variant aptbts:oreCopper#inventory for item "aptbts:oreCopper", normal location exception:
net.minecraftforge.client.model.ModelLoaderRegistry$LoaderException: Exception loading model aptbts:item/oreCopper with loader VanillaLoader.INSTANCE, skipping
...
Caused by: java.io.FileNotFoundException: aptbts:models/item/oreCopper.json

...

[21:55:54] [Client thread/ERROR]: Exception loading blockstate for the variant aptbts:oreCopper#inventory:
java.lang.Exception: Could not load model definition for variant aptbts:oreCopper
...
Caused by: java.lang.RuntimeException: Encountered an exception when loading model definition of model aptbts:blockstates/oreCopper.json
...

Caused by: java.io.FileNotFoundException: aptbts:blockstates/oreCopper.json

 

 

Minecraft couldn't find your item model or blockstates file. Are they definitely in the right place (src/main/resources/assets/aptbts/...)?

I figured out the issue: In your Container constructors you were trying to use the villager field, but you never assigned it a value so it was always null. You were also assigning the IItemHandler to a handler local variable instead of the handler field. I fixed these issues in this commit.

 

I also fixed several other issues and changed GuiHandler to use the entity ID instead of the entity's coordinates (which avoids the potential of clicking one villager and opening a GUI for another standing in the same space). You can view and/or merge my changes here.

I'll start debugging it now.

 

I also recommend using a proper Git client (either the CLI or a GUI client like GitKraken or your IDE) rather than using GitHub's upload system.

 

Edit: You should also include the Gradle wrapper (gradlew, gradlew.bat and the gradle directory) in your repository, though this isn't as essential as the buildscript.

 

Edit 2: You should also include a .gitignore file to ensure only the required files are included in the repository. I linked an example in this post.

6 hours ago, Ultra_Bendy_794 said:

What are FML logs and where do I find them?

6 hours ago, larsgerrits said:

logs/fml-client-latest.log

 

This is in the game directory of the launcher profile you're running (.minecraft if you haven't changed it).

 

On 2017-5-29 at 1:33 AM, OrangeVillager61 said:

Huh, interesting, I wonder when I am registering for EntityTameable? I went through entityInit() dataParameters and there is no EntityTameable between IvVillager and EntityLiving and most of all, I renamed the variable from OWNER_UNIQUE_ID to OWNER_DEFINED_ID to prevent this specific issue.

 

As I said:

On 2017-5-28 at 11:40 PM, Choonster said:

 You're passing EntityTameable.class as the first argument of EntityDataManager.createKey,

 

This is in the OWNER_DEFINED_ID field initialiser.

 

The name of the field doesn't matter, you could call it FOO_BAR_BAZ and the issue would still be present.

 

 

On 2017-5-29 at 1:33 AM, OrangeVillager61 said:

I'll make a comit containing the current code on my mod's github, https://github.com/Orange1861/Improved-Villagers/pull/4

 

Please include your buildscript (build.gradle and gradle.properties) in the repository.

I have no idea what would cause this, but the FML log may contain some useful information; please post it.