MineMaarten

You shouldn't navigate into the codechicken folder from the root of the download. You should go into src, and then the codechicken folder. That's the way ChickenBones appears to package every dev version he puts out. Now I've looked for you and this indeed is the case. The complete path to EnderStorage's block class: /src/codechicken/enderstorage/common/BlockEnderStorage.java . To be specific look at that class its onBlockActivated() method.

Yeah Forge has a 'different' way of doing it: GameRegistry.registerTileEntity(Class<? extends TileEntity>, String id); Which calls in the end the same method you mentioned PisuCat. public static void registerTileEntity(Class<? extends TileEntity> tileEntityClass, String id) { TileEntity.addMapping(tileEntityClass, id); }

I already looked at BuildCraft's implementation. It was already quite complicated when they had all the different pipe additions (plugs, facads, gates, ...). Now that they made it easier to put on facads it became even more complicated. I suggest that you take a look at the mod you refered to in the beginning: Ender Storage. It's also open-source after all. Link to the dev version download: http://adf.ly/WAp6z . I must admit I haven't looked at this source yet.

Should work, how are you calling that method exactly?

Yup there certainly is a way to do it. Have a look at how BuildCraft allows you to place facads and pipe plugs. The idea on which this is based off has the name raytracing. Basically you're tracing the line the player's reticle is following until you hit the block. https://github.com/BuildCraft/BuildCraft/blob/master/common/buildcraft/transport/BlockGenericPipe.java

These values are only saved on the server. The console chat is sent from the client. what if you added !player.worldObj.isRemote to your if() statement? Would it stop then?

It can't be the cause of the code you've put here if you say the middle part renders. The cables will render if you remove the check if they are connected or not right? Then it should be the cause of the check. I would suggest placing a breakpoint just before a check and tracing down why it returns false.

Or if you want to do things more organized, you could go for a workspace in which every mod and Minecraft is divided in a project which are linked together, 'the Pahimar set-up',

If you want to render anything in the 3D world you can use RenderWorldLastEvent like TheGreyGhost explained. If you want to draw anything on your 2D HUD however, you could implement ITickHandler and do your rendering every render tick. @SideOnly(Side.CLIENT) public class TickHandler implements ITickHandler{ @Override public void tickStart(EnumSet<TickType> type, Object... tickData){ } @Override public void tickEnd(EnumSet<TickType> type, Object... tickData){ if(type.contains(TickType.RENDER)) { //Render code here, use the links TheGreyGhost gave you } } @Override public EnumSet<TickType> ticks(){ return EnumSet.of(TickType.RENDER); } @Override public String getLabel(){ return "Name of your TickHandler"; } And registering it in your ClientProxy: TickRegistry.registerTickHandler(new TickHandler(), Side.CLIENT);

I really recommend not making it hardcoded and creating a recipe list instead (unless the random items are the same for every input item off course).

As I read it I'm doubting if it would work, but if it does, it looks fine. This code also takes spawnable Biomes in account. There are some dirtynesses going on though: int i1 = par3 + par2Random.nextInt(1) - par2Random.nextInt(1); Random#nextInt(1) will always return 0, not very random. Maybe it's meant as an extra option, that you can change this 1. public WorldGenCustomFlower(int par1) { this.GlowFlowerBlockId = par1; } (...) if (TutorialMod.GlowFlower.canBlockStay(par1World, i1, j1 + i2, k1)) { par1World.setBlock(i1, j1 + i2, k1, TutorialMod.GlowFlower.blockID, 0, 1); } What's the point in giving a blockID in the constructor if you're not going to use it...

Then it's a matter of just not processing input when the output slot isn't null, and the disallowing of the player putting items in the output slot (which you can do in the Container).

What I've done for my plants to generate is firstly a thought process: I want them to spawn in groups, and scattered around the surface. More translated to code I think of every chunk having a 1 in so many chance to spawn a group. When it has to spawn a group, it'll generate a number between 7 - 14 which is the number of plants that (most of the times) will be generated. When you have that number, you can illiterate that many times in a for loop and generate a random x and z every time you do so. The y is the height of the topmost block +1, or World#getHeightValue(x, z). This comes down to this code: if(rand.nextInt(40) == 0) { int plantsInGroup = 7 + rand.nextInt(; //beteen 7 and 14 plants per group. for(int i = 0; i < plantsInGroup; i++) { int x = chunkX * 16 + rand.nextInt(20);//in an area of 20x20 int z = chunkZ * 16 + rand.nextInt(20); int y = world.getHeightValue(x, z); if(y > 0 && (BlockYourFlower)Block.blocksList[idOfYourFlower].canPlantGrowOnThisBlockID(world.getBlockId(x, y - 1, z))) { world.setBlock(x, y, z, idOfYourFlower, 0, 2); } } } I gave the explanation at the beginning to show you that with a good rundown of the problem you don't always need a tutorial for it.

Well, then you could choose an Entity you want to perform the changes to, lets say the EntityItem. So I go to net.minecraft.entity.item.EntityItem.java. On line 111 of the onUpdate() method you can see: this.motionY -= 0.03999999910593033D; Which is the gravity being applied to the entity, it appears to be 0.4 m/tick². If you look further in the method you see (from line 132) : float f = 0.98F; (...) this.motionX *= (double)f; this.motionY *= 0.9800000190734863D; this.motionZ *= (double)f; Which is the air drag being applied. Every tick the entity loses 2% of its velocity. The code in the (...) handles the difference in slipperyness of blocks (and only applies to the X and Z motion). So if you're not planning on releasing any mod, you can just change these parameters.

Editing the integer is not a problem at all. Even then the two points in time that you'll have to save/write to the file is when the server shuts down/starts up.

I think they did some trickery to approximate the rotated BB by combining multiple AABB's. As Minecraft uses Axis Aligned Bounding Boxes, the name says it all, they will stick to the axis.

You could get the gravitational acceleration of every entity in the world by getting every entity in the world World#loadedEntityList. Then you get the entity type and create a fake entity of the same type you can then test on. Call Entity#onUpdate() on it and look at the motionY. That motion is it's gravitational acceleration (as no other forces apply except air drag, which is handled before the acceleration so that will have no effect). You now have the acceleration of that entity. If you want to make the entity have half the acceleration you can do Entity#motionY = -acceleration * 0.5D every tick. I haven't tested this and this is quite resource intensive (as it will create a fake Entity object for every Entity every tick). This is a base concept though, and there are ways to make it more efficient (storing the accelerations of all the types of entities instead of recalculating them again and again).

Although BuildCraft's power framework is complicated (many parameters you can fiddle with) in comparison to IC2's, BuildCraft's is more popular.

Not if he adds custom inventory, like he suggests he's doing. Could it be that you're saving the data twice somewhere? You're checking for slots, but it would allow to drop two ItemStacks with the same slot number.

Plus the fact that you're using the World#setBlock(pars) method without a flag parameter, which gives a call to the World#setBlock(pars) with flag: public boolean setBlock(int par1, int par2, int par3, int par4) { return this.setBlock(par1, par2, par3, par4, 0, 3); } When set to 3 this means that you'll cause a block update and a update to every nearby client when you generate every block. So calling the World#setBlock without these flags should also increase performance.

It's about how you read the sentence. You (and me too) thought GameRegistry was yelling about that you register the block before it was fully initialized. However, after research, it seems to be about you registering a too early init stage. Block registry should be done in the PreInit, but you've done it before that. Have you initialized your blocks statically? So "public static Block test = new BlockBase(parms);" ? So calling GameRegistry from within your constructor is fine, calling it before the PreInit phase isn't.

This really makes me think of IC2's way to manage the powernet. When you want to add an IC2 machine to the powernet, you'll have to post an event when you load the TileEntity and a different event when the TileEntity gets unloaded or removed. Although IC2 is closed source, you could learn from their API . A bit of info you could use in your implementation, from IC2 API's usage.txt: And about the unloading: The difference is they stop using the TileEntity when it's unloaded. So they are using events, but that's with an API in mind, you could just add to a list and store it in WorldInfo like TheGreyGhost mentioned (I also never have used this). Good luck!

Thanks Draco. And the way you're doing it is great . I just want to say, if you get any compile time errors, this is Java, and if you google it you'll most certainly find a solution. These solutions don't have to be Minecraft related in any way off course.

The id's start at 0, so you'll use 0-35 (equals 36 slots) for the entire player inventory. But that number is not the slot number, these will automatically assigned (in the order you call addSlotToContainer()). You just need to pass it the index of the inventory itself, so probably 0-5.

And this ID you can get like how you did earlier: "ModItems.redTCrystal.itemID". The problem then was that redTCrystal was null. So find out why, because that's not normal. Probably you haven't initialized your item (redTCrystal = new Item....).