jabelar

Create an event handler for PlayerTickEvent. I have a tutorial on event handling here: http://jabelarminecraft.blogspot.com/p/minecraft-forge-172-event-handling.html In that event handling method, check if the player is holding the item you're interested in. If it is, use the worldObj.getEntitiesWithinAABB() method to get a list of the entities within a certain bounding box you choose. Iterate through that list and take each entity and damage them.

[deleted]

If you want them to move together they need to have the same rotation point. You didn't post the code where you set the rotation points, but I suspect you don't have them the same. Alternatively you can make the parts "child" parts to the head and then you only have to turn the head, using the addChild() method for the renderer parts. However, in that case the rotation points will be relative and probably have to be adjusted depending on how you set up your model pieces.

What exactly do you mean "stores XP"? Do you want to be able to put XP orbs in and take it them out somehow? Or do you mean you just want it to display the player's current XP?

[EDIT] Do what CoolAlias says.

I think you're registering the event handler to the wrong bus. It is an FML event so needs to be registered on that event bus. You can read up more on events here: http://jabelarminecraft.blogspot.com/p/minecraft-forge-172-event-handling.html

By the way, a memory leak occurs with the software program continues to allocate memory for use without ever freeing it up again. So the amount of memory used by the program grows until the system can't handle it anymore and crashes. Memory leaks are often a result of poor buffer management. For example, if you're doing file I/O operations and keep opening up stream buffers for reading without ever closing them, or similarly with networking that usually uses buffers for the message payloads. I'm not really certain how the memory leak occurred in that problematic packet system that we all used for a while, but it likely was similar issue with buffer allocations not being freed up.

You keep adding on to your angles so even with a trig function that goes negative, if you keep adding on to your previous it will still generally accumulate in a weird way. Instead I think you should have a fixed starting angle for each leg and only add the trig to that. Maybe something like: this.RightHindLeg1.rotateAngleX = rightLegStartingRotation + MathHelper.cos(par2 * 0.6662F) * 1.4F * par3; Where you should replace rightLegStartingRotation with whatever value the middle of the animation is supposed to have (maybe 0 in your case). Do that for each rotation.

It's really quite simple, but you need to do things in order and you need to double check rotation points and offsets. The most common mistake is that in Techne (or Java model) you can mistakenly use offsets to make it look like the parts are correctly connected, but you really need to make sure the rotation points are correct (usually at the point of connection between parts). In my tutorial where I introduce the concept of convertToChild() I also talk about the spinX(), spinY(), and spinZ() utility functions for testing your rotation points. Basically if you take a part and spin it it is the best way to confirm that your rotation points are correct. From the description of your problem, the rotation points for your horns is still incorrect. Once the horns are children of the head, the rotation point needs to be *relative* to rotation point of the head. So if the head rotation point is in the center of the head it will be different than if the rotation point is at the neck connection. It should be very easy to get it right if you think carefully about it -- you can even just sketch it on paper and do the calculations.

getEntitiesWithinAABB() method returns a List. You need to iterate through that list (loop), check if it is the entity you want to kill, and if it is then use the setDead() method to kill each entity.

Okay, first of all, in the set rotation and angels method you should not do any rotation of the horns or the horn points. Once they are made children of the head they should automatically turn with the head -- that is the whole point of making them a child. Basically, what you should do is remove the lines that are rotating the horns and horn tips in the setRotationAndAngles() function. Secondly, you need to make sure they are nicely connected and rotated initially. The easiest way to do this is to rotate them after they are converted to child. So when you first make the horns and horn tips, do no rotate them at all. Just make sure they are connected at right point with right rotation points. Then do the rotation you want to get the horns looking right. After that they should stay connected and should turn with the head, just by rotating the head.

You don't have to. We said you should use event handling to do it. When the events we mentioned fire, your handler should just check if it is firing for a zombie and if it is then do what you need to do to extinguish the fire.

You don't understand my point. Any time you want to get the instance you can just use GameData.getItemRegistry().getObject() method directly. You don't need to "store" the registry to use it because you can chain the getObject() method to the getItemRegistry() method. Besides which, in Java when you "grabbed the instance" you actually aren't making a copy of it, you're just pointing to the one that already exists.

Yes, but I'm not quite sure that it is better practice to make your own field name to point to the instance. Seems to me that it is more readable just using GameData methods as needed directly. While modding on our own, we are of course free to name things how we want, it is generally best to practice programming as if you're part of a coding team, in which case readability (by other people) is an important principle.

I'd go with your idea that the player would actually have a collection of body part entities around it. But I would render the player normally and just have invisible entities for the additional collision boxes. However, besides the issue of lag that both you and TheGreyGhost mentioned, the collision boxes for entities in Minecraft don't rotate with the models and in fact the collision box is always aligned with the x, y, z axes, so I'm not sure how satisfactory the result would be. I mean you might have a swinging arm, but what collision box would you really put for that? I feel the combination of lag plus imprecise alignment of collision boxes with rendered body parts would make it seem a lot less precise, and possibly frustrating, which is sort of the opposite of what you want (i.e. critical hits being a precise thing). I think it works for the dragon because it is so big that the issues of imprecision and lag are sort of lessened.

Each event has an instance passed in as a parameter, so you need to get the field from the parameter. In your code the parameter is called event, so you should be checking the value of event.lootingLevel After that, yes, you simply test the value and then code what you want. If looting level is 1, 2, or 3 just test and put code you want. Alternatively you could just multiply the looting level times the quantity to drop more. Anything you want -- it is your code.

There are lots of possible Java data structures like arrays, lists, maps, hashmaps, etc. that can each probably be used with different advantages to each. they can also be combined, like array of lists, lists of arrays, etc. I think if the map is sparse (i.e. the number of matching blocks is small compared to the overall area) then something like a list seems like it would be efficient since you'd only have entries for the blocks that actually matter. I think if the map is dense then maybe more of an array. I don't know what your structure really looks like, but for example imagine a list or array of chunk coordinates (you could even create a custom class containing the coordinates). Then you'd just go through the list/array and check at each chunk coordinates. Basically there are a lot of ways to approach this, you might have to play around until you get something you like. I guess I would probably do this like: make a custom class containing coordinates and block type and a boolean for whether the block is placed or not. Then make a list of that class, with each entry representing a block in the structure. Then just cycle through the list marking the boolean in each entry. Make sense?

I'm not sure but I think the player logged in event likely requires more network handshaking which would provide some variability. Like maybe during the actual log in sequence the server decides it should spawn the player entity so the living update starts to tick but maybe the logged in event still requires some acknowledgement from the client. I'm just guessing and haven't looked into it, but it seems to me that "logging in" could be a process that has variability in it. I agree it does seem like an annoying race condition though. But I could see how it could logically exist.

That actually is pretty challenging. In some respects it is like a power system (like redstone) and in those systems each block checks its neighbors in sort of a distributed processing approach. However, most power systems only implement a limited range because, as you might imagine, checking for all the possible connection paths over a large area quickly grows to require significant processing. So you probably want a centralized approach, where some method checks the blocks for the pattern. But this is only easy if some starting point or maybe center point is a special block that you can use to reference all the other locations. Otherwise you'd have to constantly scan the world for any possible pattern that matches the structure, and that would again require a on of processing. So my first suggestion is that, if you haven't already, you should make one special tile entity that is meant to form maybe the starting point or the control panel or the center of your particle accelerator. Then that tile entity would have the job of detecting the completion with the idea that the rest of the structure is supposed to have a known relationship to the position of this tile entity. (You could even do cool things like this tile entity could actually suggest where to place the next block.) Then you'd be back to your original question: how to efficiently scan for completion of the particle accelerator. I'm assuming your accelerator is made up of special blocks. In that case you could have the tile entity check each time the custom block is placed. If your tile entity started out with a "map" of the needed positions, then you'd just have to "check off" each needed block until they were all in place. Like imagine that the tile entity had a list of all the relative positions that needed a block, and each time a block was placed you marked it as placed. I think that would work pretty well performance-wise, because instead of scanning the whole space and using pattern matching logic, you'd have a preset pattern that you could check off quickly and only when a potential block has been placed. Not sure if you get what I mean, but the gist is that you have a tile entity that has a map of where things should be placed, then when blocks are placed you check off the positions on the map.

I don't quite know what you're asking. Do you mean you want to detect when a player has constructed enough blocks to complete a large particle accelerator structure?

Yeah. There are ways that you can undo vines growing but that would cause additional lag, not prevent it. You can also replace vanilla versions with custom versions of all growing blocks but that will cause lag during chunk generation so you'd be changing one type of lag for another. In the end, Minecraft has a lot of potential for lag. While people sometimes dismiss Minecraft as a "simple" world, the reality is that the number of blocks being processed grows is actually very large and the graphics which look simple still need full rendering.

Sorry, that seems to be a mistake in my tutorial. I just updated it. I think I edited the text without running the code again, after a discussion with someone about the obfuscated method names. As diesieben07 says, the Eclipse editor should have warned you about the problem -- it would indicate the method doesn't exist. That is because a method only matches if all the parameters match. In fact you can have dozens of methods all with same name and they are technically different if they have different parameter types.

TheGreyGhost already explained it. If you think about it, for the graphics engine to calculate the picture when there are transparent things in the background, the only trustworthy way is to draw the stuff in the background first then blend the transparent stuff on top. Imagine you were painting something and you did a light wash of color first (i.e. the transparent part) and then painted over it with thick paint, versus doing it the other way around -- doing a wash of color over thick paint. The results are not the same: the order matters. If you leave depth mask as true, then when it comes time to render the transparent stuff there is a chance that it has will be "painted" in the scene before something in the background and then when the background is checked it is considered "behind" the transparent part so is not rendered at all (this is called culling). If you disable depth mask with false, then it will render everything even if it was supposed to be behind. This can screw things up. The fundamental problem is that Minecraft should ideally render things in order based on depth, but instead does several passes. So your entity may be rendered before water, even if the water is farther back in the background. There isn't really an easy solution to this. You can however control the order of depth and rendering within your own rendering code. I don't know how your pipes are rendered, but you could theoretically draw the transparent parts and solid parts with and without depth checking as needed.

It is weird that it says "for the type MinecraftForge". MinecraftForge isn't a class as far as I know, so it seems that you're mistakenly trying to call the method from a class that doesn't exist. Anyway, post your code and the console message errors.

I think I tried that and got concurrency errors. I'm not expert at threads, but unless you design the threads to work together you get into trouble if two threads are trying to operate on the same data -- i.e. think of one thread trying to read the array of the blocks in the world at the same time the other thread is trying to place a new block.