herbix

{ "poof":{ "category": "master", "sounds": [ "poof" ] } }

If you need items drop from an entity: Entity e = ...; e.entityDropItem(new ItemStack(...));

player.addPotionEffect(new PotionEffect(id, 9600, 0)); Id is the effect id, I looked it up on minecraft wiki. 9600 is duration, in ticks. 9600 = 20 * 8 * 60 = 8 min 0 is amplitude, means level1. If you want level n, use (n-1).

You could make a large model and change its scale when rendering. Just like when rendering a baby, the body part would be smaller.

Maybe it's /summon modid.NPC? You used registerModEntity, the entity id in your mod would have a common prefix "modid.".

"Unable to summon object" means the summoning of your entity throwed an exception. I think there would be messages in your console.

net.minecraft.client.renderer.RenderBlocks decides how a block is rendered. See BlockGlass.getRenderType and look up it in RenderBlocks. There are tons of codes in RenderBlocks about rendering a block. I mean, there is no need to read it. Vanilla do it in RenderBlocks. And we modders could do this using ISimpleBlockRenderingHandler (in 1.7.x).

You need Minecraft.getMinecraft(). If you have read the constructor of class Minecraft, you would find it.

The connection is calculated during rendering. Say, when I'm rendering a glass pane, I get its position. So I know whether there are other glass panes near by and change its shape. There's no need to use TileEntity. By the way, in 1.8, the connection is stored in IBlockState.

b.addGeneralQuad(myquad); b.addFaceQuad(EnumFacing.UP, myquad); These two statements are just examples of adding face to the result model. myquad is a BakedQuad. You could check the around blocks in getExtendedState, where you would get World and BlockPos objects.

Good idea. I would do it later.

I feel sad about this.

In forge-1.8-11.14.1.1334, SpawnerAnimals.findChunksForSpawning (Line:152), there is a check: ... if(... canCreatureTypeSpawnAtLocation(EntitySpawnPlacementRegistry.func_180109_a(spawnlistentry.entityClass), p_77192_1_, blockpos1) ...) ... It reads the registry to get an entity's type (ground, water, or air). So one entity belongs to one type. But in 1.7.x, there is no EntitySpawnPlacementRegistry.func_180109_a(spawnlistentry.entityClass), they use enumcreaturetype. BiomeGenBase didn't change, but something changed.

In 1.7.10, it's possible to render a non-tile-entity block with ISimpleBlockRenderingHandler. In 1.8, json models is good in most cases. In other cases I use ISmartBlockModel and ExtendedBlockState together to customize rendering.

In 1.7.x, I did this by adding spawn data to spawnableCreatureList and spawnableWaterCreatureList. It doesn't work in 1.8 because of changed spawning mechanism. So is there a simple way to do this? Or should I register two types of a same entity (I hate this)?

I'm not sure I see this. Unless it is obfuscated, I don't see an equals nor hashCode methods In EntityPlayer. Nor in Item. Or Block, for that matter. Which makes me think that player and item are the same in that regard. What am I missing? If equals or hashCode is not defined, the default one would be used. Every object in JVM has an unique id. The equality of two objects is decided by this id. That means, the default equals method is like this: public boolean equals(Object o) { return this == o; } An Item object contains the definition of the item. It's created when server starts and won't be destroyed until server stops. A player object is different. It contains runtime informations of a player, such as position, speed, etc. When the player leaves. These informations are saved into disk and the object is destroyed. Then, even the same player joins, you won't get the same object, because it's destroyed. A new player object would be created. So if you hold the old player object as a key, that makes no sense. You can only operate on the new object now. That is, an Item object has a long lifecycle, from server start to server stop, while a Player object only exists when the player is in game. If the informations stored in HashMap is invalidated after the player logging off, it's ok. You may use the player object as a key. Of course, you should remember to remove the key-value pair from the HashMap when the player leave.

No. I'm not German. I'm Chinese. English is even harder for me, I think.

Use ItemStack instead of Item when registering recipes. Entity type value is contained in damage value of the ItemStack object. Minecraft wiki would tell you what id the entity is: http://minecraft.gamepedia.com/Data_value#Entity_IDs

Not much changed. In IChunkProvider, ChunkPrimer replaced Block[] and int[], BlockPos replaced int x, y, z. The other parts of creating a world remain unchanged.

It's not a good idea opening gui on both side. It may cause synchronization problems. A better choice is using openGui and making forge do the same thing as vanilla.

The reason of not using a player object as a key is that the object of a same player would change during a game, and it's different at client and server side. A Item object won't, so it's possible to use it as a key.

My forge version is 1.8-11.14.1.1334. Now RenderItem.renderItemModelForEntity is like this: public void renderItemModelForEntity(ItemStack stack, EntityLivingBase entityToRenderFor, ItemCameraTransforms.TransformType cameraTransformType) { IBakedModel ibakedmodel = this.itemModelMesher.getItemModel(stack); if (entityToRenderFor instanceof EntityPlayer) { ... if (item == Items.fishing_rod && entityplayer.fishEntity != null) { ... } else { modelresourcelocation = item.getModel(stack, entityplayer, entityplayer.getItemInUseCount()); } if (modelresourcelocation != null) { ibakedmodel = this.itemModelMesher.getModelManager().getModel(modelresourcelocation); } } ... } The ISmartItemModel.handleItemState is called inside the method getItemModel, from the first line of renderItemModelForEntity. But this result model returned by getItemModel would be replaced by Item.getModel. That made me sad when I returned a ResourceLocation pointed to an ISmartItemModel in Item.getModel, trying to create an customized item model considering useRemaining and player state. So I suppose it would be better if forge calls ISmartItemModel.handleItemState after Item.getModel. That's my little suggestion.

Just define your own EnumType and use it like this: ... public static final PropertyEnum VARIANT = PropertyEnum.create("variant", MyWoodType.class); ... @Override protected BlockState createBlockState() { return new BlockState(this, new IProperty[] { VARIANT, AXIS }); } Of course, It's a new class. You should override getMetaFromState and getStateFromMeta too.

EntityLivingBase.addRandomArmor should be dropRareDrop. See EntityZombie: protected void addRandomArmor() { switch (this.rand.nextInt(3)) { case 0: this.dropItem(Items.iron_ingot, 1); break; case 1: this.dropItem(Items.carrot, 1); break; case 2: this.dropItem(Items.potato, 1); } } Also, EntityLiving.func_180481_a is the real addRandomArmor. Forge version: 1.8-11.14.1.1334

I usually register event handler like this: ... public class MyItem extends Item { ... public MyItem() { ... MinecraftForge.EVENT_BUS.register(this); ... } @SubscribeEvent public void onXX(XX event) { ... } } But I have no idea about whether it's not a efficient way(both programming and executing). Of course, this event has close relations with the item.