coolAlias

Yeah, shit, I forgot it just ray traces blocks. Well, you're going to either have to do some fancy Vec3 mathematics (I'm sure there's an example somewhere in vanilla) or manually iterate over the player's look vector until you hit something.

... ... ... Seriously? Again? Look at the method: [b]@SideOnly(Side.CLIENT)[/b] public Entity getEntityFromLookVector (World world, EntityPlayer player){ Let's hope the bold works on CLIENT SIDE ONLY!!! Yet you expect results on the server. Did you not read my previous previous comment? I told you exactly which method you can use that already exists - you don't need to write anything but one line to get the raytrace (i.e. MovingObjectPosition). Please read it again. Also, you should know that your naming conventions are incorrect: "Target" would be a class name, not the name of a variable - that would be 'target'.

<facepalm> Minecraft.getMinecraft(), along with objectMouseOver, are both CLIENT side ONLY. Your code will not only not work, but it will also crash if you try it on a server. If you just want to get the entity that the player is looking at, since you are in an Item class, you can use Item#getMovingObjectPositionFromPlayer - this gives you a MovingObjectPosition which you can then check hitType and entityHit. Or you can do the vector calculations yourself.

Not necessary - primitive types can not be null and they all default to the equivalent of zero.

In 1.6.4, sounds are not added via JSON, they are registered during an event: @ForgeSubscribe public void onLoadSound(SoundLoadEvent event) { event.manager.addSound(ModInfo.ID + ":sound_file.ogg"); } If you have a sound with variants (e.g. 'sound1', 'sound2', etc.), you need to register each variant separately (loops work great) BUT when you play the sound, you play it without a number (e.g. 'sound') and it chooses a random one from the variants. Other than that, sounds are handled exactly the same: world.playSoundAt(Entity...) plays a sound on the server which everyone will hear, player.playSound can be used on the client side to play a sound just for that player, and packets are your go between when needed.

In your fromBytes method, 'flip' is NULL. The packet instance is separate on both sides, meaning either you need to send 'flip' with the packet, or it needs to basically be a constant.

Why not use the RenderGameOverlayEvent with a class inheriting from Gui ? That's what those are for, after all.

I've never had trouble rendering things on the left side... 0, 0 is the upper-left corner of the screen, no matter what the width is... Post your code.

Hm, in 1.8 yes, but in 1.7.10 the EntityVillager#createChild implementation doesn't call any other methods. Well, I'll just ignore that one, then, since there doesn't seem to be anything to do about it until I update to 1.8. Thanks for the help!

In this case it's not a generic parameter, it's the covariant return type that is causing the bridge method to be created, but changing the return type to EntityVillager (or worse, EntityAgeable), even if it were an option, simply does not work to remove the warning. If only I could magically absorb all knowledge of the JVM and javac... :\

Ah, that makes sense. For whatever reason, I didn't put 2 and 2 together. I was able to fix all but one of the warnings that way: I have a class that extends EntityVillager and overrides createChild(EntityAgeable), but I cannot change the parameter type without the method signature failing. @Override public EntityGoron createChild(EntityAgeable entity) { EntityGoron goron = new EntityGoron(worldObj); goron.onSpawnWithEgg(null); goron.updateEntityAttributes(true); return goron; }

I noticed this warning for the first time today: RenderEntityKeese.java:48: warning: getEntityTexture (Entity) in RenderEntitykeese overrides getEntityTexture(Entity) in RenderBat; overridden method is a bridge method protected ResourceLocation getEntityTexture(Entity entity) { Code responsible: // RenderEntityKeese extends RenderBat @Override protected ResourceLocation getEntityTexture(Entity entity) { return getEntityTexture((EntityKeese) entity); // this is exactly the same as how RenderBat overrides getEntityTexture } Which got me reading about bridge methods and type erasure, here, here, and here. I tried various things to see if I could get the warning to go away to no avail. Everything seems to work fine, but I don't like getting warnings Is this something I can 'fix', or is it not an issue?

Are you trying to turn ALL water blocks to ice? Or is it one or more specific blocks? If specific, what conditions determine when a water block should freeze?

First of all, you need to make sure that your image file has an alpha layer, which you can add with any decent image editor (such GIMP, PhotoShop, etc.). Then you need to use GL11.glBlendFunc(GL11.GL_SRC_ALPHA, GL11.GL_ONE_MINUS_SRC_ALPHA) before you render your image. See example. This method will render the png with however much alpha transparency you gave it in your editor, but I'm sure there is a GL function that will let you adjust it dynamically.

Don't put @Mod.EventHandler in any class except the main class - it does not belong in your proxies at all. Your client proxy extends the common, so you need to call 'super.whateverMethod' from each of your methods, otherwise the stuff in common proxy never gets called, meaning that your Item was never initialized and thus the crash.

You get an NPE when something is null, in this case 'nextTube' is null, so when you try to access 'nextTube.straights', the game crashes. Why is 'nextTube' null? Should that ever be possible? If so, check for it. If not, check the rest of your logic.

This is an excellent question, and it is one of those things that some people seem to just magically know how to do... for example, I had no idea that /src/api/java/ was a special folder (it didn't even exist). I suppose it's a feature of Gradle to link those files automatically? Then there's all sorts of magic that is evidently possible with build.gradle, but there are probably whole books devoted to that subject - the online documentation certainly isn't a quick read. For us non-Gradle experts, it would be really nice to have a 'Gradle for Modders' information page, somewhere we can quickly learn about the most common modding-related tasks so we don't all have to become experts in Gradle and can focus instead on adding content to our mods.

What Ernio said pretty much covers it, but keep in mind that you don't really need to store the player's inventory anywhere separate - what displays on the screen is not dependent what is or isn't stored somewhere. You can simply NOT draw the inventory hot bar without changing anything in about the inventory itself, and then draw your custom hot bar in its place. That said, you should definitely start simple and build up to it one step at a time.

Your crash is because you referenced an @SideOnly(Side.CLIENT) class (KeyBinding) somewhere in your code that is not only on the client side. If you have keybindings, you should only register them through your ClientProxy - same with any Render classes and that type of thing. Btw, the visibility and 'static'-ness of a class member has no impact on whether it actually behaves as a static member: every single Item is declared as a singleton, thus only one of each item exists and thus every Item class' members automatically behave as though they were static, because there is only ONE instance. Make sense?

Extend GuiContainer - you then have the handleMouseClick method which has the Slot and slot number as the first two parameters.

Okay, that would explain it. Is the IEntityAdditionalSpawnData synced continuously or just during spawn? If it is synced continuously (my custom field values can change during game) I'll try the additional spawn data approach. I haven't been using that because I have had for a long time a successful similar implementation of my own (NBT on each side for saving/loading custom fields plus custom packet to sync) but with this new issue of synchronization the additional spawn data seems much preferred. IEntityAdditionalSpawnData only allows you to piggyback ONCE on the initial spawn packet; any synchronization required after that is still up to you. Typcially, I use IEASD for unchanging fields that the client needs to know about, and either DataWatcher or setEntityState + handleHealthUpdate for the ones which can change. For some examples of the latter, see here - it's great for things like animation timers.

EDIT: Nevermind, doesn't seem to be doing it anymore, even though I'm pretty sure I haven't changed anything. If I happen across this again, I'll update this thread. While messing around, I found something very interesting and somewhat alarming: Decorating at -1600/0, << shift: -25600/0 // note that the new x/z values are the previous ones bit-shifted!!! Decorating at -25600/0, << shift: -409600/0 // and again!!! Decorating at -409600/0, << shift: -6553600/0 Decorating at -1600/-64, << shift: -25600/-1024 Decorating at -25600/-1024, << shift: -409600/-16384 Decorating at -1600/-80, << shift: -25600/-1280 Decorating at -25600/-1280, << shift: -409600/-20480 Decorating at -409600/-20480, << shift: -6553600/-327680 I was checking if DecorateBiomeEvent.Post's chunkX/chunkZ fields were block positions, or chunk positions; the above output was generated by this code: @SubscribeEvent public void onDecorate(DecorateBiomeEvent.Post event) { if (event.world.provider.isSurfaceWorld()) { logger.info(String.format("Decorating at %d/%d, << shift: %d/%d", event.chunkX, event.chunkZ, (event.chunkX << 4), (event.chunkZ << 4))); } } What's especially interesting is that the output clearly shows that the decorator is called once with block coordinates, but then those exact same block coordinates are << 4 as though they were chunk coordinates and apparently RE-POSTED to the event bus! Any ideas on why this is? The only places that this event gets posted is from BiomeDecorator#genDecorations and, for the Nether, from ChunkProviderHell#populate, neither of which look like they should be causing this kind of behavior.

The problem is that packets are handled on a different thread now, and these don't always sync up. Vanilla's 'solution' to this problem is to then WAIT for the main server thread to process the packets. You can see here how I do the same in my packet system. That being said, it is much easier (and provides better encapsulation) to implement IAdditionalEntitySpawnData in your entity class, which then lets you tag along extra data with the actual spawn packet, rather than writing and sending your own additional packet(s) on spawn.

entity.motionX/Y/Z would generally work for your needs, as that is the current motion of any entity (if any motion > 0, stop casting); however, for EntityPlayer, there is the problem that sometimes player.motionX/Y/Z is different on the client side (which is where player motion usually begins via player input) or even never sent to the server (i.e. by mods), making it less than ideal. entity.posY/X/Z is always the current position of the entity, and even for players this should always be the same between client <-> server due to update packets. Those are the most important and most often used of the movement/position fields; the others, like lastTickPosX/Y/Z, are generally used for a specific internal use and not that useful to modders, though I'm sure there are some use cases. Anyway, as the first reply to your topic suggested, your best bet here is to store the player's initial position when they begin casting, and each tick check the player's distance to that point; if it's greater than whatever threshold you decide, then the player has 'moved' and the casting cancelled. Whether you need to use TickEvent or not depends on how your casting is handled, e.g. if you have access to any ticking method (usually #onUpdate of some sort), then you can check it from there instead. EDIT: To clarify since you seem to want "acceleration" instead of "position" - how that makes sense at all when your title is 'Check if player moved' is your call - store the initial motionX/Y/Z instead of posX/Y/Z and keep track of the difference each tick, but keep in mind the note about EntityPlayer's motion as well as the fact that motion values (as well as position values) can be negative, so you'll probably want to get Pythagorean on them.

And? Does it still not work? Can you show the ENTIRE class in which you listen for ItemCraftedEvent? And why are you declaring your method as throwing an IOException?