jabelar

Where do you call the renderInformation() method? From your base class? Your renderer registration happens in that method, and it is not clear from the code you posted that the method ever gets called.

I think you want to selectively cancel the event (assuming it is cancelable). In other words, if you see that it is something you want to prevent you cancel it, otherwise you don't (and the vanilla processing will continue as expected). So the key is the test for what you want. Are you having trouble with detecting just the action that you care about?

Yeah, the Java/Techne models are easy because you can name each part in Java and you can have parts be child of another and each has independent position and rotation. So animation is actually very easy as long as you set up the initial model correctly (i.e. rotation points in right place for joints and child hierarchy set up properly). I assume it is possible with OBJ models as well, but maybe not built in. I think the OBJ models in forge work fine for static models (i.e. like blocks) or if the whole model rotates and moves together. But as you mention, if there isn't a built-in way to designate multiple pieces then you'd want to actually make each piece its own model and use Java to render it such that it is kept connected and animated properly.

The key to animating a model is being able to control each part, especially in a hierarchical way. I'm not that familiar with OBJ models, and I'm sure they can have hierarchical parts, but we need parts that can be referenced in Java to control the animation. So for example, if you could make an OBJ model that has a couple parts in a connected hierarchy (e.g, say a hand attached to a forearm attached to an upper arm attached to a shoulder) in Minecraft such that Java can reference each part then I think I can probably help create a tutorial for the actual animation.

Techne is okay but it is just a starting point. It is really just an tool for creating the Java code that can be used as a model in Minecraft. I personally find that it has a few mistakes that are annoying, but I admit I still use it as a visualization tool because it is easy to use, and I also use it to get my texture offsets adjusted. But Techne has almost nothing to do with animation. Animation is going to require Java coding. It isn't that hard though -- all you need to do is set the rotation point and rotation angle of each piece in a way that gives you the animation effect that you want. I have a personal technique that I developed where I use a 2-D array to step through all the various angles needed, because otherwise people can get confused by trying to use a bunch of trigonometry and other spatial mathematics. Did you read my animation tutorial? Anyway, Techne is only a starting point. If you're wanting to animate you'll have to do some programming to.

I'm somewhat suspicious that there may be a problem in this part of your code, in your config GUI class: public class ZaetConfigGUI extends GuiConfig { public ZaetConfigGUI() { super(new GuiMainMenu(), new ConfigElement(Config.config.getCategory("textures")).getChildElements(), "zaet", false, false, "./config/zaet/config.cfg"); } } I have a simpler config GUI working and the code for mine looks like: public WildAnimalsConfigGUI(GuiScreen parent) { super(parent, new ConfigElement(WildAnimals.config.getCategory(Configuration.CATEGORY_GENERAL)).getChildElements(), WildAnimals.MODID, false, false, GuiConfig.getAbridgedConfigPath(WildAnimals.config.toString())); } I understand that some of the differences are simply due to the way you've set up your class structure, so may not be a problem. But it might be good to break down this line a bit to see if it is doing what you expect. In particular, see if the category is working, maybe try using a built in category to see if you can get that working first, maybe double check the config file path and maybe try doing it with the abridged config path method I used. I just feel that the problem is somewhere in this line. Just a hunch, but a lot has to be working right for this line to execute as expected.

Do you mean where it goes red for a bit? Or the knockback effect? I believe the red effect is controlled by the hurt timer in the attackEntityFrom method of the target entity. The knockback effect is applied in the attackEntityAsMob method.

Basically if I want my mod to work with yours I can choose to: 1) just say "hey can you make some deobfuscated methods that we agree on?" No Java interface but just trust you'll implement the methods as agreed. b) say "I'll expose an deobfuscated API in my obfuscated mod that exposes a Java interface that you can implement (without needing source)" z) say "Here's source code for a Java interface that I hope you expose as a deobfuscated API in your obfuscated mod." All three methods can work, but are just different perspectives on the same problem. Sounds like Redstone is taking the third approach.

This is kinda a complicated question. As diesieben07 indicates, the word "interface" can mean different things. In Java it specifically means a set of public unimplemented methods (someday soon Java will support "default" methods in interfaces allowing some implementation) that enforces compliance on those classes that implement it. The Java interfaces are mostly intended for enforcing compliance within an internal development team. For example, if I had a team of software coders working on something I could define the interfaces for them to implement and then they would go off an implement them and I would be sure that the result would have the methods I expect so I could assign another software developer to write code that calls those interfaces. There is a secondary use of Java interfaces in helping provide "multiple inheritance". This is because Java allows you to test instanceof for interfaces. You can only extend one class, but you can implement multiple interfaces. So if I wanted to group a bunch of classes that were not extending the same parent class I could define an empty interface and have all the classes implement it and then I could treat them all as instances of that interface. Not sure if you know what I mean, but I do find this useful sometimes. An API is usually a bit more "external". It is telling other people how to access the functionality and resources of your code. But you might have no interaction with those people at all. You just publish your compiled code and a documented API and they can use it how they want. I'm not entirely sure why someone would put a Java interface in an API. It is not directly callable because the interface isn't implemented. It can be used to allow the mod with the API to "discover" and use your classes though. For example, imagine that there was a mod that wanted to add sea life entities to Minecraft and they wanted to be aware if your mod also has sea life entities. Then the API could provide a Java interface for sea life, you could implement that interface in your seal life entity classes, and in their mod whenever they tested for instanceof they would also see all your entities (and further know how to access them, through the methods the interface forces you to implement). Not sure if that is entirely clear. But I would say that generally a Java interface is more about internal developers working together on the same code base, and an API is about external developers being able to interact with your code product.

That's interesting -- why doesn't Eclipse complain about that? I didn't know you could refer to a declared but uninitialized field. Are object fields initialized as null (I guess it makes some sense from a memory reservation point of view or something) as soon as they're declared? Just surprised Eclipse doesn't warn about something like that....

Yes, I should have mentioned that. Here is tutorial on @Optional annotation. http://minalien.com/minecraft-forge-feature-spotlight-optional-annotation/

What kind of model are you using? Techne/Java or OBJ? If using Techne/Java then you might be interested in my tutorial on animating complex models: I have a tutorial on doing complex models with animation. See: http://jabelarminecraft.blogspot.com/p/complex-entity-models-including.html

I think people are confusing "using open source code" with "using an API". If someone writes an "API" but then gives out the open source code for it, you certainly are allowed to use it. But that is just copying code, not using an API. An API is an agreed upon set of calls between two independently developed pieces of code. That's the whole point. You want to take advantage of the other developers' effort by depending on it. Imagine I made a mod that did some cool world generation and had and API called generateCoolWorld(). You would use my mod (required dependency) and call that method. But I could independently keep improving what that does -- maybe fix bugs, or make it even cooler world. You could drop in any version of my mod and the API would be there for you -- the API is like a "contract" or standard. You should never have to re-build your mod because I fixed a bug in my API. You just update my mod instead. There is nothing wrong with using open source code, but if you're building it then I'm pretty sure it isn't an "API".

I have a tutorial on doing complex models with animation. See: http://jabelarminecraft.blogspot.com/p/complex-entity-models-including.html

You need to post the whole crash report. The crash reports usually tell you quite a bit about exactly where the issue is. Learn to read through the crash report and think about what it is saying. What line of code did it say was causing the crash? If it was your code, then look at what might be wrong, and if it was forge code look to see which of your code called that forge code. Anyway post the complete crash report, not just the top line.

You're supposed to wait more than a few hours before bumping your own topic. anyway, I don't think there is a dedicated event for dismounting. However, it should be easy to check if something is mounted so you can monitor that (maybe with player tick event) and do what you want. I think the EntityPlayerSP and EntityPlayerMP have a public isRiding() method that you can check. If you keep track of that, you will be able to detect when there is a dismount because at some point it will be riding then it will be not riding. If you're only concerned about a custom entity of yours, you can also do this the other way -- in the update task for the entity you could check if it is being ridden and similarly look for a dismount.

I think people often get confused about what an API is. I get confused about it too, but here is my understanding (feel free to correct me). Normally after compilation and obfuscation a Java mod's functionality isn't really accessible in a human-readable and accessible way. However, people making a mod can choose to expose functionality as an API by constructing their build (I think you can identify API code in the build.gradle if you're creating an API) such that portions are not obfuscated and can be referenced by their original method name. The trick then is to make your dev environment "know about" this API so that when you use the API methods in your code there isn't any error. I think there may be two ways -- you can bring the source over but segregate it as required code that doesn't get built into your mod (I think that is what diesieben07 is suggesting above), or you can actually bring the actual mod into your run location so it is accessed similar to how it will be when you mod is actually published. What you don't want to do is to bring their source code into your mod. Yes you want Eclipse to recognize the methods from the API, but that should be like other libraries instead of actually part of your code. I don't know all the details to do the above right, but that is the general concept. You might want to check out CoolAlias' tutorial on APIs: http://www.minecraftforum.net/topic/2496232-tutorial-modding-with-apis/

What about the frustum stuff I recommended? That code exactly determines what is shown on the player screen. I don't think faceEntity is the right code for what you're looking for -- that code just turns the head to make an entity to look in the right direction. Do you want to force the player to look at something? Even if it is facing, don't you care whether the view is blocked? The frustum will tell you whether something is already in the camera view, and the canEntityBeSeen() method will tell you if the view is blocked. I feel like those are closer to what you're trying to do.

Okay. I got excited because the release notes for these recent releases focused on a lot of comments related to merging these functions, and also other people picked up on it -- for example the tutorial I found was "news" about the new feature. Yeah, sure anyone can extend GuiScreen and create a custom event to post, but these are the "official" utilities. It is like the fiasco with the Netty handling where several people came up with their own packet systems then people started using some of those only to find they were flawed, and then finally the simple network wrapper system seems ready to go. It is true that anyone could create a packet system on their own -- I did and still use my own -- but now I recommend that people use the "official" one. Just today I responded to a person who was getting a memory leak because they had followed the older Netty tutorial. I think in a modding support forum you have to consider the different skill levels (Java wise) of the people trying to mod. There are people who are still missing basic Java, there are people like me who are fairly confident but still fumble some code, and there are expert. For those first two categories, using "official" hooks is the way to go. So when cpw finally gets SimpleNetworkWrapper going, or when they add a new event, it is worth posting as "news" to us.

Is your packet system based on this tutorial? http://www.minecraftforge.net/wiki/Netty_Packet_Handling You'll see that there is now a warning on that tutorial saying it creates memory leaks and should not be used. Instead you need to use the new SimpleNetworkWrapper system: http://www.minecraftforge.net/forum/index.php/topic,20135.0.html

Well if you follow the call hierarchy in Eclipse, this event is created and posted in the onItemUseFinish() method in the FMLEventFactory class, which is called by the onItemUseFinish() method in EntityPlayer. And that is called by onUpdate() method in EntityPlayer as well as onItemUseFinish() in EntityPlayerMP as well as handleHealUpdate() in EntityPlayer. So it seems likely that it is getting posted. How did you test this? You need to completely eat something, or similar. What bus did your register the event handler to?

I'm not sure if you understand where this source code is coming from. Mojang (Minecraft developers) don't publish their code and it is provided to public in a compiled and obfuscated format -- basically it is not human readable. However, Java is actually fairly prone to decompilation and deobfuscation by people dedicated to the task. So some people have done that, and I think that is what the MCP does -- it maps the obfuscated code to deobfuscated code, making it essentially human readable. However, each time there is a major version upgrade to Minecraft the work has to be done over again. And it is never really complete. So the weird method and parameter names you see are those areas of the code that they have not gotten around to deobfuscate. Whether or not you can change them is really according to how Java works. If they are local parameter names going into a method that you're overriding or copying, of course you can change them. However, if they are method names you have to think more carefully and understand what may be calling the method. If some vanilla code elsewhere in Minecraft will call the method then of course you can't change the name because then it will break the call. But if the method is only called within a class that you have control over, maybe that you copied, then of course you can change the name. So those names are not really a "naming convention" but rather they are unfinished part of the deobfuscation and are admittedly not human readable.

Awesome. The reason I perservered with you is because I knew you were close and just needed the push. Programming is about details and understanding every line of execution. Printing to console can get you a long way to helping you trace the execution and detect what is going wrong. With that skill alone you'll advance very quickly. Cheers!

EntityLivingBase has a method called canEntityBeSeen() which should do the job. The code for that class is: /** * returns true if the entity provided in the argument can be seen. (Raytrace) */ public boolean canEntityBeSeen(Entity par1Entity) { return this.worldObj.rayTraceBlocks(this.worldObj.getWorldVec3Pool().getVecFromPool(this.posX, this.posY + (double)this.getEyeHeight(), this.posZ), this.worldObj.getWorldVec3Pool().getVecFromPool(par1Entity.posX, par1Entity.posY + (double)par1Entity.getEyeHeight(), par1Entity.posZ)) == null; } However, while the above method is good enough for AI (like for a mob to notice player) I'm not sure it technically finds all cases where a player could possibly see something. To check if something is being rendered to the player, you might need to consider the "frustum" (http://en.wikipedia.org/wiki/Frustum) which is how the rendering determines that something is possibly in camera view so needs to be rendered. You might want to consider this method in the Frustrum class (notice that Frustrum class name is misspelled with extra "r"). Here is the method that might be interesting (it checks that a bounding box, which could be for an entity, is in the camera view). /** * Returns true if the bounding box is inside all 6 clipping planes, otherwise returns false. */ public boolean isBoundingBoxInFrustum(AxisAlignedBB par1AxisAlignedBB) { return this.isBoxInFrustum(par1AxisAlignedBB.minX, par1AxisAlignedBB.minY, par1AxisAlignedBB.minZ, par1AxisAlignedBB.maxX, par1AxisAlignedBB.maxY, par1AxisAlignedBB.maxZ); }

@Nevermind, the code example was an example and the TheClassWhereYouHaveYouExperienceStuff needs to be changed to the name of your event handler class. Based on your previous code posted above, I think you called it PlayerEventHandler, so in that case it would be: MinecraftForge.EVENT_BUS.register(new PlayerEventHandler()); By the way if you want to know more about event handlers, I have a tutorial with list of which events are on which bus (and explanation on how to check package to figure this out yourself), see: http://jabelarminecraft.blogspot.com/p/minecraft-forge-172-event-handling.html