imadnsn

I'm pretty sure you can do DamageSource from player. I guess it wouldn't make sense to have a player for a machine but maybe a fake player would do?

It did work but it made the problem opposite, which I can deal with. The reason why it is hard to implement is because there is some logic behind it. A particle should render before transparent block if it is behind or inside the block, but it should render after the block if it is in front of it. This is pretty much a basic graphical problem when it comes to rendering a scene. And to make it worse, particles aren't blocks so the only way to solve this is by raytracing.

Put it in a file called "en_US" with the extension being ".lang" (not ".yml") directly in "*directory*/src/main/resources/assets/*modid*/lang/" folder

After I looked at Vazkii's Botania code, I saw she's "queuing" the render for the particle and she renders it in a RenderWorldLastEvent. Could this be a workaround?

For blocks, you do: if (is != null && is.getItem() ==Item.getItemFromBlock(theBlock))

I made a particle effect that is in the shape of a block (renders 6 sides), it is rendering all well except when you try to see it with a portal, water or any other semi-transparent block (such as stained glass or ice) behind. What happens is that the particle renders before the block does, which makes the block renders as if the particle is behind it although it is not. The way I made the particle is like vanilla ones, except it is static (i.e. doesn't move) and with renderParticle overridden (the super is not called in it). I also made a utility class that spawns the particle just like how RenderGlobal does (the same mechanics). Should I disable some OpenGL options before drawing or do something like that? I should note that I don't use "startDrawingQuads" or anything like that in the tesselatior because I think it is already preconfigured looking at vanilla code. This is the render method: @Override @SideOnly(Side.CLIENT) // the partial tick and all rotations aren't used in the rendering because the particle is not facing the player public void renderParticle(Tessellator t, float partialTick, float rotationX, float rotationXZ, float rotationZ, float rotationYZ, float rotationXY) { double minu = 0; double maxu = 0.25; double minv = 0; double maxv = 1; // interpPos is related to the player's position, it renders the particle relatively to the player. double x = this.posX - interpPosX; double y = this.posY - interpPosY; double z = this.posZ - interpPosZ; // ... some logic that choose minu and maxu ... Minecraft.getMinecraft().renderEngine.bindTexture(new ResourceLocation(Magematica.MODID, "textures/particles/block_fade.png")); t.setColorRGBA_F(this.particleRed, this.particleGreen, this.particleBlue, this.particleAlpha); // ... a lot of addVertexWithUVs that work fine ... } This is the spawning in the utility client-only class ParticleSpawner: public static void spawnParticle(String particleType, double x, double y, double z, double velX, double velY, double velZ) { EntityFX particle = getEntityFXToSpawn(particleType, x, y, z, velX, velY, velZ); if (particle != null) { mc.effectRenderer.addEffect(particle); } } private static EntityFX getEntityFXToSpawn(String particleType, double x, double y, double z, double velX, double velY, double velZ) { EntityFX ret = null; if (mc != null && mc.renderViewEntity != null && mc.effectRenderer != null) { int particleSetting = mc.gameSettings.particleSetting; boolean spawn = particleSetting != 2; // Don't spawn on Minimal particle setting // 1/4 chance of not spawning when particle setting is Decreased if (particleSetting == 1 && world.rand.nextInt(3) == 0) { spawn = false; } double xDist = mc.thePlayer.posX - x; double yDist = mc.thePlayer.posY - y; double zDist = mc.thePlayer.posZ - z; // only spawn when player is within 16 blocks of range (squared to not account for signs). spawn &= xDist * xDist + yDist * yDist + zDist * zDist <= 16 * 16; if (spawn) { switch (particleType) { case block_fade: ret = new EntityBlockFadeFX(world, x, y, z); PlayerMageProperties props = PlayerMageProperties.getFromPlayer(mc.thePlayer); // ... some logic to choose particle color (I assure it is not the problem) ... break; } } } return ret; }

Well I know that well, I know that I can use the compatibility mode if I don't want problems, but as I said, I prefer "compiling with JDK 1.7", I do appreciate your answer, but my question isn't answered yet.

If you mean by "fine" = "you can use it", you didn't quite answer my question.

It is not that easy if you never used packets, but the way you do it is you handle InputEvent.KeyInputEvent and in it you check for: Minecraft.getMinecraft.gameSettings.keyBindJump.isPressed() and in case it is true, you send a packet to the server, upon handling, you set the player's ridingEntity's motionY: player.ridingEntity.motionY += 1.0; Which will make the ridden entity jump one block. Note that this will jump for whatever entity the player is riding. If you want it to only work for spider, check for: player.ridingEntity instanceof EntitySpider

I'm not asking whether I can use Java 7 (JDK 1.7) when compiling my mod, I actually want to know about how much the forge modding community is using Java 7, and whether mods actually compile using Java 7, because I prefer to use it but I don't want to keep telling people to download JRE 7 in order to use my mod. Will this thing make me encounter this problem frequently?

I've got it sorted out by doing so: double degree = 180 / Math.PI; double dx = player.posX - (playermop.blockX + 0.5); double dy = (player.posY + player.eyeHeight) - (playermop.blockY + 0.5); double dz = player.posZ - (playermop.blockZ + 0.5); double yaw = -((Math.atan2(dx, dz) * degree) + 180); double pitch = (Math.atan2(dy, Math.sqrt(dx * dx + dz * dz)) * degree); I wanted it in degrees to compare it with player's rotationYaw and rotationPitch and it worked perfectly, it gives the exact yaw and pitch if the player is looking at the center of the block. I just want to know if it is theoretically correct to do it like so...

try initializing in preInit

What crash does it give you? Your code seems alright. I don't think you need to use proxies, they work fine to me without them. The way I currently use those packets is by sending messages from server to update client's information when it is changed on server. Since I know it will always be sync I use the info in my client while rendering Gui without worrying about whether it is sync or not. Although I'm sure you can send request-reply message for the info and render on reply handling

InputEvent.KeyInputEvent, using KeyBindings is good since it allows users to change thekeys For the scroll, use MouseEvent, I guess the event's dwheel will not be zero (either positive or negative) when the player scrolls.

Problems of missing methods have been raising lately... Could it be that ForgeGradle is downloading Forge incorrectly? Or something else concerning Forge setup.

I want to make a projectile, extended from EntityThrowable, although it wont be thrown but it will have the same mechanics. This projectile will only appear when the player is looking at a block. I want this projectile to reach the center of the block in a straight line, so I don't want to have the player's pitch and yaw as the projectile's but rather I want the pitch and yaw that will make the projectile reach the center of the block, but I can't seem to figure out how I would calculate the pitch and yaw of the projectile, as I don't know a lot about rotations. Can someone help?

public static SilverGenerationClass SilverWorldGen = new SilverGenerationClass(); That's basic java

If you mean you want to pick the block with metadata as an ItemBlock with damage, you should return the metadata in the damageDropped function, if that doesn't work, make custom class extending ItemBlock with damage to denote Block's metadata

Do you in any way in the mod modify the item's stack size after initialization? Search where the setMaxStackSize() method is referenced, you might find something.

If door's block material doesn't matter for you, try making its material wood while extending vanilla BlockDoor

It is: this.useNeighborBrightness = true;

item.manaCrystal.manaCrystal=Mana Crystal item.manaCrystal.manaShard=Mana Shard item.manaCrystal.manaFoci=Mana Focus it should be: item.manaCrystal.manaCrystal.name=Mana Crystal item.manaCrystal.manaShard.name=Mana Shard item.manaCrystal.manaFoci.name=Mana Focus For the packet thing, I barely could handle my problems in it, I would've answered if I've known

See BlockStairs class. If you did, tell us what is the problem specifically.

you should do return getUnlocalizedName() + "." + names[getDamage(item)]; not return getUnlocalizedName(item) + "." + names[getDamage(item)];

StackOverflow happens in recursion, i.e. when you call a method from itself. StackOverflow happens when you keep calling the same method again without stop, which is what happens in your getUnlocalizedName() method. Well, that's what hasSubtypes(true) and setMaxDamage(0) are for.