coolAlias

Btw, you usually don't want to override it to always return false unless you NEVER want the re-equip animation; but what about when the player legitimately changes items, whether by changing their current slot or having the item in their current slot change? Something along these lines is usually decent, but it depends on how you define what does and does not count as the same item for your Item: return slotChanged || !ItemStack.areItemsEqual(oldStack, newStack);

Are you setting it to have a custom name when you spawn it, or did you override #getCustomNameTag in your entity class to always return "Monster"? Show the code that spawns your entity as well as your entity class.

The config file on the server, which the server owner would modify, is the only one that matters as far as most anything is concerned. Encumbrance should only matter on the server side, and thus the server config is the only thing that is important. You can't (well, shouldn't) use the server values to actually overwrite any config / .json file on the client side; you only use it to overwrite the values in memory. Also, you don't use the map to write the .json file, you use the .json file to create the map (except, perhaps, for the very first time). Basically, the config (.json) file that the client reads in should be completely irrelevant as the whole point is you read the file into memory, and those values will be replaced by the ones sent from the server. The only exception is single player, in which the same file is read by both the integrated server and the client, so sending a packet makes no difference (but also won't hurt anything).

The config path itself isn't different, but the config file that is sitting on the server cannot be read from the client, as it is usually on a different computer. You have to write every value you want to sync to the packet / byte buffer, then read it back in from that buffer on the other side and set the values in the config instance that already exists. In very very rough pseudo-code: // YourPacket#write: buffer.writeInt(map.size()); for (each entry in your map) { buffer.writeString(key); buffer.writeString(value); } // YourPacket#read: map = new Map(); int n = buffer.readInt(); // this is the number of entries for (i = 0; i < n; ++i) { map.put(buffer.readString(), buffer.readString()); } YourMod.config.map = map; // overrwrite the previously existing map entirely That's just one way to do it, of course, but the key point is that both the server and the client have independent copies of the Config file which they read in independently, and you want to overwrite certain values on the client's version with those from the server. Keep in mind that the only reason to sync Config values to the clients is if those values are actually used on the client side, such as for rendering in the GUI. Generally, this is not the case, but it sounds like you'd like to display the weight values, so in that case you should sync those values, but probably not anything else.

Your API never alters another mod's files - it is an option for modders to use your interface if they want to provide more direct compatibility, e.g. they have an Item whose weight is determined by damage values or NBT that cannot be described using the simple Config file options you provide. The Config settings are there so you and users can easily add compatibility without requiring other mods to implement the API, as well as to allow users to customize them. It's the backup for when no more explicit instructions are given.

Use a regular config file. The weight is calculated server side, so if a player changed their config settings, it wouldn't have any effect other than perhaps changing what is displayed; you can fix that by sending the config data from the server to the client when the player logs in, overriding whatever client values they may have with the data from the server. Re: the interface - that IS an API, i.e. a contract (the interface) between you and anyone implementing said interface that it will do what you claim it does. APIs are not special, it's just a term to describe public-facing parts of your code that are expected to be used by others to interact with your code in the specified manner. Any modder wishing to implement that API would add your mod as a dependency and implement whatever interfaces they wanted (usually @Optional), and that's it. That's an API. If you want to make it obvious that it's for public use, create a new package called 'yourmod.api' and put any such interfaces in that package. The expectation would then be that any classes in 'yourmod.api' would be relatively stable (i.e. not changing or breaking backwards-compatibility).

Also, if you want other mods to be able to register their items without forcing users to enter them all in via the Config file, you can use the FML Inter-Mod Communication system, as well as create in interface such as IEncumber with a method 'int getWeight(ItemStack)' - that would allow mods to add custom implementations that return weight based on the stack NBT data or whatever, which would need to be checked prior to fetching the value from your map. You may also want to consider using a float value for the weight, if you're not already, so an item can be less than 1 unit of weight.

You can always type 'Keyboard.' in your IDE and a list of all fields will come up. Handy trick for finding stuff in a pinch

Ah, I didn't re-read the OP carefully enough, thought he was trying to cause crops to grow when a neighbor updates

If you do get it working by changing it to notify neighbors, one thing you will need to be careful of is recursion; if you have crop blocks all next to each other and one updates, it notifies all of its neighbors who then update, and suddenly it's a cluster-f*ck. At best, every crop will instantly mature; at worst, you crash with StackOverflow.

Oh, I didn't see that class, just saw the Villager one. Well, (0, 0, 0) is at the bottom of the world, even on a super-flat world I doubt your entity will be able to make it there. You're going to want to use an actual block position near the entity that it can reach.

It doesn't look like you ever add the EntityAISaveResources task to your villager's AI task list. You may want to take a closer look at some of the vanilla AI - setting the BlockPos from the AI constructor doesn't make much sense, for example, unless you don't anticipate the location ever changing; but what if a player removes all those blocks?

@Cerandior - World#getClosestPlayer is FAR more optimized at finding players than #getEntitiesWithinAABB, an example of which can be seen in the post immediately prior to yours.

Probably. With JD-GUI you can save all sources, and a .java file IS a text file, so... But Lex recommends FernFlower, which probably does the same thing but better. May as well check that out first, but I've never used it before, so can't help you there.

Just clone your Git repo into a workspace and... oh, you didn't use an online repository? Oops You can use JD-GUI to view compiled .java files as source code and then copy / paste those into new text files for your project. It'll be a pain in the ass, but at least it's something. Next time, use git

That was my point - that AI is copied directly from the 1.8 version of the Ghast (why they didn't make the AI public, who knows), which, in combination with the new GhastMoveHelper, is just an encapsulated version of the same code they had used in the #updateEntityActionState in 1.7.10. The OP claims to have already looked at that code and found it wanting, which brings us back to square one. OP, what have you tried, and what about it isn't doing what you expect?

For the y-axis, resolutionScaled.getScaledHeight() is always the bottom of the screen, and the vanilla hotbar slots are 18 pixels tall, so (height - 18 - fontHeight) will put text right above them (vertically). Dividing it by 2 will put you relative to the center of the screen, which you don't want if you are trying to stay relative to the hotbar. Horizontally, resolutionScaled.getScaledWidth() / 2 will always be relative to the center, with your text flowing to the right. This should be fine, subtracting some amount to move it further left above the hotbar. It looks like you have a HUGE difference in screen resolution between those 2 images, btw, though the positions shown in either image still don't look right for the values you have in your code. One thing to note: RenderGameOverlayEvent has both a Pre and a Post - choose Pre if you want to cancel the event, or Post if you just want to render, e.g.: @SubscribeEvent public void onRenderExperienceBar(RenderGameOverlayEvent.Post event) { if (event.type != RenderGameOverlayEvent.ElementType.EXPERIENCE) { return; // limit the rendering to one ElementType, otherwise it will render LOTS of times each frame } // do your rendering here }

At its most fundamental, all you need to do is choose a random location, move there, and then choose another random location and move there, on and on forever. Ghasts do this when they don't have a target, so what does your helicopter do when using that same code? What have you tried, and what about it is not working?

Indeed, what Draco mentions would be a problem, plus your entity will be dropping items very regularly. If you want to add some randomness to it, you can store a long value of the next time the entity should drop an item, and check the current world time against that every so often: private long nextDrop; // in onUpdate if (worldObj.getTotalWorldTime() > nextDrop) { if (nextDrop > 0) { // make sure nextDrop has been initialized // drop the item } // set the next drop time nextDrop = worldObj.getTotalWorldTime() + rand.nextInt(20 * 60 * 3) + (20 * 60 * 2); // from 2-5 minutes between drops } Make sure to write and read the nextDrop value to your entity's NBT data.

Take a look at BiomeGenForest, WorldGenForest, WorldGenTrees, etc. - those should get you going in the right direction to find what you need.

Absolutely. In your Entity class, override any of the #update related methods, e.g. #onUpdate or #onLivingUpdate, and check: int time = 10 * 20; // 20 ticks per second times 10 seconds if (this.ticksExisted % time == (time - 1)) { // if you check against 0, it will drop an item immediately every time the world loads // drop item } Note that if you do create a List of ItemStacks, you will want to drop a COPY of the ItemStack, not the ItemStack itself, otherwise once the first one is picked up, all other drops of that stack will have a stack size of zero.

OMMModItems.registerRenders(); That is calling it directly from your main class. Only the proxy (ClientProxy, in this case) should call that method. proxy.registerRenders(); That line is fine, as it would do nothing in the server proxy, but ClientProxy should override it to make all necessary rendering registrations, either from within the CP itself or by calling other methods such as the first one, e.g.: public class ClientProxy extends CommonProxy { @Override public void registerRenders() { Minecraft.getMinecraft().renderstuff.renderstuff.register(someRenderer); // this is fine OMMModItems.registerRenders(); // this is fine here, too } }

We need more context: 1. Where do you call that code? 2. Does your entity have a movement speed attribute > 0 ? 3. How about #getBlockPathWeight - what does your entity return for that? 4. Are you calling super from all overridden update methods? etc. etc. We need to see your entire Entity class along with any custom AI you may have for it in order to determine what's wrong.

The NPE is from the rendering registration, not your item registration, because the model mesher is null during the pre-init phase; just move it to the init phase and it will work. However, you should only be calling the rendering registration method through your proxy anyway, not directly, as any reference to a client-only class (e.g. ALL rendering classes) will crash a server if you try to run it there.

What's the console output from your System.out.println statements? Are those values still empty / null? I assume you set those values from the GUI, but that's client-side only, so are you sending packets to the server to set the actual data there? Btw, you don't need to pass the block position coordinates to open the GUI if you are not going to be using them for anything.