jabelar

What have you tried so far?

Well there is if the OP actually wants to check for actual radius (i.e. a sphere) rather than a box. If you don't check distance you'd be checking in a big cube, but the way he worded the original question made it sound like he wanted a big sphere. Of course if it doesn't matter much then yes a big cube is easier.

I'm not sure about the specific fix to the clumping problem, but I think it may be possible to override the vanilla villager AI with your own. Every EntityLiving has a public list of AI tasks called "tasks". I haven't tried it, but I suspect you could clear the vanilla EntityVillager AI tasks with a new EntityAITasks (or maybe just clear the taskEntries list within the tasks) and then build up a list of custom AI using the addTask method.

I don't know if performance is a big issue, but since you're only trying to find out if there is at least one of the block in the whole radius, you can quit the search as soon as you find one so I would probably use a "labeled break" to get out of Jacky2611's loops once I found the first occurrence. To understand how you can use a "labeled break" to get out of nested loops in Java, refer to first answer to this question: http://stackoverflow.com/questions/886955/breaking-out-of-nested-loops-in-java While some argue that breaks are evidence of a unstructured coding style, I think they have their place in performance optimization. Anyway, I don't think you should continue to check hundreds of block locations after you find one...

I find it easier to browse by traversing /build/tmp/recompSrc/ because in Eclipse package explorer everything is organized in neat folders. Also, you probably know but rather than browsing the packages or folders for something you can usually just have Eclipse find it: if you want to see the source for something that is referenced in code that you're viewing you can just right-click on the class or method and choose Open Declaration. And of course just use an Eclipse search.

Well I don't "have to tell you" anything Anyway, those are all aspects of blocks that are moddable. Not sure how much experience you have with that (I'm pretty new myself). I expect some of those things you just don't want to show, so probably related to rendering, although maybe there are also some methods/variables that can be used to control them. Righ-clicking is related to the onBlockActivated() method I think, so you'd want to override that. Honestly, the only way to progress as a Minecraft modder is to use Eclipse to follow the vanilla source code to see how Minecraft already does things, then figure out a way to intercept and modify that behavior. So find out where the break particles are controlled and then change that for your block, find out where the block interaction on right-click happens and then change that for your block, etc.

Not sure if this is a really dumb or really smart way to do it, but... Why not create an invisible block that changes position to move along with the entity? Then it could emit light like a block and also be walked on like a block.

Yeah, but what the player is looking at is a client side thing so even the look vector at some point must accept client data, right? But I guess you're saying that the look vector is somehow more secure? (I'm not trying to be argumentative, as I'm pretty new to Minecraft and the server stuff still trips me up. I just want to understand fully so I don't make the mistake later myself). Maybe you're saying that the look vector isn't itself more secure, but rather it is relative to the player position so it couldn't be hacked to cause arbitrary teleport except to legitimate things that could be seen by the player anyway?

Do you just want to do something "every 10,000 ticks". To do something every 10,000 ticks you just need a variable that is incremented every tick and then just check if it is evenly divisible by 10,000 (or whatever number you want). Most programming languages have a "modululs" operator, sometimes called the "remainder" operator. It tells you if something is evenly divisible if the remainder = 0. In Java this operator uses the percent sign "%". You can find out more here: http://www.cafeaulait.org/course/week2/15.html So if you had an int variable called tick_count, you would know you're on a 10,000 x n tick with something like the following logical expression:

I beg to differ. Look vectors are exactly what is needed here. objectMouseOver is useful, but can only be used on the client, so if you want to be able to teleport on the server without sending a packet, the look vector is perfect. I've used it lots of times. @OP accessing Minecraft.getMinecraft().anything will crash your game if you try to access it on the server side (i.e. when the world is NOT remote), since getMinecraft() is all client-side only. If you want to use objectMouseOver, you will need to do so only on the client and send a packet containing the coordinates you need, then resolve the teleport from the server side; otherwise, you can try using the look vector. Yeah, this is the same mistake I made on separate topic you just helped me with (i.e. client versus server side) I still think that the mouseOver is more specifically what this person wants though (says he wants to teleport to a block located in direction looking, not just in direction looking), so maybe doing it like you said -- use mouseOver in client but send packet from client to server. I say this because the look vector doesn't directly give you a block position, whereas mouseOver already has all the "goodness" of figuring out if there is an object under your cursor that has a meaningful position in the world. If you use lookvector then you'll have to do something to check positions in direction of the look until you find something. I guess neither way is hard, but when modding since I'm a noob to Minecraft (obviously) I tend to try to make use of any vanilla code that is useful and it seems that mouseOver is sort of sophisticated.

Okay, thanks. Solution: I was referencing a client side player instance rather than a server side.

Okay, I had some success by changing the way I reference the player. Originally I had: Which I replaced with: I guess I'm okay now that it works, but I like to understand code that doesn't behave how I expect. Why would the original code make the entity look like it attacked (but with no damage) whereas the second version works? I'm guessing it has to do with server side versus client side? Maybe the first one wasn't properly updating the server version of the player object so what looked like an attack on the client side didn't really cause damage? client - server stuff is still something I mess up a lot ...

[Deleted since CoolAlias rightfully pointed out it was wrong due to being client-side]

Ah, normalized vectors. Oh so handy! Actually they are handy as they can be resolved into an actual direction. The problem here is that the look vector is wrong for this purpose, there is other methods for returning the block your cursor is actually targeting. I haven't used it in a while, but I think something like Minecraft.getMinecraft().objectMouseOver would be better. In any case, Minecraft of course has methods for figuring out the block that you can interact with and you need to invoke those, rather than a look vector.

Depending on what you want to do, you could just make it so that when someone crafts a vanilla axe they get yours instead -- that would be just a matter of replacing the recipe. If yours is an extension of the vanilla axe, it should work pretty well in all code where an axe is needed. For most practical purposes it your axe would be the axes players would get. If you really want to eliminate vanilla axes entirely (e.g. villagers can never have them, etc.) that can get pretty involved. You technically can eliminate axes from the item Registry, but I suspect that would cause trouble because I expect that axes are referred to in various places through the vanilla code.

(Forge version = 1047) [updated subject to be more specific] Okay, so I have created an EntityTiger that is essentially a re-textured vanilla wolf, and it works perfectly (basically behaves like a wolf in that it is passive unless attacked, can be tamed, hunts sheep on its own, etc.) I want to make a sub-class EntityManEatingTiger which extends EntityTiger but basically is always hostile and will attack a player on sight. I thought I could do this by setAngry(true) and setting target to the player (I realize this isn't really good practice for multiplayer, but will fix that later). I also have setTamed(false). So I have an untamed, angry tiger with player as the target. It does in fact look angry (red eyes texture), and it follows my player and leaps at it just like it is attacking me. However, it doesn't actually do any damage (not a real attack). If I hit it though, then it will attack me for real. So I'm missing something -- how do you make it actually attack rather than follow me with red eyes? Here are the two classes. EntityTiger EntityManEatingTiger

Thanks. Yeah, the first idea is pretty much what I expected when I asked "Is the only solution to record the instance in the superclass and reference it here?". But I like the second idea better gives me more specific control especially since I plan to override much of the behavior (can't have a man-eating tiger act like a regular tiger after all...)

(Using Forge 1047) Okay, I'm doing something that should be simple but have gotten confused. I am creating a tiger entity which is essentially a re-textured wolf at the moment (I plan to more drastically mod the behavior later but for now it is pretty much just an orange striped wolf). This works great -- nothing wrong with tiger entity. Next I wanted to extend the tiger class to create special case of a "man-eating" tiger that basically is always hostile and cannot be tamed. The problem is that the AI task list is set up in the superclass EntityTiger but I want to override some of the AI. I'm getting stuck because my constructor for EntityManEatingTiger would add additional AI tasks but would still have the superclass tasks (I think). There is a removeTask method but it seems to reference an instance of the AI class which isn't really available at the sub-class (I suppose I could store instances in variables and pass them, but seems clumsy). So basically my main issue is I want to remove a specific AI task from the superclass's AI task list during the subclass constructor. Here is constructor of EntityTiger: And suppose I want to remove the begging task in the subclass EntityManEatingTiger (which extends EntityTiger) constructor: I know the removeTask must be wrong because it is referencing a new instance of the EntityAIBegTiger rather than whatever instance was added in superclass constructor. Is the only solution to record the instance in the superclass and reference it here? Or is there some better way to organize the AI task list generation? Maybe create some other method or even superclass constructor to call?

Wow you're right. That is one of those cases where you get blind to an error. I checked it over so many times and compared with the Minecraft assets folder and my brain just kept seeing the file within the sounds folder rather than beside it. So yes, the solution to my specific problem was that the sounds.json should be beside the sounds folder, not within it. The answer to my general question (what is proper way to reference your sounds) is that you do need to put your modid in front of the sound name in order to decode it from your sounds.json otherwise it will pick up the vanilla sound.

Actually, I usually have Eclipse set up to automatically put those in on save, but I guess when I set up Eclipse on this new computer I forgot to set the preferences. So now I've got them in there. Thanks.

Like everyone here has said, from painful personal experience that migrating a mod from 1.6.4 to 1.7.2 is a very tedious undertaking. Basically we are now modding a new code base. There are functions that are entirely different, registrations that are entirely different, asset organization that are entirely different. I'm not aware of any way except to use the IDE (like Eclipse) to help flag your problems and then crawl through and learn to fix each one. The fixes aren't always easy either -- for example if you relied on block and item IDs those are now referenced differently, if you registered sounds those are now registered differently. Again, the best way to explain it is that all of the Minecraft code as well as the Forge code has been modified extensively and it will ripple through your entire mod code. We're actually modding a different game now (no exaggeration)! Anyway, just look at everything flagged in Eclipse and fix it one by one. Note that just because you see 21,000 errors it doesn't mean you will have to fix that many -- for many fixes it will clean up whole swaths of reported errors. Unless you had one million lines of code I don't expect you have to actually fix 21,000 lines of code. Search and replace (carefully! make sure you use the case sensitive and whole word option when search and replacing, else you can really screw up your code irreparably) should get you pretty far.

I know it is already explained above, but just to really emphasize to those (like me) who are fairly new to Minecraft modding: it can be extremely frustrating working with the early versions of Forge after a major upgrade of Minecraft because so many functions are still obfuscated. I know just enough programming to sometimes figure out a few pieces of the obfuscated code, but generally once you hit the obfuscated functions you may get stuck going much further. For example, in 1.6.4 I was quite capable to make custom furnaces and stuff fairly handily, but now I keep getting stuck on 1.7.2 after getting to a certain point where the obfuscation gets in the way. Basically, be prepared to hit limits depending on what you delve into. Thanks to all those at MCP who are working to break through this for us lesser programmers! I do like the idea of a crowd-sourced de-obfuscation. I have certainly been able to figure out a few functions that would probably be useful to others.

I think I was successful in creating custom crops with 1.7.2. I did it as follows. I extended BlockCrops with my own version (I usually do this when modding to allow more control where possible, but you should be able to do this with vanilla BlockCrops): https://gist.github.com/anonymous/9797206 Made a blueberry bush block with: https://gist.github.com/anonymous/9796922 I extended ItemSeedFood with my own version (I usually do this when modding to allow more control where possible, but you should be able to do this with vanilla ItemSeedFood): https://gist.github.com/anonymous/9796951 I made the blueberry seed food item with: https://gist.github.com/anonymous/9796968 Then in my main class of the mod I registered everything with: https://gist.github.com/anonymous/9797030

(This is my first posting here, so let me know if I'm breaking any posting protocol) I'm using latest/recent forge = 1047 Okay, I am trying a simple experiment to learn the new sound registration using sounds.json and can't quite make it work. I'm pretty sure I have my assets folders organized properly, since other assets like textures work fine. I also have properly used the plural "sounds" instead of "sound". Anyway, I have put my sounds.json file in following folder: path: E:\Forge\eclipse\WildAnimals\src\assets\wildanimals\sounds. I think this is correct: "WildAnimals" is my Eclipse project name, "wildanimals" is the modid. I have put the sounds.json file in that folder and also put sub folders (with paths that match sounds.json) for the actual sounds. Okay, to test this I have basically created a tiger entity that is pretty much an exact copy of a vanilla wolf except with an orange texture, with the idea that I would replace the sounds to sound more like a tiger. I copied the actual sounds into my mod's sounds assets path described above. Here is my sounds.json: https://gist.github.com/anonymous/9796472 To test this, in the EntityTiger I have the following method: https://gist.github.com/anonymous/9796757 I'm purposefully trying various references to aid my understanding of how to do it properly. In other words, I'm trying to see which sounds.json is actually being accessed. When I run my mod, it generally works (spawns tiger in jungle, the tigers act like wolves except with orange texure) however I get the following console errors: [16:55:03] [Client thread/WARN]: Unable to play unknown soundEvent: minecraft:mob.tiger.step [16:55:03] [Client thread/WARN]: Unable to play unknown soundEvent: wildanimals:mob.tiger.step I do hear a step sound as well, which I assume is the vanilla wolf sound since there is no error related to that. In other words, I just can't seem to figure out how to get it to reference my sounds.json file. If I don't put any modid reference, it seems to grab the vanilla sounds.json, proven by fact that the wolf sound works and the tiger one fails (since there is no vanilla tiger). Even when I explicitly tell it to use my modid asset it fails, but I don't understand this since that json does define mob.tiger.step. So it all comes down to this, what step am I missing to ensure that Minecraft looks up the sounds based on my json rather than the vanilla one? Is there some additional step to register the json? Is there some build-path setting in Eclipse I have wrong? Or maybe I have the json in wrong path despite all my other assets working in same path? Or what?

What was the solution? I have an almost identical issue. I'm using latest Forge (.1047) and am getting an "unable to play soundEvent" error. I have assets folder path that I have double checked (and yes it uses the plural "sounds" not "sound"). My sounds.json is pretty much just copied from the wolf portion of the vanilla sounds.json and the sounds themselves are copied from wolf as well so are valid .ogg files. (I'll change to my own later, just using wolf to debug this issue). So what was solution in your case? Thanks!