TheGreyGhost

whoa dude, danger zone there It will work fine until you try and run your mod on a dedicated server. Then it will fall in a heap. Client-side-only stuff like renderers should be in client proxy. -TGG

Hi I think, if you fix your proxy, it will fix your renderer registration problem. Currently the clientproxy method never gets called. -TGG

Hi If you want other clients to hear the sound effect you need to send it to the server. If you just want the local client to hear the sound, you can use Minecraft.getMinecraft().getSoundHandler().playSound(sound); where sound is an ISound, typically PositionedSoundRecord There are some good vanilla examples such as MovingSoundMinecartRiding -TGG

Hi Do these lines print something to console or not? System.out.println("Setting Render Types"); System.out.println("Rendering1"); I notice you aren't using the ClientProxy and CommonProxy properly. See here http://greyminecraftcoder.blogspot.com.au/2013/11/how-forge-starts-up-your-code.html -TGG

Hi For each of the four views(Inventory, first person, third person, entity): - does it render correctly in 3D? - if not, what does it look like? 2D, or invisible? This link might help, see the Item Rendering sections http://greyminecraftcoder.blogspot.com.au/p/list-of-topics.html and especially http://greyminecraftcoder.blogspot.com.au/2013/09/custom-item-rendering-using.html I notice that renderItem doesn't handle INVENTORY? -TGG

your upper and lower case must match in jars. eg NickelCrystal.png is not the same as nickelCrystal.png -TGG

No worries, glad to help. Yeah that wiki page is confusing. I changed it. -TGG

Hi An example from one of my mods resourceLocation = new ResourceLocation("speedytoolsmod:complex.boundarygrab"); sound file resources/assets/speedytoolsmod/sounds/complex/boundarygrabquiet.ogg in the json: { "complex.boundarygrab": {"category": "player", "sounds": ["complex/boundarygrabquiet"]} } Your json looks a bit different to mine, perhaps try the simpler format. The other bits look fine to me. -TGG PS the json file should be resources/assets/speedytoolsmod/sounds.json not resources/assets/speedytoolsmod/sounds/sounds.json perhaps that's the reason...

even better!

Hi The minecraft code changes from each version to the next. So the errors you're getting are because those fields / methods are either replaced by something else or are made private. You'll need to figure out what they have changed to. If they are now private, you will need either Access Transformer or Reflection to access them. In some cases, there may not be a replacement and you will need to significantly re-code. In this case I think the mod is pretty simple so there shouldn't be much to change. You'll probably need to understand Java pretty well though. -TGG

I think the apparent mismatch in buffer size is ok, the extra one byte in the sending packet is the packet discriminator byte. And all of your sent data makes it to the recipient. The cause is a bug in vanilla minecraft. It assumes the compressed data length will fit into a short (32767). If it doesn't, it overflows so the decompressor gets a wrong length. PacketBuffer:: /** * Writes a compressed NBTTagCompound to this buffer */ public void writeNBTTagCompoundToBuffer(NBTTagCompound p_150786_1_) throws IOException { if (p_150786_1_ == null) { this.writeShort(-1); } else { byte[] abyte = CompressedStreamTools.compress(p_150786_1_); this.writeShort((short)abyte.length); /// aiiiee noob coding mistake this.writeBytes(abyte); } } The good news is, that large packet made it across no problems. I reckon all you need to do is copy out the vanilla code for compressing the data and change the short to an int. -TGG

Hi How big is your nbt? perhaps it is too big. Try putting System.out.println("Buffer contents: " + buf.readableBytes()); in your fromBytes (before readTag) and your toBytes (after writeTag) that might give a clue -TGG

Forgot to mention - what you're doing sounds very similar to how vanilla takes an item's icon and gives it thickness when rendering in the hand. It might help to look at that (i.e. each of your cubes is one texel of the item icon). http://greyminecraftcoder.blogspot.com.au/2013/08/rendering-first-person-view-items.html ItemRenderer.renderItemIn2D() -TGG

Hi If you don't need your model to update every frame, you could compile your model to a render list. That is quite a bit faster. 256*6 faces takes very little time at all to render. For example that's what I used in this mod to show the blocks being copied. http://www.planetminecraft.com/mod/build-faster--four-tools-to-make-your-creative-life-easier/ Alternatively, you could create a renderlist for a cube, then render the renderlist at each cube location (using glTranslate) using your for loop. That's probably much faster than the model renderer. -TGG

OK. That's a good start. I'd suggest you could add a breakpoint to getCollisionBoundingBoxFromPool(), or something fancy which returns different AABB or null depending on what the caller is (http://stackoverflow.com/questions/11306811/how-to-get-the-caller-class-in-java). It might help you find what else in the vanilla code is using getCollisionBoundBoxFromPool to detect collisions. -TGG

Ah, bummer. Well I'm stumped then. addCollisionBoxesToList should work fine. Does it still glitch if your addCollisionBoxesToList always returns none? Might be worth trying getCollisionBoundingBoxFromPool() to return null always and see if that fixes the problem. If so, you could add a breakpoint to it, or something fancy which returns different AABB depending on what the caller is (http://stackoverflow.com/questions/11306811/how-to-get-the-caller-class-in-java) to help you find what else is using that. -TGG

Try Block::getCollisionBoundingBoxFromPool, eg from BlockBush /** * Returns a bounding box from the pool of bounding boxes (this means this box can change after the pool has been * cleared to be reused) */ public AxisAlignedBB getCollisionBoundingBoxFromPool(World p_149668_1_, int p_149668_2_, int p_149668_3_, int p_149668_4_) { return null; } -TGG

Hi the vanilla minecraft files are obfuscated (all the class and field names are meaningless). In your development environment, they are all deobfuscated to something meaningful. That means that you need to reobfuscate your code when putting into your mods folder, i.e. you can't just copy the files. Use the gradle build command instead, the properly packaged jar with reobfuscated names will be in build/libs -TGG

Hi Almost guaranteed it will make absolutely no perceptible difference to the player whatsoever. I'd say you should choose whichever is easier to understand and maintain for the coder. If you're really concerned, try it both ways and see? -TGG

Hi Sounds like your renderer isn't registered. Do you call proxy.registerRenderThings() anywhere? You can test by putting System.out.println("reached..."); at appropriate points in your code. In particular in the rendering code soRender - if it's called, you have a rendering problem. If it's not called, you probably have an entity renderer registration problem. -TGG

Hi This link might help to understand Quad rendering and the Tessellator http://greyminecraftcoder.blogspot.com.au/2013/08/the-tessellator.html -TGG

Hi Pls show RenderAlchemyCauldron, best to post it using this site, that way it shows line numbers http://pastebin.com/ -TGG

Hi Where did you copy the ChunkProviderPuplet from? it looks similar to the vanilla but has some significant differences. I'd suggest updating it. Apart from that I have no idea, I've never worked with terrain generation. -TGG

Hi You can use the command debug start to collect a lot of profiling information, it creates a profiler results file in the folder "debug". This will slow down your system a lot but can be helpful. You can add profiling code to your methods - either using System.nanoTime(), or have a look at the way the vanilla uses the profiler, eg this.mcProfiler.startSection("scheduledExecutables"); Alternatively you can use a Java profiler, although this will make your code ridiculously slow unless you restrict profiling to a small part of your code. -TGG

Hi I'd suggest adding a few more diagnostics, eg for (int i = 0; i < 6; i++) { int x = this.xCoord + dirs[i].offsetX; int y = this.yCoord + dirs[i].offsetY; int z = this.zCoord + dirs[i].offsetZ; System.out.println("Test " + i + " at [" + x + ", " + y + ", " + z + "]"); if (!getWorldObj().blockExists(x, y, z)) continue; Block t = getWorldObj().getBlock(x, y, z); System.out.println("Block found:" + block); TileEntity te = getWorldObj().getTileEntity(x, y, z); System.out.println("Tile Entity found:" + te); if (te instanceof ITurtleAccess) { turtles.add((ITurtleAccess) te); Logger.info(""); } } -TGG