jabelar

What have you tried so far? Have you got a custom weapon that acts normally working already? Once you do that, you should look at all the methods available in the class and think about how you could use them. There are methods called for attacks and such that you can override. There are also lots of weapons tutorials and there is open source for many popular mods available.

Okay, I just wanted to clarify that you weren't still attacking with mouse and that attack meant more than just extinguishing the fire. I think the problem is that the setKeyBindState() method is the wrong method to use, you should use unpressKey() -- If you look at both methods, the key bind state doesn't affect the timer that is checked when you call isPressed().

Yes, if it is in a fixed location then you can get the tile entity at the fixed relative offset. However, you also said you wanted a time delay before the refresh, which would require a counter which would probably require a tile entity. But like I said, there are multiple ways to solve any problem in programming. In this case, the refresh intelligence can all be in the chest tile entity, or a lock tile entity, or combination of both. I think it is logically better and probably bit better performance to have the intelligence in the lock because you should only need to check for refresh when the lock state changes. So player interacts with lock, whenever it is going from locked to unlocked you check the timer to ensure enough time has passed, then check the chest and decide whether it needs to be replenished. But you can also have the check continuously check the lock to see if it changes state and then have timer in the chest and if enough time has passed decide whether to replenish the contents.

What exactly do you mean by "attack"? Your code should still extinguish the fire, but no other attack should happen and all other keys should be stopped. And what key are you binding to the attack?

In your first code sample, you need to remember this event will fire for every key pressed. But you set the key bind state to false in all cases, so of course it is going to prevent all key presses. The keybinding still works because you continue with code to handle it. What you should be doing is only setting the key state to false inside the if statement.

I think one approach might be as follows. When second player is mounted, the RenderPlayerEvent would render that player as you want in the vehicle (while cancelling normal rendering). The rendering would use exact position based on the vehicle to avoid lag issues that Ernio mentions. But you would still also keep the positions up to date on both client and server. You'd also have to intercept the second player's input to avoid it trying to control player position while mounted.

Nope, I checked and it is server side only. So nevermind.

Can you post your code for the full onBlocksDestroyed() method? What I would do is break the block clicked on normally, and then destroy the other blocks with a setBlock() method which I'm pretty sure does not call the break or harvest events. As you destroy the other blocks, you can drop what you want. Alternatively, as you destroy the blocks you can force the break event by posting it yourself with a ForgeHooks.onBlockBreakEvent() method call. Then you can handle the break event by checking if player is holding your item and proceeding accordingly.

Let's not be too hard on Izzy. Despite some fundamental mistakes, his code actually looks like he could learn to be a good programmer (unlike some of the crazy code some people post that appears hopeless). Izzy, you're bashing into a couple concepts here. Static, instances and singletons. The first one is what a static field is. Putting static means that it is SHARED across all instances of that class. (Well actually it isn't in the instances at all, but is referenced directly through the class). Fields that are not static need to have an instance of the class to reference, and can vary between the instances. An instance is created whenever you use the "new" keyword: MyClass myClassInstance = new MyClass(). To see the difference between accessing a static and non-static field, if MyClass has a static int myField you would reference it simply with MyClass.myField. However, if it wasn't static then you'd have to create an instance with MyClass myClassInstance = new MyClass() and then you could reference with myClassInstance.myField. See the difference? Now theoretically you'd want to create an instance for everything in your program that might vary from similar things. In Minecraft you might think that you'd create a block instance for every block placed in the world. The problem is that there are so many blocks in a Minecraft world that you'd run out of memory doing it this way. Instead they only create a single instance (called a "singleton") that has the ability to change a bit by looking up a compressed map of data called metadata. There are cases though where you want your blocks to do something more complicated, or store things like inventories of items. So that is where tile entities come in. But since it is expected that you won't place too many of these they allow you to create an instance for every placement. Putting all this together, you should have just one custom block instance (i.e. there should only be one place through the entire mod where you use new with your class constructor) but when the method for getting the lightvalue is called you want to check the unique tile entity instance at the same position. That tile entity class shouldn't use static fields for calculating the light value, otherwise all the tile entities will report the same value. Hope that helps. I feel if you can wrap your head around these three concepts -- static, singletons used for blocks and items, multiple instances of tile entities -- that you'll really have a breakthrough in your modding and programming in general. The second concept is the idea of a "singleton" class.

What happens if you handle the BreakEvent instead? I think it fires on both sides. You can check if whatever block that is breaking has a fire on top, in which case you extinguish the fire and cancel the breaking of the block.

For us to help you, you need to post your code as well. There are lots of tutorials on recipes, such as: http://bedrockminer.jimdo.com/modding-tutorials/basic-modding-1-7/crafting-recipes/ But your error might be more of a Java mistake than recipe issue. So post your code.

If you're only doing one block it isn't that much work to do the JSONs. The main pain with JSONs for me is that there is no code verification by your IDE so simple typos are hard to debug -- in other words Eclipse won't warn you if you make a mistake. Anyway, the approach to animation (either changing model or texture) is to create an int property in your block and a tile entity for the block to help control that property. The int will represent an animation step, meaning your model. In the tile entity, you can increase the property and roll back to 0 when you reach the end of your animation steps. You don't need to convert the property to metadata because the animation is just a visual effect and it isn't important to save it. Then in the blockstates JSON for the block, just point to different models based on that property value. If you want some more background on working with blocks in 1.8, read TheGreyGhost's tutorials: http://greyminecraftcoder.blogspot.com.au/2014/12/block-rendering-18.html and http://greyminecraftcoder.blogspot.com.au/2014/12/block-models-18.html

I got it working by spreading the generation out over several ticks, although the code was pretty much identical. I think the problem must have been that maybe the networking got jammed up with so many blocks created so quickly that it had trouble. Allowing it some time by breaking up the work over multiple ticks maybe allowed it to catch up. Anyway, I got it working, but just wish I could confirm why it didn't work.

No, people sometimes miss posts, plus sometimes some topics people figure you can google for existing answers. One guy who has done a lot with block models is TheGreyGhost. It seems he's been converting his site to make 1.8 tutorial more prominent, but you can probably root around to find the 1.7.10 versions. For 1.8 he has explanations of block rendering: http://greyminecraftcoder.blogspot.com.au/2014/12/block-rendering-18.html and block models: http://greyminecraftcoder.blogspot.com/2014/12/block-models-18.html

@Thornack, how do you mount your entity if the interact() method is blank?

Well, there is a difference between avoiding 1.8 for new mods versus updating old mods to 1.8. Depending on what your mod did, updating can be a LOT of work. I tend to mostly mod entities, so the update wasn't hard. But I could see how people with lots of blocks, particularly ones with custom models and such, might legitimately feel it is not worth the effort. Definitely any new modding should be done in 1.8. And like diesieben07 says any PRs for non-critical changes will only be accepted into 1.8.

In cases where your code doesn't do what you expect you need to go back to standard debugging -- meaning you need to trace the code execution. I do it by putting in console statements at every critical point in the execution. If you printed out the values that your loop is generated for example, I think you'd quickly find out why the math isn't working the way you expect.

If I understand what the original poster is trying to do, I think Abastro's recommendation to get the list of ores from the ore dict and work with that seems like the best approach. You could drop the first thing in the list, or randomize which one comes out. Like if 5 mods for some reason all added basalt then you could randomly choose from the list.

Yes, you need the lock block to remember the location of its associated chest and a tile entity is a good way to do that. You can potentially do things with world data instead, storing a map between locks and chests. In programming there is usually multiple ways to accomplish the same or similar results.

No, while I used the method to show attacking an entity, it is really just a copy of the mouse over method with a reach you can specify. It returns a moving object position so (although I didn't confirm it) I think it will return a block if it doesn't hit an entity. The method basically works by first doing a ray trace on the look vector which returns a block, and then iterates along the vector to that block to see if there is an entity in the way.

What is the error? Also, where is the smeltedblockoneye being assigned?

Okay, well you find the tile entity by knowing the position and checking the world for tile entity at that location using World#getTileEntity() method. Then once you have the tile entity instance, there are all sorts of fields and methods (just look at the class) related to the contents of the chest. In particular you could loop through the slot numbers and use getStackInSlot() method to see what is already there. Then if you decide to add something use the setInventorySlotContents() method to place something in a slot.

I think you can check if the item in the stack is an instanceof ItemBlock class.

It would help if you described what kind of machine you want to make. If your machine is something you can put items into (like it has slots), then a furnace would be a good example -- you'd need to implement Container and such. If your machine doesn't need items, then you would just make it a simple tile entity.

I think this may have a problem though. That method is used by the EntityRenderer#getMouseOver() method. But that method seems to clamp the value to 3.0D (or 6.0D if in creative mode). Here's the relevant code: this.mc.pointedEntity = null; double d0 = (double)this.mc.playerController.getBlockReachDistance(); this.mc.objectMouseOver = this.mc.renderViewEntity.rayTrace(d0, p_78473_1_); double d1 = d0; Vec3 vec3 = this.mc.renderViewEntity.getPosition(p_78473_1_); if (this.mc.playerController.extendedReach()) { d0 = 6.0D; d1 = 6.0D; } else { if (d0 > 3.0D) { d1 = 3.0D; } d0 = d1; } if (this.mc.objectMouseOver != null) { d1 = this.mc.objectMouseOver.hitVec.distanceTo(vec3); } Doesn't that prevent values over 3.0D? This is why I chose to try creating my own mouse over method instead.