TheGreyGhost

By crikey dude the logic behind that code is pretty messed up. Calling handlePerspective from within handlePerspective is not going to end well. The simplest way of doing this is like this 1) in handleItemState(), save your itemstate information into the model and return 'this' 2) in handlePerspective(), save your cameraTransformType into the model and return a new pair of this and the Matrix4f corresponding to the selected view, I think you can get this from ForgeHooksClient.getMatrix() by supplying it with the correct transform for the cameraTransformType, eg model.getItemCameraTransforms().firstPerson 3) in your IBakedModel.getGeneralQuads(), use the stored itemstate and cameraTransformType to generate the appropriate model Haven't tried it in code so it might need tweaking. -TGG

Hi THis tutorial project has an example (MBE08) which might help you https://github.com/TheGreyGhost/MinecraftByExample -TGG

Hi YOu might find this tutorial project useful https://github.com/TheGreyGhost/MinecraftByExample Look at MBE60 for network messages to do this sort of thing (send a message to the server in response to a button click) -TGG

Hi You must match capitalisation of paths exactly. I suggest you should just use lower case for everything especially your modid. This troubleshooting guide might also help http://greyminecraftcoder.blogspot.com.au/2015/03/troubleshooting-block-and-item-rendering.html -TGG

Hi Yeah the whole modelling system takes quite a bit of getting used to. What you want to do will work fine. You should create a class that implements both IPerspectiveAwareModel and ISmartItemModel. handleItemState() will be called first, so you return an IPerspectiveAwareModel which saves the itemstate information internally for later reference Immediately after, Forge will call handlePerspective with your IPerspectiveAwareModel (which has the saved itemstate info), and you can select or generate the correct first vs third person model. -TGG

Does it work if you install it in a dedicated server without all those other mods? If you browse through your built jar, can you find the RSARead class in expected path? -TGG

Hi This might be useful too http://greyminecraftcoder.blogspot.com.au/2015/02/recipes.html -TGG

Hi Depends what you mean by animation. Torch in your hand, or in the world (as a block)? BlockTorch is the vanilla torch. But BlockFire might be more interesting. Best way for block animation is by animated textures. You can do that with mcmeta textures, for example see fire_layer_0.png and fire_layer_0.png.mcmeta. A google on animated textures will also bring up a relevant tutorial or two. -TGG

Hi This tutorial project has examples of ISmartItemModel and IFlexibleBakedModel https://github.com/TheGreyGhost/MinecraftByExample It sounds like ISmartModel is what you need here. Don't worry about the deprecation warnings for IBakedModel. That's just RainWarrior's way of persuading you to use his new interfaces, which are not necessary in most cases. -TGG

Hi Try setting useNeighborBrightness = true in your block's constructor http://www.minecraftforge.net/forum/index.php/topic,32060.msg167789.html#msg167789 -TGG

Hi I think you will probably need to use ASM+Reflection to overwrite parts of the vanilla code in EntityRenderer.updateLightMap(). That's pretty tricky to get right, but the change itself will be very simple. There are a few tutorials around on how to use ASM+Reflection. -TGG

Hi Not sure what you want but these from BlockGrass might help Block:: @SideOnly(Side.CLIENT) public int getBlockColor() { return ColorizerGrass.getGrassColor(0.5D, 1.0D); } @SideOnly(Side.CLIENT) public int getRenderColor(IBlockState state) { return this.getBlockColor(); } @SideOnly(Side.CLIENT) public int colorMultiplier(IBlockAccess worldIn, BlockPos pos, int renderPass) { return BiomeColorHelper.getGrassColorAtPos(worldIn, pos); } -TGG

Hi Pls show your blockstates json, your item json, and the code where you register your block & item? It looks like you've specified the name of a texture (blocks/wool_colored_light_blue) where a block model json was expected This link might help if you need answers faster http://greyminecraftcoder.blogspot.com.au/2015/03/troubleshooting-block-and-item-rendering.html -TGG

Hi I'm guessing that the mod actually modifies the block lighting texture, not the minimum light level (which is already zero) This link explains a bit more http://greyminecraftcoder.blogspot.com.au/2014/12/lighting-18.html I imagine that if the [0,0] entry is fully black, unlit blocks will be completely black. -TGG

Hi Have a look in the console for an error which mentions your leaves. You will probably find something that says it expects to find "decayable=true,check_decay=true" but couldn't. ->either add these to your blockstates file (four lines instead of just one) or add a custom state mapper http://www.minecraftforge.net/forum/index.php/topic,28997.msg149446.html#msg149446 -TGG

No worries The 1.8 Models are just really hard to get right. One little thing wrong and it just doesn't work, usually without any helpful symptoms. I nearly put my first through the screen once after spending 3 hours due to an l which looked like a 1 in the font of the editor I was using. -TGG

Hi OK. That means you've other problems as well as the state mapping- your properties are probably correct but there's something wrong with the model names, locations, model files, and/or texture files, etc This link might help you now http://greyminecraftcoder.blogspot.com.au/2015/03/troubleshooting-block-and-item-rendering.html -TGG

Hi I've never heard of "ground" and "fixed" before. Where did you get those from? The last time I reviewed the rendering code, dropped items and items in frames use no translation at all (see ItemCameraTransforms.Deserializer and ForgeHooksClient.handleCameraTransforms, RenderItem.renderItemModel, RenderEntityItem and RenderItemFrame ) In order to change those, you should change your model so that it looks right without any rotation, translation, or scale at all. -TGG

Hi This link might help http://greyminecraftcoder.blogspot.com.au/2015/03/troubleshooting-block-and-item-rendering.html -TGG

Hi The weird snap-back after five seconds is caused by some poor coding practice by Mojang, which I discovered back in 1.6.4 after a lot of pulling my hair out It is caused because the entity position is updated to the client using "position change relative to last position" instead of "move to position [x,y,z]". The "move to position [x,y,z]" are only issued every 5 seconds or so. But EntityArrow have to be treated slightly differently otherwise the initial position is off by one and all the "position change relative to last position" messages are out of sync. After 5 seconds it sends an absolute "move to position [x,y,z]" and the arrow pops to the correct position on the client. The offending line is here EntityTrackerEntry.updatePlayerList if (this.updateCounter > 0 || this.trackedEntity instanceof EntityArrow) The easiest fix is to make your custom arrow extend EntityArrow. That fixed all my problems with arrows. -TGG

Hi I would suggest; try troubleshooting a bit more without the state mapper because it seems to be causing confusion. i.e. just add the extra lines to your blockstates file and get it working that way first for a couple of the states. If the error message for that stage disappears, and the model renders properly, you'll have eliminate all the other likely causes of the problem eg change this line "facing=east,half=lower,hinge=left,open=false": { "model": "doornetherack_bottom" }, to "facing=east,half=lower,hinge=left,open=false,powered=false": { "model": "doornetherack_bottom" }, "facing=east,half=lower,hinge=left,open=false,powered=true": { "model": "doornetherack_bottom" }, -TGG

This might help http://greyminecraftcoder.blogspot.com.au/2015/03/troubleshooting-block-and-item-rendering.html -TGG

Awesome dude, nice work > boolean flag1 = block13 instanceof BlockStairs; > boolean flag2 = block13 instanceof BlockSlab; I should have guessed, freakin' Mojang and their dirty little quick fixes. I think this is a good candidate for a Forge patch. In your case, you could override getUseNeighbourBrightness() without having to access the protected field. It's funny though, a couple of your symptoms don't seem to match that root cause, guess there's something more subtle going on that I'm not seeing. -TGG

Hi It's because your item texture goes right to the edge of the 16x16. Have a look at minecraft vanilla textures eg stick, sword, etc. They all leave the rightmost column and topmost row of voxels free. [edit] actually the sword does go right to the edge! Odd. But anyway, I had this problem for one of my item icons, and leaving the rightmost + topmost free fixed it for me. -TGG

Yes but how to do triangles in a json file ? I've seen a resource-pack json model using vertex but this resource-pack doesn't work anymore on 1.8 (it does before) Ah yeah, brain fade sorry. I think you could also do this using the Blitz3D (B3DLoader) model loader for blocks that is now built into forge. I don't reckon the vanilla model json can handle triangles (sloped quads yes, three-sided degenerate quads no). Yes and that's the real problem now ! EDIT : If no-one find out from where the bug comes, it's maybe a Forge bug... So I tried to report the issue : https://github.com/MinecraftForge/MinecraftForge/issues/2019 And my problem for the triangles in json is still there ! (I will create a new post for that if the lighting bug is solved) Does the problem go away if you derive from a different type of block instead of BlockStairs? Do the dark sections stay there permanently or do they eventually pop to the correct value (a lighting update issue) after time, or if you place another block nearby? You might also be able to narrow it down to an ambient occlusion / fancy lighting issue (a couple of those screenshots look like an ambient occlusion problem). I think this will be hard to track down; you would probably need to put a couple of breakpoints in the rendering code and see why the adjacent blocks are getting dud values for lighting calcs from your block. -TGG