Leaderboard

I fixed it by changing the <= to < WOOHOO! Maybe I'm not a total noob haha. It works I get my diamond block and NOT my gold ore. You guys are seriously a freaking amazing community though.

You can't compare ItemStacks using the == operator, it checks for object identity - so a newly created stack will never be == to an existing stack. Instead you need to check the item that's within the stack (using stack#getItem) and compare it to the block's ItemBlock (which you can obtain from Item.getItemFromBlock). Items can be compared using ==, because they are singletons (so there's only ever one gold ore item, for example).

Minable's offset is a fixed +8 +8 to move away from the problematic north and west edges (south and east always have neighbors already, so it's ok for ores to push into them). Minable does not randomize, so a mod still needs to do that. Some mods don't use WorldGenMinable (perhaps because they must do other work or make other decisions) . Those are the mods that must beware of runaway worldgen and produce their own offset to avoid generating anything along the north or west edge of the given chunk (which would trigger neighbor updates into unloaded chunks, which would trigger more worldgen).

The docs have a basic overview of using events. To edit the drops from a block, you can use HarvestDropsEvent. In the event, you can check for your chosen block(s) and then edit the list of drops (from event#getDrops()) however you like.

Yeah the redistributable installs the runtime files

You can't safely interact with normal Minecraft classes from the network thread, so the first thing you do in IMessageHandler#onMessage should be to schedule the task to run on the main thread. Only get the villager and hire it inside the scheduled task. WorldServer#addScheduledTask isn't a static method, you need to call it on an instance of WorldServer. The MinecraftServer class also implements IThreadListener, so you can use the server instance (EntityPlayerMP#mcServer) to schedule the task instead of a WorldServer instance (the WorldServer implementation of IThreadListener delegates to the MinecraftServer implementation anyway). The MessageSendEntityID name isn't much better than EntityIDProxy. The purpose of the packet is to hire a villager, the fact that it sends an entity ID is just an implementation detail. Entity already implements ICapabilityProvider, so IvVillager implements it as well. You don't need to create a new implementation. What I was trying to say is that you only need to expose an IItemHandler (or any other capability handler instance) through the ICapabilityProvider methods if you want vanilla or other mods to interact with it. If only your code needs to interact with it, you can create your own method in IvVillager to return it. The IMessageHandler shouldn't really be checking the hire cost itself, it should simply check that the player is within range of the villager before calling IvVillager#hire_Villager. IvVillager#hire_Villager should check the hire cost and the hired status before setting the villager as hired and the player as its owner.

You're not doing it the way I told you to in my previous post, but it's mostly correct. The main issues are that you're running this code on the network thread instead of the main thread (see the Warning box on the Simple Network Wrapper documentation page for an explanation) and that you're checking that the villager is hired before attempting to hire it. Why are using slot 15 of the IItemHandler? You should expose the IItemHandler that stores the emeralds directly (either via ICapabilityProvider#getCapability or a custom method) and use that rather than using a wrapper of all of the villager's inventories (which I presume is why you're using slot 15). You only need to expose an object through ICapabilityProvider if you want external code to be able to access it. Use descriptive names for your classes, fields, methods, etc. that reflect their purpose: EntityIdProxy doesn't tell me that the class is an IMessage, nor does it tell me anything about what the packet does. I recommend naming your packets Message[Action], where [Action] is the action that the packet performs (i.e. why it's sent in the first place). This packet hires a villager, so name it something like MessageHireVillager. toSend doesn't tell me anything about the contents or purpose of the field, the fact that it's sent in a packet is already obvious from the context so it doesn't need to be included in the name. This field stores the villager's entity ID, so name it something like entityID or villagerEntityID. Only declare local variables in the scope where they're used. There's no reason to declare the remaining_i variable at the start of the method if you're only going to use inside the if statement.

There are many Forge mods at CurseForge, and many of them link to their source code at github. You can learn much from just walking through others' source code, especially if you can find a mod doing something like what you want to do.

You don't access the GUI, you access the IItemHandler inventory that the GUI interacts with. The IMessageHandler should check that the player is in range and then call the hire method. The hire method should take an EntityPlayer argument and check that there are enough emeralds in the villager's inventory and the villager isn't already hired (plus any other prerequisites) before setting the villager as hired and the player as its owner.

Whether or not each side needs a Forge mod installed depends on what the mod does. If it adds a new Block or Item, both the client and server must have the mod installed. If it adds a new server-side command, only the server needs to have the mod installed (though the client will also need it installed if you want to use any non-vanilla localisations). If it changes client-side things like rendering, only the client needs to have the mod installed. Set @Mod#clientSideOnly or @Mod#serverSideOnly to true if the mod is client-only or server-only to prevent it from being loaded on the opposite physical side. Set @Mod#acceptableRemoteVersions to "*" (i.e. accept any version, including none) if the mod is only required on one side. Edit: acceptableRemoteVersions, not acceptedMinecraftVersions.

Ya, there isn't much we can do to help you. Optifine is a thing that just hacks into A LOT of internal stuff. And we've tried to expose as much as we can to help him. But he's closed source, and doesn't talk or submit issues. So ya, can't do anything. Plus the fact that MOST users don't get any performance out of Optifine. Oh well. Make your choice, Optifine or Forge. We've done our best.

The problem you're having is that the update intervals of rendering and the player movement are different. The player position is changed each 1/20s, but your line rendering is updated every render frame (which is usually much faster than the 1/20s). Say you're doing a render at the half of a tick time passed. What you have to basically do is starting with the current position of the player at the current tick, and subtract the old position of the player from the previous (server) tick. if you then multiply this by how much you're 'in' the current tick (0.5 in this case) you have the average of the two. Take a look at this code snippet to see what I mean: double playerX = player.prevPosX + (player.posX - player.prevPosX) * event.partialTicks; double playerY = player.prevPosY + (player.posY - player.prevPosY) * event.partialTicks; double playerZ = player.prevPosZ + (player.posZ - player.prevPosZ) * event.partialTicks; Like you can see, the variable holding the value telling you how far you are in the current tick is called a 'partial tick', and can be retrieved from the RenderWorldLast event.