The main reason I say do not learn by making a mod is that when things go wrong or don't work (which will inevitably happen), how will you know whether it is a java issue or a modding issue? So you will ask here and just get told to "go learn Java".
You NEED to be able to read and understand exceptions and be able to debug your own code.
When there is no exception, but it isn't doing what you expected, that is when you come and ask us for assistance.
The people on this forum assume that the person they are helping has java knowledge, so understands what they are telling them to do without writing the code for them.
i starting watching lessons from Stanford university, I'm surprised at how simular it is to minecraft commandblocks using scoreboards with commands, tellraw. and trigger boards etc. at first i felt like what i was learning had no connection to minecraft but I'm starting to see connections. this is the playlist I'm using the following video
I find it to be easy to fallow and somewhat entertaining. i don't know what I'm going to get out of it yet because I'm not finished. but i think when all is said and done i think its an awesome way to learn java. in the first video he does a really good job of explaining why we cant just jump into making programs (in my case mods) because i need to understand the language first
his example "writing code is just like writing an essay. you cant be a good essay writing, without learning the language you want to write in. if you don't learn English, you cant be a good English essay writer. if you don'T know java (or another coding language) you cant write good code"
i had never looked at it that way before i saw the video, and i use to always want to skip java because in my mind. i was thinking "i don't want to learn java, i want to learn forge" but now i kinda understand why learning java is so important first.
watching the video also teaches good coding habits i have better foundation as a future coder because of good habits that im setting for myself
1
Aha got it! You made the same mistake in the Renderer by accessing a TileEntity instance that is never changed:
You need to learn about casting. Up-casting is when you tell Java to assume that the TileEntity passed in by renderTileEntityAt is actually a TileEntityVerticalTrafficLight. That will let you access getPower() by using the actual TileEntity that the renderer is checking
I do this at the beginning of my methods:
@Override public void renderTileEntityAt(TileEntity te, double x, double y, double z, float par5) { final float SC = 0.0625F; if(te instanceof TETesla) { TETesla tesla = (TETesla)te; // now you can use it! GL11.glPushMatrix(); // bind texture int frame = getFrame(tesla.getTicks()); // here I use the casted version this.bindTexture(textures[frame]); // set location GL11.glTranslatef((float) x + 0.5F, (float) y + 1.5F, (float) z + 0.5F); // rotate so it's not upside down GL11.glPushMatrix(); GL11.glRotatef(180F, 0.0F, 0.0F, 1.0F); this.model.render(null, 0, 0, 0, 0, 0, SC); GL11.glPopMatrix(); GL11.glPopMatrix(); } }1
My Slime Golem knocks players directly back from the direction they are facing by calling Entity#addVelocity(addX, addY, addZ)
However, I notice that doing it this way does not work in Creative mode or if the player cannot be harmed. addVelocity only seems to take effect if I call attackEntityFrom as well:
My code:
private void knockbackTarget(Entity entity, final double KNOCKBACK_FACTOR) { double dX = (entity.posX - this.posX) * KNOCKBACK_FACTOR; double dZ = (entity.posZ - this.posZ) * KNOCKBACK_FACTOR; entity.addVelocity(dX, KNOCKBACK_FACTOR / 4, dZ); entity.attackEntityFrom(DamageSource.causeMobDamage(this), 0.1F); }The math here is in the first two lines. By subtracting positions I get a result that is either positive or negative.
This is not the best way to do this. It's just an easy, concise way that fit my needs. One drawback of this is that the knockback distance INCREASES when you are further away from the source.
To send the player the direction they are looking, instead of directly away, just switch the two differences like this:
Hopefully this helps. I know it's not great but it's something.
Happy Modding!
1
If you are overriding the writeToNBT and readFromNBT methods, you should put this.markDirty() in every setter method so any changes are saved.
Besides that, here is why your texture is not changing:
You put this in your Block class. Two things: All Blocks are a single instance, so you are accessing a single instance of your TileEntity. However, all Entity classes (including TileEntity) are initialized separately by using the createNewTileEntity method you override. Basically, you're setting the values for te but accessing the values from another instance.
Do not do that. You can access the actual TileEntity, the one that the Renderer checks for values, with this:
Use that in onNeighborBlockChange instead of making a class variable to hold one universal TileEntity that, as far as the game is concerned, has no location and therefore does not exist in the world. You may also consider casting to TileEntityVerticalTrafficLight only after an instanceof check.
1
Make a new post for this. Include both the EntityDog.java and RenderDog.java and I will help you there.
1
Okay, so for a 1.7.10 TileEntity here is what I have done in the past:
package com.exmod.tileentity; import net.minecraft.client.renderer.tileentity.TileEntitySpecialRenderer; import net.minecraft.tileentity.TileEntity; public class TENewtonsCradle extends TileEntity { private int ticksExisted; private int power; public TENewtonsCradle() { this.setTicksExisted(0); this.setPower(0); } @Override public void updateEntity() { ++this.ticksExisted; } public int getTicksExisted() { return ticksExisted; } public void setTicksExisted(int ticksExisted) { this.ticksExisted = ticksExisted; } public int getPower() { return power; } public void setPower(int ticksExisted) { this.power = ticksExisted; } }I notice that your power variable was static -- bad idea. That will make every traffic light change texture at the same time. As an example I added a field called 'power' to the above example with getter and setter methods.
Inside your TESR (TileEntitySpecialRenderer) class you should:
- first, inside renderTileEntityAt you should check and cast the TileEntity passed as an argument.
Example:
@Override public void renderTileEntityAt(TileEntity te, double x, double y, double z, float f) { final float SCALE = 0.0625F; if(te instanceof TENewtonsCradle) { TENewtonsCradle cradle = (TENewtonsCradle)te; // do GL stuff..... // bind texture and render Minecraft.getMinecraft().renderEngine.bindTexture(TEXTURE); this.model.render(null, 0, 0, 0, 0, 0, SCALE); // pop GL matrices } else { System.out.println("Found non-TENewtonsCradle TileEntity at (" + te.xCoord + ", " + te.yCoord + ", " + te.zCoord + ")"); te.worldObj.removeTileEntity(te.xCoord, te.yCoord, te.zCoord); te.worldObj.setBlock(te.xCoord, te.yCoord, te.zCoord, Blocks.air); } }This is in my TESR and it first checks that the TE can be cast to my TE. If that passes, it makes a local TENewtonsCradle for me to access methods like getTicksExisted() and getPower()
Just to clarify, here is the code I posted earlier for you to use inside your render class where you bind the texture:
if (cradle.getPower() == 0) { if(cradle.getTicksExisted() % 20 == 0) { textureNum++; textureNum %= POWER_0_TEXTURES; } switch(textureNum) { case 0: Minecraft.getMinecraft().renderEngine.bindTexture(texture); break; case 1: Minecraft.getMinecraft().renderEngine.bindTexture(texture3); break; } } else { Minecraft.getMinecraft().renderEngine.bindTexture(texture2); }I'm not certain what you want to accomplish, but you may want to change ticksExisted to ticksPowered and keep track of how long the block has been powered rather than how long it has existed. To do that you would only increment ticksExisted inside onUpdate if it is being powered. Other tweaking will be needed.
That's as much as I can help you for now. It will take a bit of math and thinking to do what you want, but that is essential for you to learn. Happy Modding!
Edit: Don't bump. I was getting to it :/
1
So hopefully you have all your .JSON files set up.
Here is the Minecraft file for models > item > leather_helmet.JSON
{ "parent": "builtin/generated", "textures": { "layer0": "items/leather_helmet", "layer1": "items/leather_helmet_overlay" }, "display": { "thirdperson": { "rotation": [ -90, 0, 0 ], "translation": [ 0, 1, -2.25 ], "scale": [ 0.55, 0.55, 0.55 ] }, "firstperson": { "rotation": [ 0, -135, 25 ], "translation": [ 0, 4, 2 ], "scale": [ 1.7, 1.7, 1.7 ] } } }The vital part is where it lists two layers under the "textures" attribute. I don't remember, but I think there is also a method inside the Item class called getColorFromItemStack or something like that. Actually that might just be for 1.7.10..... I don't remember.
To register multiple model files for items, I found one example that did this where they register item renders:
the register function was just a local helper function that calls the Minecraft render manager and all that. It looks like this:
private void register(Item item, int meta, String modelName) { Minecraft.getMinecraft().getRenderItem().getItemModelMesher().register(item, meta, new ModelResourceLocation(ExampleMod.MODID + ":" + modelName, "inventory")); }In this example, there were three item model files:
models > item > meta_item_0.JSON
models > item > meta_item_1.JSON
models > item > meta_item_2.JSON
Each specified a different texture where necessary. Hopefully this is what you are asking about.
Also look at this post where they solved the same problem.
1
I'm assuming this is in the render code for something. What you need to do is add a timer to track how many ticks the current texture has been used.
Really I need more context so I know what you have access to.
If you have access to an Entity you can access the ticksExisted field.
Then to change the texture every 20 ticks (1 second) you do
private boolean isTexture1; // class field if(ticksExisted % 20 == 0) { isTexture1 = !isTexture1; // other stuff }If you have access to a TileEntity you can make a field in there that does the same thing: inside updateEntity or whatever it's called you increment a field every tick, then access it from the other code.
Here's a revised version of your other code that also allows for more than two textures when power == 0
private int ticksExisted = 0; // class field private int textureNum = 0; // class field private final int POWER_0_TEXTURES = 2; // how many textures it has when power == 0 // then inside a method that's called every tick ticksExisted++; // then inside your other method if (power == 0) { if(ticksExisted % 20 == 0) { textureNum++; textureNum %= POWER_0_TEXTURES; } switch(textureNum) { case 0: Minecraft.getMinecraft().renderEngine.bindTexture(texture); break; case 1: Minecraft.getMinecraft().renderEngine.bindTexture(texture3); break; } } else { Minecraft.getMinecraft().renderEngine.bindTexture(texture2); }1
Check this troubleshooting guide.
If you are still stuck, post all the related .JSON files and their location in your assets folder.
1
Have you looked at how leather armor items change color?
Also see this troubleshooting guide and this tutorial for updating textures.
1
What difficulties are you having?
If it's the long complicated math in generateParticles that throws you off, read here:
Jabelar gives this as an example:
public void generateMysteriousParticles(Entity theEntity) { double motionX = theEntity.worldObj.rand.nextGaussian() * 0.02D; double motionY = theEntity.worldObj.rand.nextGaussian() * 0.02D; double motionZ = theEntity.worldObj.rand.nextGaussian() * 0.02D; EntityFX particleMysterious = new EntityParticleFXMysterious( theEntity.worldObj, theEntity.posX + theEntity.worldObj.rand.nextFloat() * theEntity.width * 2.0F - theEntity.width, theEntity.posY + 0.5D + theEntity.worldObj.rand.nextFloat() * theEntity.height, theEntity.posZ + theEntity.worldObj.rand.nextFloat() * theEntity.width * 2.0F - theEntity.width, motionX, motionY, motionZ); Minecraft.getMinecraft().effectRenderer.addEffect(particleMysterious); }Let's break it up:
The first three lines give the particle a random motion. This is essential because otherwise the particle will stay exactly where you spawn it and will not be noticeable.
Jabelar calls the same thing for each motion variable:
Pretty simple, and there are many alternatives (rand.nextFloat, rand.nextDouble, etc.) The advantage of nextGaussian is that it tends to pick numbers closer to zero than further -- numbers "group" and the result can be shifted or transformed as needed. In this case the motion will be very small because the result is multiplied by 0.02
The next part combines the constructor and position randomness. It is also crucial to not spawn all your particles at the entity's exact position, so let's look at one position statement:
This is the first parameter in the constructor and is identical to the third except that it uses posX instead of posZ. Remember the order of operations: The second, third, and fourth parts of this line will be calculated. For example, replace it with a variable called spreadX and you get:
That makes it easier to see that all it does is take the entity position, add a random value, and subtract the entity width.
The same thing is done for the y position but using theEntity.height instead.
The next three args after the world and position are your motion values that you set in the first three lines. Not too hard, really.
If it's instantiating your particle, read here:
Your constructor in EntityParticleYellow has autogenerated names like this:
public EntityParticleYellow(World world, double p_i46349_2_, double p_i46349_4_, double p_i46349_6_, float p_i46349_8_, float p_i46349_9_, float p_i46349_10_) { super(world, p_i46349_2_, p_i46349_4_, p_i46349_6_, p_i46349_8_, p_i46349_9_, p_i46349_10_); // other stuff.... }The first argument is the world. The second, third, and fourth args are posX, posY, and posZ respectively. The last three args are motionX, motionY, and motionZ in that order.
Inside the "other stuff," check out what the super class does in its constructor. For example,
This sets the color to full red, full blue, and no green, which give us yellow. I'm sure you already know this, though.
For actually making an instance of your EntityFX, the constructor expects something like this:
That's all I've got unless you specify the exact problem. Hopefully this helps though.