jabelar

I think I just figured it out -- the model 0, 0, 0 position is actually 24 pixels above ground (to prove this go to Techne and create a block at 0, 0, 0. Since a block is 16 pixels, 24 would be 1.5 blocks high.

Does your custom model extend ModelBase? If you look at the ModelTechne class, it both extends ModelBase and implements IModelCustom interface. I'm thinking that maybe if you extend ModelBase and furthermore register your custom Model with a custom Renderer it should probably just work. I don't think you should have to do any tick handling, but I'm not totally sure. Can you post your code for your custom model class, you renderer class, and the code (probably from your client proxy) where you register the model and renderer?

For the bounding box, it is actually just in the Entity class. You use the setSize() method. Interestingly, the X and Z are both set to width value, so you can't control them independently. For the damage, I remember having a similar problem when I did my Tiger. Have you set the attackDamage attribute? You can see my tutorial on attributes here: http://jabelarminecraft.blogspot.com/p/introduction-living-entities-i.html

Yes, that is exactly what I meant -- create scale fields and add the scaling before the actual rendering/calllist. I'll probably add another constructor that passes the scale factors in at time of construction, but that is just a style thing. I think the additional cool thing about this is that it will allow you to dynamically scale any piece parts without having to separate the model -- seems that would be useful for many interesting or improved animations (real animators actually squash and stretch their models quite a bit (i.e. imagine something jumping and landing). The other thing I plan to do: for the actual Model class create a convertToChild() method to use instead of addChild(). Imagine if you could take the Techne output and not have to adjust the rotation points and rotations when making them into children. The only trick is that in order to support multiple levels I think you have to crawl up the parent hierarchy to calculate the absolute values of the parent's rotation point and rotation angle.

No, I admit that is a peeve of mine but have been too lazy to work it out once and for all. When I don't have a closed form solution I usually do it brute force -- find all the pairs of translations and scales and just use them together. Actually, if you record a few of those pairs you'll probably figure out the formula since it's gotta be linear. I'm heading to bed. Glad I was able to help. If your model gets set up properly, it makes it really easy to do "amazing" animations. Twitch the tail, have the body heave up and down with breathing, tilt the head for a dramatic look. Have fun!

I think it is because you actual made the body upright then tilted it down 75 degrees. The Y and Z of the children will be relative, so if you tilt parent by 90 it will seem like a swap. I think you actually did it the right way though for a dinosaur because it is still technically a bipedal creature and the head is "on top" even though it is visually more "in front" after the body is tilted. To keep sane (my primary motivation when doing this 3D modeling stuff) you may want to only set the final rotations at the end after everything is connected and properly hierarchical. Just zero out that setRotation when you create the body for now and you'll see what I mean. It is cool that you said you did the dinosaur for your boys -- that's pretty much why I do mods too (my kids ask me to).

Regarding the tail not flashing, I'm not sure if it is related but for all the ModelRenderers you've set the texture size to 64 x 32 (I think you just kept the Techne Java line, which seems to mistakenly not put in the textureWidth and textureHeight variables). I don't know if it is related to the flashing, but seems like it could be a problem (I'm assuming your texture is actually 256 x 256 right? I'm actually crawling through your model as well, mostly for fun. You have sooo many teeth! Overall, I've got more suggestions to help you keep your sanity. First of all, I suggest working in degrees instead of radians. I usually use the following helper functions: protected float degToRad(float degrees) { return degrees * (float)Math.PI / 180 ; } protected void setRotation(ModelRenderer model, float rotX, float rotY, float rotZ) { model.rotateAngleX = degToRad(rotX); model.rotateAngleY = degToRad(rotY); model.rotateAngleZ = degToRad(rotZ); } You'll then have to go back to your setRotation calls and change the passed parameters to degrees, but frankly putting in 45F is a lot easier on the brain than 0.785398163F. I did a quick pass through your model and it didn't take long to convert to degrees. Secondly, for animation purposes later I think you need to adjust some rotation points. Because you had previously not used children, you had a lot of the rotation points at the same place, but that isn't really correct. You really want the rotation point to be the joint of the animation (i.e. any rotation). So the head and jaw and neck and teeth shouldn't really have the same rotation point. The neck should have rotation point where it attaches to the body, the head at the point where it attaches to the neck, the jaw where it attaches to the head and the teeth where they attach to the jaw. You got away with it because offsets can make it look correct, but it really won't be when you get into animating. For all these suggestions it will take some work to crawl through the model to correct it, but I think it will really help you later on. But up to you. For fun I'm going to continue to rework it a bit and I'll pass you the results. You've also got me thinking about the render flicker thing. It is a really bummer if you have to break the hierarchy just to do the 0.995 scaling trick, so I'm thinking about seeing if I can create my own extension to ModelRenderer that allows a scaling factor to be passed to it. If the ModelRenderer is aware of the scaling factor, then even the children could render properly as the children are just a recursive call to the render() after doing the parent transformations. Anyways, that would really be perfect if I can figure that out. Again, I find this stuff fun. Don't worry, I won't steal your model or anything, but I'll pass you any other thoughts as I come across them.

Still going. Since you want to control flicker on the lower jaw, I left headlowera independent, but added headlowerb and tounge as children. Again the rotation points are zeroed out, renders removed and rotations removed. Note that the rotations are also relative so you have to subtract them out. So I left headlowera rotated, but headlowerb and tongue have no rotation (they'll rotate along with headlowera). Now I'm working on the teeth.

Okay, i'm continuing and it looks like headuppera and headupperb should also just be part of head, so do the same thing -- zero out the rotation point, add them as child to head, remove the rendering for them separately, remove any rotations for them separately.

I'm still going through it. Starting with an easy one: making headb a child of head. All I had to do was: 1. modify the headb creation as follows: headb = new ModelRenderer(this, 40, 0); headb.addBox(-3F, -9F, -3F, 6, 1, 6); headb.setRotationPoint([b][color=blue]0F, 0F, 0F[/color][/b]); headb.setTextureSize(64, 32); headb.mirror = true; setRotation(headb, 0F, 0F, 0F); [b][color=blue]head.addChild(headb);[/color][/b] Since headb should have the same rotation point as head, the setRotationPoint needs to be 0, 0, 0 (relative). And I've made headb the child of head -- note make sure you use addChild() the right way around (some people think that they add head to headb as the method name is a bit ambiguous). 2. remove the separate render for headb. rendering head should be sufficient to also see headb. 3. make sure you remove the separate rotations for headb. Remove these lines: // Head headb.rotateAngleX = head.rotateAngleX; headb.rotateAngleY = head.rotateAngleY; headb.rotateAngleZ = head.rotateAngleZ; Try that and see if it works for you.

Hey, I loaded the model and it looks really cool. I really like it. I'll try to show a tooth as an added box, and maybe an arm as a child. Give me a few minutes.

Yes, the offsets need to be adjusted because the become relative. It is a bit of work, but worth it. The way it works is this -- the offset is relative to the rotation point, and the child's rotation point is relative to the parent's rotation point. So generally I think you can just subtract the parent's rotation point from the child's. Note though that if you're actually going to rotate the child you should ensure the offset is really what you want (i.e. the tail's rotation point should be at the end that attaches to the butt, the head's rotation point should be where the neck meets the body, etc). I'll see if I can adjust your model for you... Yes, regarding the flicker, like I said in my tutorial, one reason to not make a child is if you need a transformation (in this case a bit of scaling) on the part between part renders.

Not necessarily related to your problem, but are all those parts (like every separate tooth) going to move/animate separately from each other? If not, you don't need each one to have a separate ModelRenderer. Rather you can simply add more boxes to the head to add the teeth and such. And if you're going to move some part, like the tail, you should really do them as children of the part they are attached too. Then you don't have to move them if the other parts rotate. Check out my tutorial on this: http://jabelarminecraft.blogspot.com/p/complex-entity-models-including.html In that tutorial I create a complex model (a snake) with multiple moving parts, but I only have to render one part because all the others are children. Anyway, my suggestion is that no part of the model should be truly separate from the others unless you want to go crazy trying to figure out the trigonometry or unless they are truly logically independent (in terms of movement or special transformations/blending). The parts should be directly added (if they don't move on their own), or be a child (if they move on their own).

Looking at the code in Entity that calls the onEntityWalking() method, this is how it detects the block being walked on. Note that they include yOffset plus some other fixed displacement. int j1 = MathHelper.floor_double(this.posX); k = [color=blue]MathHelper.floor_double(this.posY - 0.20000000298023224D - (double)this.yOffset);[/color] int l = MathHelper.floor_double(this.posZ); Block block = this.worldObj.getBlock(j1, k, l); int i1 = this.worldObj.getBlock(j1, k - 1, l).getRenderType(); if (i1 == 11 || i1 == 32 || i1 == 21) { block = this.worldObj.getBlock(j1, k - 1, l); }

Great attitude! Some people get offended when we say "learn Java", but if you're willing to put in the work it will be quite rewarding.

That is weird. Is there anything different about the way you created the ModelRenderer for those parts? Are they children of another ModelRenderer or something? I'm thinking that you might just want to check for the same condition and force the blend yourself and see if that works. I feel like you and I are around the same skill level in Java and so I know you'll do the same stuff I would do. But I would certainly expect the entire model to be affected by the blend if all the parts are rendered consecutively.

For learning programming I strongly recommend reading an actual book instead of (or in addition to) online resources. Online information tempts you to jump around, but in programming there are some very key details that you'll miss unless they are "forced" upon you to learn. I find reading an actual book gets you to give the proper attention to the topic, and furthermore guides you through the progression of ideas better. As a quick but practical Java programming book that is not boring, I recommend Java In Easy Steps: http://www.amazon.com/Java-Easy-Steps-Fully-Updated/dp/1840784431/ref=cm_cr_pr_product_top

I think it happens in the doRender() method of RendererLivingEntity. Look for where the hurtTime field is checked for > 0 as I believe that controls the 10 ticks of red coloring. Not sure why one part of your model wouldn't color like the rest but I guess you can check the same field and color it yourself if needed.

I've been working on some wild animal entities myself. I found I got pretty good results by copying methods from EntityWolf. Basically it is an EntityAnimal that also attacks and stuff. You can remove the stuff about taming if you don't want your bear to be tamable. Anyway, I suggest looking at EntityWolf. I was able to make tiger entities that do everything I was interested in doing.

I've been interested as well in trying the SimpleNetworkWrapper method. If you find that class there is a lot of comments that explain how to use it. I think that was meant to be primary way for us lesser modders to quickly get packets working, but apparently it was buggy until very recently so people made all these other tutorials. I'll probably be trying to get this working over next couple weeks, but it is probably worth an attempt if you're up for it.

While I agree that this is a Java language learning topic, telling you to learn all of Java isn't that helpful. So I'll give you some hints on what you need to learn. Basically the method will be available depending on the object. In your code sample, you are trying to call the method on "this" But think carefully about what "this" is at the point where that code is being executed. "this" refers to the current class (actually I think an instance of the current class). So if this code is in your renderer class it refers to the renderer, not to the block object. Since the renderer class doesn't have a getBlockName() method your compiler will puke on it. So my hint is that you should change the "this" to be the block object (which should have the method). You see why this is a basic Java language question -- you're calling methods on wrong class.

By the way, to help others that might come to this thread, I created a tutorial on the topic: http://jabelarminecraft.blogspot.com/p/minecraft-forge-172-applying-entity.html

I'll have to look at this sometime. But I usually debug it by turning it around and instead of looking for a key I hope is there, instead try reading through the map and output all the keys that are there.

So what do the console messages tell you? Basically, to debug something you need to trace every step to see if it is behaving as you expect. For example, you can put a console message to print out the velocity before you modify it, an then again after you modify it. Maybe you will notice an issue there. For example, you're assuming that the player motionX and motionY are non-zero. However it is possible (I'm not sure how the Minecraft code works) that if the player collides with the ball that the collision is processed by the player entity first and it might decide to stop (i.e. set motion to 0) and then by the time you add it it is already 0. You really need to check at that level of detail -- is the velocity really changing in that line of code?

I think there is hurtResistantTime which count until it reaches maxHurtResistantTime. The attackEntityFrom() method in each entity is (I believe) called on each attack, and whether damage happens is determined there (i.e. it will check if the entity is invulnerable, whether player is in creative mode, etc.) including checking for the hurt resistance cooldown. Anyway, you might want to look at the attackEntityFrom() method in some vanilla entity classes (and superclasses) to get ideas on how damage is determined). There is also the recentlyHit which (according to the comments) is set to 100 (the Javadoc says it's set to 60 but the code in EntityLiving sets it to 100) when an entity is hit by a player. There is also hurtTime, maxHurtTime, and lastDamage which are all used related to cooldowns and such.