Render the beams inside ItemRenderSword's renderItem method, in the switch for case ENTITY, just after you call this.modelSword.render
You do not need the custom entity and you don't need to override those methods I gave you for the item. Just find a way to render the beams inside that switch.
The name of the Java file does not cause this error. Show us the code where you set the registry name of both of these items.
If you are doing that in a constructor and the classes are linked by inheritance, that might cause problems. Regardless, we need to see the code before we can trace the problem.
As for actually rendering the beams, you'd have to look at Minecraft's code for that. Look for a class called RenderDragon and see what it does in rotateCorpse. It may not render the beams there, though, and I don't know for myself.
To tell Minecraft that dropping your item should make your custom EntityItem (the one you are rendering with special code), add these to the your item class:
@Override
public boolean hasCustomEntity(ItemStack stack)
{
return true;
}
@Override
public Entity createEntity(World world, Entity location, ItemStack itemstack)
{
return new // your entity here
}
Look at the super method for createEntity to see if you need to set its position or anything else.
You say you have a render class for your item -- do you want these beams to only appear when it is tossed on the ground, or when it is in inventory as well? I'm not sure what you can and can't specify in a custom item class. Making a custom EntityItem may not be necessary if you can already alter the rendering of the item ONLY when it is on the ground.
To get the current world inside an entity method, use this.worldObj instead of world.
I get the strong feeling that you're copy-pasting without knowing what you're doing (since I've seen that exact code on Jabelar's tutorials). You may want to learn Java before you continue with modding.
I think I understand you, the 2 client events are triggered and damages a "ghost" zombie, right? Only the tick on the server will damage the real zombie?
No, it has nothing to do with client-server. The players' events (client or server) will still not target the zombie because they have no idea the zombie exists. That zombie is not included in my player's tick event, and my player is not included in that zombie's tick event.
have only done offline games before, where it is the same entity object in all the events
That could be the reason behind this misunderstanding. Forge events are not quite the same as, say, MouseEvent or KeyboardInputEvent. Those events will always have the same mouse or keyboard.
Forge events, on the other hand, are created once for every entity and will have the entity that created them. Imagine the code running like this:
- Minecraft starts 'tick all entities' phase and starts iterating through the entity list.
- The first entity in the list is, say, a player. An event is created containing that player, then fired and executed before the code moves on.
- The next entity in the list is that potion-effected zombie. An event is created containing that zombie, then fired and executed. Your if-statements filter out this zombie (because of the potion effect) so your code runs too.
- The third entity in the list is, say, another player. Once again an event is created containing this player, and once again it is fired. Your if-statements still run, but they detect that this player does not have the potion effect.
Glad you got the code working, though. Hopefully this explanation helps.
But with 2 players logged in, and a potion effect on a zombie, the LivingUpdateEvent will be dispatched to the server, and both players, and picked up by the server and both players, then the code would be executed 3 times, wouldn't it? In that case, wouldn't the entity take 3 times as much damage?
It is true that the code would be executed three times, but with a different value for entityLiving each time. Only one of those runs would include the zombie that has the effect, so only that one run would do damage. I'm not sure where you're getting the idea that something would take twice as much damage just because another entity had its events fired -- the two entities and events are completely independent.
Even if multiple entities have that effect, just take my word that this code will not run for any of them twice in one tick.
Besides that misunderstanding, did you get everything working?
As for registering the render, call the registering method from your ClientProxy in the preInit phase.
You seem to have copy-pasted my re-useable registration method, which is not necessary for you situation. Just move everything inside registerTextured into a new (non-static) method that you call from the FMLPreInitializationPhase.
it would take periodical damage for each player logged on the server, as well as on server update. Is this true?
That's not how events work. In a multi-player setting, a new event is created for each player, then fired containing only that player. Each player has their event fired just as often as they would in single-player.
the event seems to be triggering client side only
Have you confirmed this with print-outs inside your method? It should be firing on both client and server, but you should check where it is fired from and see if there are any !worldObj.isRemote calls preventing it from firing.
NBTTagCompound tag = event.entityLiving.getEntityData();
EntityPlayer player = event.entityLiving.worldObj.getPlayerEntityByName(tag.getString("FrostFeverSource"));
Why not check and cast the entityLiving to a player in the first place, instead of retrieving a tag? I don't even see where you set that tag.
What I mean:
if(event.entityLiving instanceof EntityPlayer)
{
EntityPlayer player = (EntityPlayer)event.entityLiving;
[... other stuff ...]
}
From your two posts, I see you want to render a custom entity based on some attribute of the player looking at the entity, correct?
That can be done fairly easily in the render class. Create and register your render class as usual, but override this method:
@Override
public void doRender(T entity, double x, double y, double z, float entityYaw, float partialTicks)
{
if(some condition)
{
super.doRender(entity, x, y, z, entityYaw, partialTicks);
}
}
Inside (some condition) you will check if the player is holding your item or has your potion effect or whatever. How do you access the player? Well, the nice thing about rendering classes is that we are 100% allowed to use Minecraft.getMinecraft().thePlayer to get the player instance
Use that to get the client player, do your checks, and only call the super method if the player satisfies your conditions. If the player fails your check, you will not call the super method and nothing will render.
If you want the entity to render differently but still render, that will need to be done more carefully. If that is the case, I will need more details.
Make a custom class that extends ItemSword. In the constructor, set the damage the same way ItemSword usually does, but add a little more than the tool material's damage instead.
The main reasons anybody would mod for an older version include:
1) There are many large mods that have not updated, but the modder wants both their mod and the old mod at the same time. This is especially common in large, popular modpacks, which may refuse to update until all those mods have updated... fat chance
2) The modder is just starting and thinks 1.7.10 may be easier to code for (especially if they skimmed through the many anti-JSON posts about 1.8). Saying "1.7.10 is easier" is not entirely wrong, but not entirely right either. There are pros and cons, but I don't have time to address that argument.
3) The modder thinks that Mojang's rapid-release of 1.9 and 1.10 means those versions are 'unstable' and constantly supporting the newest version would take too much work
3) Like Bright_Spark said, they simply don't like newer versions of Minecraft
That's all that came to my mind. My personal recommendation is this: if you fully plan on supporting 1.7.10, for whatever reason, start the mod in that version. Backporting is much harder than updating. However, if you are kind of thinking it'd be nice to have the mod in 1.7.10 but you want to support other versions too, start the mod in 1.9.4 or 1.10. (for anyone reading this after September 2016, those versions may be unsupported too)
0
Render the beams inside ItemRenderSword's renderItem method, in the switch for case ENTITY, just after you call this.modelSword.render
You do not need the custom entity and you don't need to override those methods I gave you for the item. Just find a way to render the beams inside that switch.
0
The name of the Java file does not cause this error. Show us the code where you set the registry name of both of these items.
If you are doing that in a constructor and the classes are linked by inheritance, that might cause problems. Regardless, we need to see the code before we can trace the problem.
0
As for actually rendering the beams, you'd have to look at Minecraft's code for that. Look for a class called RenderDragon and see what it does in rotateCorpse. It may not render the beams there, though, and I don't know for myself.
Good luck.
0
To tell Minecraft that dropping your item should make your custom EntityItem (the one you are rendering with special code), add these to the your item class:
@Override public boolean hasCustomEntity(ItemStack stack) { return true; } @Override public Entity createEntity(World world, Entity location, ItemStack itemstack) { return new // your entity here }Look at the super method for createEntity to see if you need to set its position or anything else.
You say you have a render class for your item -- do you want these beams to only appear when it is tossed on the ground, or when it is in inventory as well? I'm not sure what you can and can't specify in a custom item class. Making a custom EntityItem may not be necessary if you can already alter the rendering of the item ONLY when it is on the ground.
0
If you are indeed using 1.7.10, override onLivingUpdate() . Make sure to call the super method.
You can see how I do something similar here.
Edit: why not make a method called setBlockUnderEntity that does this?
public static boolean setBlockUnderEntity(Entity parEntity, Block toSet) { int blockX = MathHelper.floor_double(parEntity.posX); int blockY = MathHelper.floor_double(parEntity.boundingBox.minY)-1; int blockZ = MathHelper.floor_double(parEntity.posZ); return parEntity.worldObj.setBlock(blockX, blockY, blockZ, toSet); }Much simpler than your triad of methods that you will only call together.
0
To get the current world inside an entity method, use this.worldObj instead of world.
I get the strong feeling that you're copy-pasting without knowing what you're doing (since I've seen that exact code on Jabelar's tutorials). You may want to learn Java before you continue with modding.
0
No, it has nothing to do with client-server. The players' events (client or server) will still not target the zombie because they have no idea the zombie exists. That zombie is not included in my player's tick event, and my player is not included in that zombie's tick event.
That could be the reason behind this misunderstanding. Forge events are not quite the same as, say, MouseEvent or KeyboardInputEvent. Those events will always have the same mouse or keyboard.
Forge events, on the other hand, are created once for every entity and will have the entity that created them. Imagine the code running like this:
- Minecraft starts 'tick all entities' phase and starts iterating through the entity list.
- The first entity in the list is, say, a player. An event is created containing that player, then fired and executed before the code moves on.
- The next entity in the list is that potion-effected zombie. An event is created containing that zombie, then fired and executed. Your if-statements filter out this zombie (because of the potion effect) so your code runs too.
- The third entity in the list is, say, another player. Once again an event is created containing this player, and once again it is fired. Your if-statements still run, but they detect that this player does not have the potion effect.
Glad you got the code working, though. Hopefully this explanation helps.
0
First of all, you will need to make a custom EntityItem for your weapon and override the correct method in the Item class to return that EntityItem.
Second, you will need to make a custom render class and register that to your EntityItem.
I don't know any more than that. The actual effects will have to be done in your render class, but if you can get it to that point, it's a start.
0
It is true that the code would be executed three times, but with a different value for entityLiving each time. Only one of those runs would include the zombie that has the effect, so only that one run would do damage. I'm not sure where you're getting the idea that something would take twice as much damage just because another entity had its events fired -- the two entities and events are completely independent.
Even if multiple entities have that effect, just take my word that this code will not run for any of them twice in one tick.
Besides that misunderstanding, did you get everything working?
0
I just noticed this method in the Render class:
Maybe override that to always return false.
As for registering the render, call the registering method from your ClientProxy in the preInit phase.
You seem to have copy-pasted my re-useable registration method, which is not necessary for you situation. Just move everything inside registerTextured into a new (non-static) method that you call from the FMLPreInitializationPhase.
0
That's not how events work. In a multi-player setting, a new event is created for each player, then fired containing only that player. Each player has their event fired just as often as they would in single-player.
Have you confirmed this with print-outs inside your method? It should be firing on both client and server, but you should check where it is fired from and see if there are any !worldObj.isRemote calls preventing it from firing.
Why not check and cast the entityLiving to a player in the first place, instead of retrieving a tag? I don't even see where you set that tag.
What I mean:
if(event.entityLiving instanceof EntityPlayer) { EntityPlayer player = (EntityPlayer)event.entityLiving; [... other stuff ...] }0
From your two posts, I see you want to render a custom entity based on some attribute of the player looking at the entity, correct?
That can be done fairly easily in the render class. Create and register your render class as usual, but override this method:
@Override public void doRender(T entity, double x, double y, double z, float entityYaw, float partialTicks) { if(some condition) { super.doRender(entity, x, y, z, entityYaw, partialTicks); } }Inside (some condition) you will check if the player is holding your item or has your potion effect or whatever. How do you access the player? Well, the nice thing about rendering classes is that we are 100% allowed to use Minecraft.getMinecraft().thePlayer to get the player instance
Use that to get the client player, do your checks, and only call the super method if the player satisfies your conditions. If the player fails your check, you will not call the super method and nothing will render.
If you want the entity to render differently but still render, that will need to be done more carefully. If that is the case, I will need more details.
0
Aah, I forgot that you can only set a model in a RenderLivingBase subclass.
Luckily, you only need to make a few small changes. You can forget about the empty model, but add this to your RenderFireBolt class:
@Override public void doRender(EntityFireBolt entity, double x, double y, double z, float entityYaw, float partialTicks) { }This will override the render method, which usually draws an image, to do absolutely nothing. Which is what you want.
Your registration is correct, by the way, so you don't need to worry about anything there
0
Make a custom class that extends ItemSword. In the constructor, set the damage the same way ItemSword usually does, but add a little more than the tool material's damage instead.
Look at ItemSword for details/examples.
1
The main reasons anybody would mod for an older version include:
1) There are many large mods that have not updated, but the modder wants both their mod and the old mod at the same time. This is especially common in large, popular modpacks, which may refuse to update until all those mods have updated... fat chance
2) The modder is just starting and thinks 1.7.10 may be easier to code for (especially if they skimmed through the many anti-JSON posts about 1.8). Saying "1.7.10 is easier" is not entirely wrong, but not entirely right either. There are pros and cons, but I don't have time to address that argument.
3) The modder thinks that Mojang's rapid-release of 1.9 and 1.10 means those versions are 'unstable' and constantly supporting the newest version would take too much work
3) Like Bright_Spark said, they simply don't like newer versions of Minecraft
That's all that came to my mind. My personal recommendation is this: if you fully plan on supporting 1.7.10, for whatever reason, start the mod in that version. Backporting is much harder than updating. However, if you are kind of thinking it'd be nice to have the mod in 1.7.10 but you want to support other versions too, start the mod in 1.9.4 or 1.10. (for anyone reading this after September 2016, those versions may be unsupported too)