jabelar

You have to create your own timer int variable. On the initial press you would set it to the number of ticks (20 per second) you want the burst to occur, then count down every tick (maybe handle in the PlayerTickEvent) until you get to zero. If you want the firing to occur a few times over the interval, you can use modulo function to quickly check whether to fire. Anyway, it is up to you to keep track of the burst time.

Sorry but I think you need to learn Java better. Basically your problem is that Java allows multiple methods to have the same name, as long as the parameter list is different. So attackEntityAsMob(Entity entityTarget, boolean wasDamageDone) is a different method than attackEntityAsMob(Entity entityTarget). @Override is for changing the same method from a parent class. So @Override only works if you have the same method, including the same exact parameter types. You do need to @Override the actual method because that one is the one that Minecraft automatically calls. If you want to create a method with additional parameters, you'll have to call it yourself (maybe from the original) but you'll have to get the parameter you intend to pass. This is basic Java really. You should read a book on Java. Or take a free course.

What does the error message say?

so you changed: int fireModifier = EnchantmentHelper.getFireAspectModifier(this); if (fireModifier > 0) { entityTarget.setFire(fireModifier * 4); } Into just something like this: entityTarget.setFire(4); Right?

He already is. He has this code: int fireModifier = EnchantmentHelper.getFireAspectModifier(this); if (fireModifier > 0) { entityTarget.setFire(fireModifier * 4); } However, I already explained everything to him in the thread above. I told him that he either has to set the fire modifier, or he has to directly set the fire damage. Also, I think he's also asking about setting fire to everything nearby -- not necessarily attacked. So that needs to be in an update method or event. @Soulas97, it seems that you really don't know Java at all and you're trying to do a fairly complex (because it is different than other existing entities) entity mod. I like helping people, but if you don't understand how to debug a missing space in your code, or how introducing a parameter breaks the override, etc. I really don't think you'll be able to do this. I don't mean to be mean, just saying that what you're trying to do requires some significant Java (especially your other idea about breaking blocks in new pathfinding to get to attack target). I think you would do better to start with a simpler idea, extending some existing mobs and just making minor modifications.

In your code I don't see (maybe I missed it?) any code related to trying to look for entities to set fire to. I only see the attackEntityAsMob() method which I already helped you with. As mentioned you need to override the onLivingUpdate() method and add code that looks for entities within certain bounding box and then takes those and sets fire.

Actually it is not really clear what he wants. Yes he says "unlocalized" name, but his example seems like using the localized name would be more appropriate. Unlocalized is usually intended to be used within the code, and localized is usually intended for client gui purposes. In any case, now he has both he can try.

Sorry but you should show what you tried if you want help. Can't ask people to write your code for you. I already gave you the general instruction. Try to follow that instruction, post what you've tried. I'm happy to look at code, but won't write it for you. You'll learn a lot more that way.

You'd have to write code for that. You need to put the code in some sort of update method or tick event, probably onLivingUpdate() in your entity class, and there you'd check for entities within range and then with those you find you'd set fire with the same method described above.

Well, your code didn't work partly because the drops object passed into the event if from the dying entity, not from the player. What you need is to access the player that killed the entity. I believe it would look something like this: @SubscribeEvent(priority=EventPriority.NORMAL, receiveCanceled=true) public void onEvent(LivingDropsEvent event) { EntityLivingBase attacker = event.entityLiving.getLastAttacker(); if (attacker instanceof EntityPlayer) { EntityPlayer attackingPlayer = (EntityPlayer)attacker; // do what you want with attackingPlayer inventory here } } You need to understand better how Java works with referencing objects. Basically you can string various fields and methods together but only as long as they belong and are publicly accessible. And if you need to access a field of a subtype then you need to understand how to "cast" the object so that Java provides the required access. Anyway, hope this helps.

There should be a space before instanceof. if (entityTarget instanceof EntityLivingBase)

Override the canBePushed() method so that it always returns false. This method will be called automatically during collisions with your entity.

Did you read my tutorial? It has all the code. The knockback is where it checks for knockback and then modifies the motion of the target.

Okay, because you have extended EntityMob, it already has a full attackEntityAsMob() method. However, that method will only set fire if you set the enchantment fire modifier. So you have two options: 1) You can leave the attackEntityAsMob() method alone and instead set the enchantment fire modifier for your entity. 2) You can override the attackEntityAsMob() method, copy what I put in my tutorial, and at the part where where it checks for fire enchantment just modify that part so it always applies fire damage. Note also, in your entity constructor you don't give your bull fire immunity. You might want to set that to true.

The method should be called automatically. All classes that are derived (extended from) EntityLivingBase have the attackEntityAsMob() method and this is automatically called during an attack -- you shouldn't have to call it yourself. However, you should @Override it in your class to do what you want. So if you have a custom entity class you should do what I explained in the tutorial -- put that method in your class and modify the code to do what you like. What is your custom entity code? Can you post it?

Yes, look at the code in my tutorial. It will set fire on the attacked entity depending on the modifiers. In your case you might change the code to always set fire (instead of looking for other modifiers). Note that if the target is immune to fire it will not catch fire.

You might want to check out my tutorial on the subject (assuming you mean a custom mob). http://jabelarminecraft.blogspot.com/p/minecraft-forge-172-understanding_16.html The short answer is that the attackEntityAsMob() method (in the attacker entity) controls the knockback and application of enchantments and fire effects.

The extended properties is just an NBT structure that FML will automatically save and load for you. Other than that it is just an NBT like any other. You can create any NBT you want in your classes, including TileEntity. NBT sounds fancy but is just a tagged compound that allows you to easily look up values based on string key. Or do you mean you want your tile entity to access the extended properties of some other entity class?

Hmm, I was thinking that backface culling wouldn't work if the front polygon is transparent -- normally in backface culling you use it for polygons that are fully not visible, but I guess you are right -- it will probably cull the back face anyway since that is usually determined simply by the direction considered the outside of the surface. Basically in this particular case he wants an artifact that is usually undesirable.

Do you really mean "every few hours"? Like it is a very slow precession of the ripple through your image? If so, it might be more of a fundamental graphics driver thing, like a screen tearing like effect. Could even be something weird in your monitor hardware itself. Do you see the same thing if you run the mod on another computer?

No problem, glad I could help.

Hi. It looks like you might have been following my tutorial since my example there is sheep and uses similar coding style... Anyway, you can't use Item.RawLambChop because RawLambChop is not a field or method for the Item class. Instead I think you should have BetterFood.RawLambChop because you instantiated the raw lamb chop in your base class. Note that you should use Java naming convention and the field should be rawLambChop (lowercase initial "r"). Does that help?

There are quite a few events that FML triggers during the loading process, like the FMLServerStarted event and such. You can see more on how to use events on my tutorial: http://jabelarminecraft.blogspot.com/p/minecraft-forge-172-event-handling.html In your case you should probably look at the FML Life Cycle Events section of my tutorial.

The problem is that the back side is NOT invisible. I mean the transparency on the front side means that the graphics engine will try to render the back too -- I think even with culling it would decide that it should be rendered. I'm not expert on this, just thinking that a good graphics engine would try to do that. Well, it is good to be picky, but I'm not sure it would look that bad -- I'm suggesting to just remove the lattice between the panes in the window on the back side. There would still be the lattice on the other side which people would see from the back (indeed that is your current problem from the front). Anyway, someone that is good with the rendering may know a better way to do client-side disabling. However, a block is different than an entity because blocks have a regular model and so the idea of sides is well-defined whereas generally entities have all sorts of moving pieces and so I don't think there is a general solution. One other idea is to swap the texture depending on what side of the entity is facing the player running the client. That would take a little bit of coding, but shouldn't be too hard. So you could use a texture with the back transparent if the front is facing player, and use a texture with the front transparent if the back is facing the player.

Yes, I think that such an approach could work.