coolAlias

Thanks for the reply. The idea behind the block is that the player can right-click on pretty much any standard block and have the block assume that texture, but once placed the texture need never change. What I did for my metadata-based block is to have an array of texture names and use the metadata as the index, making it easy to return the correct icon from the Block methods. While I could theoretically do the same for 256+ blocks, that would be quite cumbersome. For now, I plan on following through with my final idea of using metadata blocks for my structure generation, since I only need 8 textures for those blocks, and leave the tile-entity based block for map-makers with a warning not to use it excessively. The main problem is simply the sheer number of blocks I am generating - if you consider that even a hollowed out 5x5x5 cube requires nearly 100 blocks (98, to be exact), and I am generating roughly 4-6 of those rooms per chunk on my default settings, that's roughly 32,000 added tile entities in just an 8x8 chunk area (500 per chunk x 64 chunks). Best to avoid that Anyway, thanks again. I will be switching back to metadata for the most part, though I am still open to other suggestions. Cheers, coolAlias

<cough> misspelling <cough> Seriously, what's the point of defining a constant when you don't use it? One of the main benefits of constants is to prevent just this sort of error from happening.

Well look at that, so you can! hahaha, though it has the hilarious side effect of keeping the same bounding box for collisions, so most of the player's body is in the ground with just his giant head sticking out - at least it doesn't crash when I click on stuff I could have sworn I tried setting the yOffset back to normal, but apparently I didn't, at least not every tick. Thanks for the tip! EDIT: Actually, that doesn't work for changing the viewpoint of the camera - it actually ends up moving to the player's posY (not even normal eye height!), even after changing player.eyeHeight. The player's bounding box is correct, since I do not fall through the ground and cannot walk under trees and such (I made the player about 4-5 blocks tall), and I can easily fix the rendering of the player to match the bounding box position, but the camera stays at the ground... Looks like it's back to square one @sequituri - iChun's Morph mod is indeed open source, and I've seen a video where the eye height moves higher or lower, so he certainly figured out how to do it. Hopefully it's not some crazy complicated mechanism like the rest of his code I'll have to poke around in there and see if I can find it.

While I haven't done anything specifically with fluids, you should be able to just make a new Material. Here's an example from one of my own blocks: I imagine it would be just about exactly the same to make a new fluid Material.

If you read my post, you will see that the code is from vanilla ItemBlock, not Block, and I was not suggesting you use that code, it was merely demonstrating that ItemBlocks do not register icons, with one sole exception. Whether that sole exception is hard-coded other places, such as getting sprite sheets, I am not sure, but if you crash when registering an icon in an ItemBlock class, then it seems quite likely. Did you try removing the registerIcons method from your ItemBlock classes, like I implicitly suggested?

EDIT: Due to coding for both 1.6.4 and 1.7.2, I simply switched back to a metadata-based block for the majority of my multi-texture blocks, and created a new but basically identical block that uses a tile entity for map-makers and creative users. This maintains high performance during world generation while still giving the option of a flexible tile entity for anyone who needs it, with the added benefit that it is extremely easy to code. Of course, this just foists the burden upon map-makers not to use too many tile entity blocks in their designs... Thanks TGG and diesieben07 for your suggestions. One of these days I'll have to delve into Trove so I can fix the problem for real ------------------------------------------------------------------------------------------------------- Hey all, I finally got around to making my dungeon blocks able to take on nearly any texture using a simple, non-updating TileEntity; however, as I'm sure most of you can guess, generating significant numbers of these blocks causes very noticeable lag when loading chunks, old or new. Previously, my block used metadata to determine which texture to return, and one bit for whether it could be broken or not, giving me up to eight textures as well as having excellent run-time performance. Is there any alternative to a TileEntity for a block that can have a bunch of different textures? I can think of two, but both are less than ideal: 1. Use getIcon(IBlockAccess, x, y, z, side) to use a neighboring texture, but this prevents me from choosing which texture I want and could get funky when each block is trying to get the texture from its neighbor, that in turn is trying to get its texture from the next neighbor and so on. 2. Have multiple metadata based blocks, each providing 8 textures, and a CreativeTab filled with my own versions of basically every regular vanilla block. Not very elegant. Barring any better suggestions, I may have to resort to a single meta-based block for my dungeons, and a tile entity-based block for the CreativeTab / people who want to mess around with it. Has anyone figured out a more performance-friendly way to accomplish this?

Do you think the look vector, or whatever the server thinks you're looking at needs to be modified? The render stuff you're doing presumably is client side, but at some point you have to translate what you're looking at into server side and maybe that is getting mucked up? Although I'm not sure why that would actually crash though, you think it would just think you're looking at the wrong thing and process as a proper left-click on whatever it thought you were looking at. I don't have Minecraft on this computer, but can't you look up that error message in the code and maybe figure out where it is going wrong based on the location of that message? That is indeed the problem - Minecraft uses the renderViewEntity not just for camera position, but also for calculating various other things among which is the objectMouseOver (from EntityRenderer). Changing the renderViewEntity to my dummy entity living base works for changing the camera position, but breaks the mouse over calculations somehow, and probably breaks many other things as well that I have yet to notice. It is possible to intercept mouse clicks, so it may also be possible to completely gloss over the vanilla objectMouseOver, using a custom one instead, but I am not a fan of that kind of solution in general. One would think that adjusting the camera's render viewpoint would be a simple matter of adjusting a single Y value or the like, but it's turning out to be much more complicated than I expected >.< Anyway, if I make any more progress on it, I will post it here. Until then, if anyone happens to know an easier way to accomplish this, I would be much obliged.

If you try to register Icons in your custom ItemBlock class, you will get this crash. ItemBlocks should not register textures, since they use the Block rendering - i.e. whatever icons you register in your block will be used for the item. If you register icons in the ItemBlock, it attempts to register them to the Item sprite sheet, crashing your game when it tries to render because it is expecting the Terrain (block) sprite sheet. At least that's what seems to happen everytime someone registers an Icon. Here is the code from vanilla ItemBlock#registerIcons: @SideOnly(Side.CLIENT) public void registerIcons(IconRegister par1IconRegister) { // note that Block#getItemIconName() returns null for all blocks except Hoppers // so only hoppers will register an icon here (according to java-docs) String s = Block.blocksList[this.blockID].getItemIconName(); if (s != null) { this.field_94588_b = par1IconRegister.registerIcon(s); } }

If only it were that simple. Changing the yOffset of the player results in the game crashing due to "an Illegal Stance" - that was the first thing I tried

itemRand is a Random object, meaning you use it to get random numbers - it's not an Item. You can use itemRand to get a random Item from the list of all registered items, or you could make your own list of items you want to give as rewards and select randomly from that. In either case, I suggest you start by brushing up on some basic Java, as it will make your journey much easier. For starters, here is the documentation on the Random class. That will help you figure out how to get a random number

To register subtype names using the LanguageRegistry, you actually have to create an instance of each ItemStack with the appropriate metadata/damage value, and register the name for it: for (int i = 0; i < numSubBlocksYouHave; ++i) { ItemStack stack = new ItemStack(yourBlock, 1, i); // easiest if you have a static array of Strings for the names // otherwise you can't use a for loop very well LanguageRegistry.addName(stack, yourBlock.names[i]); } In 1.6.4, in most cases you can also just use the vanilla ItemBlockWithMetadata directly, unless you need some special handling of onItemUse or the like. You may want to consider switching to a language file, though, since that's the way of the future.

With regards to performance, one way to do it is to have your cog/gear blocks notify neighbors when placed, and when your block receives notification that a neighbor changed, you can easily tell if it is a block you care about and then update the tile entity as needed. This way, you don't ever have to scan for nearby blocks.

Thanks TGG, that sounds reasonable. To change the player's render size, I did sneak in an extra glScalef using RenderPlayerEvent.Pre and Post, but that didn't work for the render view. Too bad there isn't a Forge hook in EntityRenderer#orientCamera Anyway, I'll post back here after I've had a chance to try your suggestion. Thanks again. EDIT: I tried creating a new EntityClientPlayerMP as a sort of fake player copy, and that kind of worked - the viewpoint was indeed where I put it, but the camera angle was freaking out between two different views. The same thing happened when I used a dummy extended EntityLivingBase, suggesting that the renderview entity is switching back and forth between the one I'm setting and mc.thePlayer. I set the fake entity at the start of the render tick (only if it is null do I create a new one), and tried both leaving it set and setting mc.renderViewEntity back to mc.thePlayer or null at tick end; neither way prevents the camera from freaking out which is strange, since the renderViewEntity should only be set in EntityRenderer when null. At any rate, lots of bad stuff happens when the renderViewEntity isn't an instance of EntityPlayer, so looks like it's time to try the first suggestion EDIT 2: Turns out the camera freaking out was because I forgot to set the previous positions... oops So actually the fake player / entitylivingbase works pretty well for changing the viewpoint, though 3rd person is still a bit jittery while walking. Using RenderPlayerEvent.Pre was still funky, but moving it to RenderGameOverlayEvent.Pre (for element type HELMET) works very well for 1st person, and avoids the camera shake in 3rd person (player movement is jittery). Interestingly, I don't have to explicitly set the camera height and it just works, even though I set the fakePlayer.posY to mc.thePlayer.posY (after resizing thePlayer, but not ever changing the position [due to Illegal Stance rubbish - same with trying to use yOffset]). However, as soon as I try to left-click, even air, it kicks me from the game with the following message: "[WARNING] [Minecraft-Server] Player coolAlias tried to attack an invalid entity" I tried to set the renderViewEntity back to mc.thePlayer for all overlays except the HELMET overlay, with the effect that clicking worked, but the camera was back to the original position. For context, here is my current code: Resizing of the player is done using Entity#setSize using either magnified or original width/height values. Size is changed only when the special item is equipped or unequipped. OverlayEvent FakeClientPlayer (nothing in it really specifies client only, but whatever)

As I mentioned in the OP, changing the eye height has no effect on the camera position, whether it is set positive or negative.

Hi all, I've been messing around with changing the player's size, and I've run into a snag: I can't seem to figure out how to get the player's in-game viewpoint to render at what should be their current eye height. Changing player.eyeHeight has no visible effect (and, quite counter-intuitively, the value appears to be zero by default on the client anyway). Then I found that Minecraft.getMinecraft().renderViewEntity is what determines the camera position and angle, but the docs say it's not suitable for changing the viewpoint mid-render. Indeed, when I changed the y position of the renderViewEntity during either render tick or render game overlay events, not only does the game bounce up and down, but the player also renders as floating above the ground by whatever value I set, which makes sense when I think about it because mc.renderViewEntity is likely just pointing to mc.thePlayer's memory location. So my question is, what's a good way to alter the in-game render position without also affecting the player's render position? Cheers, coolAlias

Did you try removing the y loop like I suggested? Like this: for(int ix = -1; ix < 2; ++ix) { for (int iz = -1; iz < 2; ++iz) { world.func_147480_a(x + ix, y, z + iz, true); stack.setItemDamage(stack.getItemDamage() - 9); } }

The final parameter of the model's render method is scale; you put '0'... model.render(pizza, 0.0F, 0.0F, 0.0F, 0.0F, 0.0F, 0); Vanilla often uses 0.0625F as the render scale; try that first, and go from there.

Have you ever used a model for an entity before? Add a field for your model in the render class and make sure to call the model's render methods when appropriate. While it's not the best example, you can see one here. It's 1.6.4, but everything to do with the model is exactly the same in 1.7.2. Every model / render is different, though, so the Rotate/Translate etc. methods you will need to tweak yourself until it looks right.

A custom projectile is just an entity, so whatever you can do in a normal Render class, you can do in your projectile entity's render class. So yes, you can use a model

Yes, the way you have your code it will break one 3x3 layer where you strike, plus one 3x3 layer both above and below that position, but the one above you'd only notice if you hit next to a wall or something. That's caused by the 'y' for loop that I pointed out earlier. One other point: you should only add/destroy blocks on the server (when the world is not remote), otherwise you can get ghost blocks - ones that either look like they exist but don't (when you add on the client), or are invisible but still block your path (when destroyed on the client).

Specifically, look at your "y" layer loop, and use your head - if you just want to break a single layer, do you really need to loop over the y values, or could you get by with just an x and z loop?

You are using the incorrect values in your for loops, i.e. checking "x < 2; ++x" instead of "ix < 2; ++ix"

Oh right, derp... forgot there is also that method in Item! Lol, sorry about that. @OP just listen to Busti, he knows what's up.

You don't, unless you are making a custom Block instead of an Item, but you're making a Hammer, right? Use what Busti suggested earlier, the onItemUse method in the Item class. The example with onBlockDestroyedByPlayer was likely just some code he had sitting around to demonstrate how to break all the blocks in a 3x3 area using "for" loops, but that's not the method you want.