jabelar

Umm, we linked you to several tutorials. You obviously didn't even Google for tutorials since you get dozens of hits if you did. Plus in this case it really is pretty much as simple as we said. You make a creative tab just like you'd make an instance of any class in Java. A single line: public static CreativeTabs tabCustom = new CreativeTabs("tabName") ;

GoToLink, I think he is also asking how to create the custom creative tab itself. To do that there are lots of tutorials out there (see http://lmgtfy.com/?q=minecraft+forge+custom+creative+tab). Off the top of my head you have to instantiate a new CreativeTab which has the icon you want, do the stuff GoToLink mentioned to associate your items to the tab, and update the .lang file to give your tab a localized name.

Delpi, the whole point of moving away from ID numbering is that you can now look up registered items, entities, etc. by name String. Like GoToLink says there is a registry method getObjectByName(). Basically the ItemRegistry, BlockRegistry, are FMLControlledNamespacedRegistry class which has the set and get object methods.

I know you're working with an obj file, and it isn't an entity, as my experience is with Java models for entities, but for those the rendering starts with the RenderLiving class which associates the model with the textures. So I usually make a custom class that extends RenderLiving and registers the custom model into that. Not sure if that applies to your case at all, but maybe it will give a clue.

They've added a BreakEvent that extends BlockEvent. I think canceling that will do the trick because the comment for the class says: /** * Event that is fired when an Block is about to be broken by a player * Canceling this event will prevent the Block from being broken. */ @Cancelable

That wiki is wrong. I was just working on attributes for my custom entities this morning. EntityLivingBase has the following: protected void applyEntityAttributes() { this.getAttributeMap().registerAttribute(SharedMonsterAttributes.maxHealth); this.getAttributeMap().registerAttribute(SharedMonsterAttributes.knockbackResistance); this.getAttributeMap().registerAttribute(SharedMonsterAttributes.movementSpeed); if (!this.isAIEnabled()) { this.getEntityAttribute(SharedMonsterAttributes.movementSpeed).setBaseValue(0.10000000149011612D); } } And then EntityLiving (which extends EntityLivingBase) has following: protected void applyEntityAttributes() { super.applyEntityAttributes(); this.getAttributeMap().registerAttribute(SharedMonsterAttributes.followRange).setBaseValue(16.0D); } In my custom entities, like GoToLink says, I had to register the additional attack damage attribute and then set it. Note that the full list of built-in attributes available to register are (from ShareMonsterAttributes class): public static final IAttribute [b]maxHealth [/b] = (new RangedAttribute("generic.maxHealth", 20.0D, 0.0D, Double.MAX_VALUE)).setDescription("Max Health").setShouldWatch(true); public static final IAttribute [b]followRange [/b] = (new RangedAttribute("generic.followRange", 32.0D, 0.0D, 2048.0D)).setDescription("Follow Range"); public static final IAttribute [b]knockbackResistance [/b] = (new RangedAttribute("generic.knockbackResistance", 0.0D, 0.0D, 1.0D)).setDescription("Knockback Resistance"); public static final IAttribute [b]movementSpeed [/b] = (new RangedAttribute("generic.movementSpeed", 0.699999988079071D, 0.0D, Double.MAX_VALUE)).setDescription("Movement Speed").setShouldWatch(true); public static final IAttribute [b]attackDamage [/b] = new RangedAttribute("generic.attackDamage", 2.0D, 0.0D, Double.MAX_VALUE);

It will take some coding, but I believe you would have make your own copy of the pathfinding related classes and modify such that the blocks you don't want to walk over are considered similar to lava. Then you will have to override the methods and/or events your entity uses to process pathfinding. Looking at it quickly, I think EntityLiving has a method called getNavigator() which returns an instance of PathNavigate class. So assuming that your custom entity extends EntityLiving (or some subclass of EntityLiving) I think if you copied or extended PathNavigate, created an instance of it in your entity, and override the getNavigator() method to point to your instance then you could do it. In your custom PathNavigate class, it calls a getPathToXYZ() which calls worldObj.getEntityPathToXYX() method which in turn creates a PathEntity by calling a PathFinder.creatEntityPathTo() method which calls an addToPath() method. The addToPath() is where I believe you would have to figure out how to avoid your block, although I looked at it quickly. Alternative: There is possibly one other "brute force" method that you might be able to try. You could try temporarily changing the bounding box of your blocks before calling the getPathToXYX() and then restore the bounding boxes. This seems like it might work and wouldn't take too much coding. Anyway, hopefully I gave you some ideas on where you might look.

No, I'm suggesting that you loop through all players (that the server knows is on that world), check first that they are within the maximum distance (based on the amount of light) and then check if they can be seen. If BOTH conditions are true, set that player as the attack target. Ideally, you want to make it more fair because the above algorithm will choose the player that joined earlier if more than one are in range and in sight, so a better implementation would be to add all the possible targets to a list or array and then randomly choose from that list. Anyway, I'm saying find a player that meets both conditions (within range of the light, and also actually in direct line of sight).

What exactly do you mean? Did you put a console message after this condition is tested?: if (d2 >= 0.009999999776482582D) Also, I'm not certain it is correct to multiply the motion by a negative number. When something is pushed, doesn't it normally go in the same direction as the thing that pushed it?

Well, it will work, but of course if you can figure it out mathematically then certainly do that.

Do you really need to use a custom packet if you have a TileEntity associated with the block? I thought TileEntities are automatically synced? So I think you should put your custom block properties into fields in the TileEntity instead, when onBlockActivated() happens update them in the TileEntity, and forget about custom packets.

This is an example of where I would suggest using "brute force" rather than trying to be mathematically correct. Doing reverse trajectory calculations can be tricky in normal physics and Minecraft physics is even weirder. What I would do is to simply experiment and record the velocity (and angle if you're changing that too) necessary to hit each distance. Then once you have all the velocities known for different distances, then in your code just create an array with those values and look it up. Understand what I mean? I guarantee that that will be much faster to code than to try to figure out all the math for a closed form calculation. No trigonometry required!

I suggest you'll have to debug this the old-fashioned way -- add your own console messages (i.e. with System.out.println() type statements) for each step in the process of creating and registering the blocks and see where it goes wrong. It will probably be pretty quickly apparent if you trace through the expected steps.

What is your code for you LogFirePacket and for your BlockLogFire classes?

Hmmm, it looks like you're doing most of the things that are required: setting can be pushed, can be collided, overriding the collision, etc. I suggest that you add more debug console statements so you can trace the execution more closely. For example, put a System.out.println() statement in the applyEntityCollision() method to confirm that that method is actually getting called. Another thing is that while playing the game you can hit F3+B to show the bounding box for the entity. This will help confirm where the bounding/collision box is because sometimes people create a model that isn't well aligned with the bounding box so they aren't actually colliding when they think they are. Anyway, by putting some console messages in each of the critical parts of the code you will be able to track through your logic and should be able to find out what is going wrong.

The AI is run on the server side per entity instance, so you would have ability to check for any player or any other condition. I wasn't suggesting any particular method, just explaining that the shouldExecute() method is how you control the execution, not addding/removing the task from the list itself. So in the shouldExecute() he could cycle through all the players the server knows are in that world, see if any of them are visible (based on lighting as well in his case) and if so then set the attack target accordingly.

I'm not entirely sure, but adding a mod to a world that previously didn't have the mod can cause all sorts of problems. For example, the registries will be different, therefore ids might be different and so you can get mismatches with the save data. I think it really depends on the mod, but potential for weirdness is there. Are you getting any errors in the server console? Like is it complaining about missing or mismatched stuff?

What's the problem? Are you getting an error, or is it not appearing in your game, or is the pushing not working properly?

Okay, you're not using AI tasks properly. You actually should NOT be adding and removing AI tasks. Rather, each AI task has a method shouldExecute() which you use to detect the condition you want go run. You should be able to detect the light conditions, proximity of player, or whatever you want for your case there. So the AI task should always be on the list, but shouldExecute() should only return true in condition you care about. Also, like GoToLink mentions, you're continuing to add tasks without ever removing them. I believe that the number ("2" or whatever) in the addTask() method is NOT actually an index, but rather a priority indicator, and is not unique. In other words, adding another task with same priority will not overwrite the previous task.

Usually in programming there is more than one way to approach these things. In general, if I had a custom item that was interacting with vanilla items it would of course make more sense to add the code in the custom item. Conversely, if I had a custom block that was interacting with vanilla items then it would make more sense to add the code in the custom block. Even more generally, as SanAndreasP points out, when changing behavior related to vanilla stuff it is best to look for events (hooks provided by FML) which are exactly intended to help you with such interceptions of vanilla processing. Even with events though, there are usual several alternatives to choose from -- handle in the player, the block, the world tick, or whatever.

The problem is pathfinding. Yes you can do things like you suggest which will block the entity by pushing them away, but the entity will not seem smart -- it won't be able to find its way around the block if there is a way. You need the pathfinding algorithm to know that that block isn't passable.

Well, the point is actually to do the scaling so close to 1.0 that it the scaling (and any offset) is pretty much unnoticeable. But yeah technically you should probably adjust the offset by half the difference between 1.0 and your scale factor.

Yeah, for other people who may end up on this thread it would be good to post your final code. But for a block you also have use the setBlockName() and also for it to fully display in CreativeTab properly you need your en_US.lang file to map the tile.liquidEnergy.name to "Liquid Energy" or similar.

What do you mean it is registering a null? You mean you later try to use the block and it is null? Could it be because in your code you register the name as "YourFluid" and then later try to call it by using liquid energy? Basically I'm saying that you registered the block as "YourFluid" which probably isn't what you want to call it, maybe that is causing your trouble.

In my model class, within the render() method. For example, for my elephant I did the following: head.render(par7); body.render(par7); // scale legs slightly to reduce render flicker on overlapping areas GL11.glPushMatrix(); GL11.glScalef(0.99F, 0.00F, 0.99F); legRearRight.render(par7); legRearLeft.render(par7); legFrontRight.render(par7); legFrontLeft.render(par7); GL11.glPopMatrix(); I only scaled in x and z direction because those were the dimensions that caused the overlap. You could probably make it even tighter with 0.999F or something. Definitely fixed it for me, assuming the flicker you're talking about is the same type.