ShetiPhian

There may be another way but, here is a trimmed down version of what I'm using. @Override protected BlockState createBlockState() { return new ExtendedBlockState(this, new IProperty[] { <Non Facing Properties> }, new IUnlistedProperty[] { OBJModel.OBJProperty.instance }); } @Override public IBlockState getExtendedState(IBlockState state, IBlockAccess world, BlockPos pos) { OBJModel.OBJState newState; newState = new OBJModel.OBJState(Lists.newArrayList(OBJModel.Group.ALL), true, new TRSRTransformation(TRSRTransformation.getMatrix(EnumFacing.NORTH))); return ((IExtendedBlockState)state).withProperty(OBJModel.OBJProperty.instance, newState); }

So I noticed chylex had created a test mod that helped sort out the issues in 1.7 (https://github.com/MinecraftForge/MinecraftForge/pull/2076) I made the minor changes needed to run it on 1.8.9 and it failed. Test: if (!BlockReplacedPlanks.class.isInstance(Blocks.planks)) throw new Exception("Block class type is incorrect: " + Blocks.planks.getClass().getName()); Error: "Test failed: Block class type is incorrect: net.minecraft.block.BlockPlanks" So I decided to skip that test and run again, failed again. Error: "Test failed: null" Cause: ItemBlock ib = (ItemBlock) Item.getItemFromBlock(Blocks.planks); < This returns null

Ran some tests with this: public void onPreInit(FMLPreInitializationEvent event) { this.testBlock = new TestBlock(); // this extends BlockTallGrass ItemBlock testItemBlock = (new ItemColored(this.testBlock, true)).setSubtypeNames(new String[] { "shrub", "grass", "fern" }); try { GameRegistry.addSubstitutionAlias("minecraft:tallgrass", GameRegistry.Type.BLOCK, this.testBlock); GameRegistry.addSubstitutionAlias("minecraft:tallgrass", GameRegistry.Type.ITEM, testItemBlock); } catch (ExistingSubstitutionException e) { e.printStackTrace(); } } Replacing both block and item (doesn't matter what order you replace them in): - Block renders correctly - F3 has correct information (in my 1.8.0 tests this was wrong) - Pick Block doesn't work - ItemBlock shows up twice in creative tab (normal position, and at end) - ItemBlock has an id of -1 - ItemBlock has no model - FML reports it can't find the model files - Placing Item Block crashes the game (due to having an id of -1) Replacing only the block: - Block renders correctly - F3 has correct information (in my 1.8.0 tests this was wrong) - Pick Block doesn't work - ItemBlock correctly shows up once on the creative tab - ItemBlock has the correct id - ItemBlock has no model - FML reports it can't find the model files - Placing Item Block does not crash the game, but places the original (onBlockPlaced on the new block is not called) Replacing only the item: Same as replacing block and item, but pick block works. I figured this would fail but I tried it anyway. Cannot register the block to the game registry before registering it to the substitution alias. "java.lang.IllegalArgumentException: The object substitution is already registered. This won't work" Edit: I just tried defining the itemblock after the block is registered: GameRegistry.addSubstitutionAlias("minecraft:tallgrass", GameRegistry.Type.BLOCK, this.testBlock); ItemBlock testItemBlock = (new ItemColored(Blocks.tallgrass, true)).setSubtypeNames(new String[] { "shrub", "grass", "fern" }); GameRegistry.addSubstitutionAlias("minecraft:tallgrass", GameRegistry.Type.ITEM, testItemBlock); No change from the other way of replacing the block and item.

Is ExtendedBlockStorage.get(int x, int y, int z) still returning air due to Block.BLOCK_STATE_IDS.getByValue(#) returning null? It was doing this in 1.8.0 when I attempted to use the alias system, I was told: So at this point we know: - What worked in 1.7.10 does not work in 1.8.x - The system does in fact work, we are just using it wrong - No one but cpw knows how to use it. - The system is basically useless because no one can figure it out. We need a working sample mod or detailed instructions.

I wasn't sure if this should wait until 1.9 or not so I didn't make a pull request. Also figured I should post here to see if there was any others wanted. PlantType Soil Block Lava Material.lava && BlockLiquid.LEVEL = 0 End Blocks.end_stone Is there any others anyone else needs/wants? It would be best to make one pull request that has the all. Sidenote: BlockLilyPad.canBlockStay is hard coded to water, simple fix though as it extends BlockBush which already uses IPlantable. Depending on what is preferred that fix can be a separate pull made at the same time or lumped in with the rest of the changes.

drawTexturedModalRect uses a 256 x 256 texture. If you want to load a different size you'll need to make your own draw function. scratch that. 0.00390625F is 1 / 256 Edit: Ernio is correct, drawModalRectWithCustomSizedTexture is what you want. For my mods in-game wiki I needed scaling, flipping, and custom sizes; so I coded a function that did everything and completely forgot Minecraft had more then drawTexturedModalRect (not sure when drawScaledCustomSizeModalRect appeared but I'm sure it wasn't there before, I could have used it for about 2/3rds of my images)

@Liahim Sorry for the confusion, I was pointing out the UV error to JimiIT92. As for your particle issue, I'm not sure. I've currently got a block with the opposite issue; item and block colored correctly but particles are grey. Eventually I'll look into it but since I have larger parts of my mod left to upgrade its low priority. I'm am using tintindex 1 for that block so my thinking is: tintindex 0 might always be used for particles so anything other then white results in colored particles, and the default grass is case exempted. But that is based entirely on observation and has no bases in the code itself. EDIT: After posting I started wonder why I was still using tintindex 1, (it was from an older model design, and I simply didn't go through and change it) So I change my models to use tintindex 0 and updated the colorMultiplier, and my particles are correctly colored. This makes it look even more like tintindex 0 is always used on particles and grass is just hard coded. I'd suggest using tintindex 1 in your model and changing it in your Block.colorMultiplier and Item.getColorFromItemStack.

The UV's in your models are off, currently they are rendering the full texture on half a block. half_grass_slab block model: { "textures": { "particle": "blocks/dirt", "bottom": "blocks/dirt", "top": "blocks/grass_top", "side": "blocks/grass_side", "overlay": "blocks/grass_side_overlay" }, "elements": [ { "from": [ 0, 0, 0 ], "to": [ 16, 8, 16 ], "faces": { "down": { "uv": [ 0, 0, 16, 16 ], "texture": "#bottom", "cullface": "down" }, "up": { "uv": [ 0, 0, 16, 16 ], "texture": "#top", "tintindex": 0 }, "north": { "uv": [ 0, 8, 16, 16 ], "texture": "#side", "cullface": "north" }, "south": { "uv": [ 0, 8, 16, 16 ], "texture": "#side", "cullface": "south" }, "west": { "uv": [ 0, 8, 16, 16 ], "texture": "#side", "cullface": "west" }, "east": { "uv": [ 0, 8, 16, 16 ], "texture": "#side", "cullface": "east" } } }, { "from": [ 0, 0, 0 ], "to": [ 16, 8, 16 ], "faces": { "north": { "uv": [ 0, 0, 16, 8 ], "texture": "#overlay", "tintindex": 0, "cullface": "north" }, "south": { "uv": [ 0, 0, 16, 8 ], "texture": "#overlay", "tintindex": 0, "cullface": "south" }, "west": { "uv": [ 0, 0, 16, 8 ], "texture": "#overlay", "tintindex": 0, "cullface": "west" }, "east": { "uv": [ 0, 0, 16, 8 ], "texture": "#overlay", "tintindex": 0, "cullface": "east" } } } ] } upper_grass_slab block model: { "textures": { "particle": "blocks/dirt", "bottom": "blocks/dirt", "top": "blocks/grass_top", "side": "blocks/grass_side", "overlay": "blocks/grass_side_overlay" }, "elements": [ { "from": [ 0, 8, 0 ], "to": [ 16, 16, 16 ], "faces": { "down": { "uv": [ 0, 0, 16, 16 ], "texture": "#bottom" }, "up": { "uv": [ 0, 0, 16, 16 ], "texture": "#top", "tintindex": 0, "cullface": "up" }, "north": { "uv": [ 0, 0, 16, 8 ], "texture": "#side", "cullface": "north" }, "south": { "uv": [ 0, 0, 16, 8 ], "texture": "#side", "cullface": "south" }, "west": { "uv": [ 0, 0, 16, 8 ], "texture": "#side", "cullface": "west" }, "east": { "uv": [ 0, 0, 16, 8 ], "texture": "#side", "cullface": "east" } } }, { "from": [ 0, 8, 0 ], "to": [ 16, 16, 16 ], "faces": { "north": { "uv": [ 0, 0, 16, 8 ], "texture": "#overlay", "tintindex": 0, "cullface": "north" }, "south": { "uv": [ 0, 0, 16, 8 ], "texture": "#overlay", "tintindex": 0, "cullface": "south" }, "west": { "uv": [ 0, 0, 16, 8 ], "texture": "#overlay", "tintindex": 0, "cullface": "west" }, "east": { "uv": [ 0, 0, 16, 8 ], "texture": "#overlay", "tintindex": 0, "cullface": "east" } } } ] }

Not sure if your just making a simple slip-up or don't know java well enough yet. A single equals is for assigning a value, a double equals is for comparing. (worldIn.isRemote = false) ^ This is trying to set the isRemote field to false, but you can't because its final. if (worldIn.isRemote == false) ^ this is what you want Or better yet: if (!worldIn.isRemote) It is the shortened form of: if (worldIn.isRemote != true) The exclamation mark represents not, so the statement is read as 'if world.isRemote is not true' thus its false.

Are you after an animated texture while your generator is active? I have not yet made my animated textures so I can't verify if this works yet. But... I made my animated textures and this works perfectly (source: http://minecraft.gamepedia.com/Resource_pack) So in your case you'd make a new texture "generator_front_active.png" that is the same width as the ones you have now but is three times as tall that contains your original three. next make a text file named "generator_front_active.png.mcmeta", with the following code: { "animation": { "frametime": 2, "frames": [ 0, 1, 2, 1 ] } } You would no longer need the multiple active states a boolean would do. while active=false you use the static "generator_front", and when active=true you use the animated "generator_front_active"

Blocks and items would be incompatible and faster to remake vs convert. Entity models I believe haven't changed much (if at all) you can use jd-gui or similar program to view those files.

Well I've tried that test mod I posted again. I've tried registering the alias in PreInit, Init, and PostInit. Every time it the same result. The block is replaced, the F3 screen shows null type: tall_grass before replacement it shows: minefraft:tallgrass type: tall_grass The original item in the creative menu has no texture and can not be placed due to failing Block.BLOCK_STATE_IDS.getByValue(#) If you use pick block, you get an item with correct texture but placing it crashes the game. java.lang.ArrayIndexOutOfBoundsException: -1 at net.minecraft.item.ItemStack.onItemUse(ItemStack.java:151) at net.minecraft.client.multiplayer.PlayerControllerMP.func_178890_a(PlayerControllerMP.java:442) ItemStack.java:151 => playerIn.triggerAchievement(StatList.objectUseStats[item.getIdFromItem(this.item)]);

I just re-implemented, or at least attempted to, a block substitution into my mod. The substitution alias does appear to be currently broken. You can't place the block because ItemBlock.placeBlockAt eventually gets to ExtendedBlockStorage.get(int x, int y, int z) and it always returns air. It does that because Block.BLOCK_STATE_IDS.getByValue(#) always returns null. Up until that point it appears to be working. Here is a quick test mod if anyone wants to look into it. With the exception of function names and imports changing, this is the same code works in 1.7 package net.minecraftforge.debug; import net.minecraft.block.Block; import net.minecraft.block.BlockTallGrass; import net.minecraft.item.ItemBlock; import net.minecraft.item.ItemColored; import net.minecraftforge.fml.common.Mod; import net.minecraftforge.fml.common.event.FMLPreInitializationEvent; import net.minecraftforge.fml.common.registry.ExistingSubstitutionException; import net.minecraftforge.fml.common.registry.GameRegistry; @Mod(modid = "substitutionaliastest") public class SubstitutionAliasTest { private Block testBlock; @Mod.EventHandler public void onPreInit(FMLPreInitializationEvent event) { this.testBlock = new TestBlock(); ItemBlock testItemBlock = (new ItemColored(this.testBlock, true)).setSubtypeNames(new String[] { "shrub", "grass", "fern" }); try { GameRegistry.addSubstitutionAlias("minecraft:tallgrass", GameRegistry.Type.BLOCK, this.testBlock); GameRegistry.addSubstitutionAlias("minecraft:tallgrass", GameRegistry.Type.ITEM, testItemBlock); } catch (ExistingSubstitutionException e) { e.printStackTrace(); } } public static class TestBlock extends BlockTallGrass { public TestBlock() { super(); super.setUnlocalizedName("tallgrass"); setHardness(0.0F); setStepSound(soundTypeGrass); setUnlocalizedName("tallgrass"); } } }

So my problem was me putting the forge state json in the wrong place, I had put it in the items folder. I ended up writing my own baked model that extended OBJBakedModel. Not a waste of time though as I needed to change the render based on nbt anyway. I ran into the obj/mtl file edits requirement while working on blocks, but the Debug files helped out there. Only issues there is: - not knowing how to get the "custom" tag, but I don't think that can be done as the debug is just a placeholder last I checked. - break particles being white, block renders fine though. Had the same issue when I used a model and mtl from the debug folders, so maybe not implemented yet.

I was getting random WorldServer#tick() crashes on the blocks I had overridden getLightOpacity on and used the blockstate to set the value. (now I check if the block is mine first) The issue is in Chunk.setBlockState(BlockPos, IBlockState) this line: int j1 = block.getLightOpacity(this.worldObj, pos); block is the new block, but at that point in time the old block is at that location. The next line sets the world position to the new block. j1 appears to be used to store the old light value to later compare to the new one, and if they are different the lighting gets updated. I believe that line should be: int j1 = block1.getLightOpacity(this.worldObj, pos);

Well I had some time to take another crack at this. You can not use a forge state json with the obj defined at a model, works for blocks but not items. Nor can you use a model json with the obj defined as a parent. Both throw the error: com.google.gson.JsonParseException: BlockModel requires either elements or parent, found neither What did work, partly. In the proxy preinit add a variant name that points to the obj file and include the '.obj' In the proxy init register the item model, also needs to point to the obj and include '.obj' That works to get the obj in game, just need to solve how to set transformations. I'm guessing that will need to be done with the ModelBakeEvent but it will have to wait until I get another chance to go digging.

So how did you get it to work? I'm currently unable use OBJ's for items. (Blocks were easy, just followed the forge debug examples. now waiting on the custom tag one) I know its something relatively simple I'm overlooking, but for the life of me I'm stumped and I wasn't able to fine an example to go by. The 'fun' I've had trying to get this to work is in the spoiler, so unless you care to read you can skip opening it.

So I found out why it seemed variants could not change the model. modelSet is always false, so the parent variant's model is always used, even if its undefined (results in null) and the child has a model set. So as it currently stands the only variant that can change the model is the first one alphabetically, and if that one has no model defined it falls back to the one in defaults. Changing the check from !this.modelSet to this.model == null in ForgeBlockStateV1.sync, allows any variant to change the model. But this is not the proper fix, modelSet needs correcting, and that will correct the check. Duh This is a new instance of Variant, this.modelSet is always going to be false. But the parent on the other hand, if its model has been set its modelSet will be true. So the sync code should not be checking the child only, the parent should be checked also. In turn making it: if (!this.modelSet && parent.modelSet) { this.model = parent.model; this.modelSet = true; } just adding: if (!this.modelSet) this.modelSet = parent.modelSet; after: if (!this.modelSet) this.model = parent.model; works also, and its just one line added rather then 1 deleted and 4 added. This make my first two code snip-its function correctly. This still doesn't solve the issue of the submodels and incorrect textures though.

Here is the link to the format to get everyone on the same page; https://github.com/MinecraftForge/MinecraftForge/pull/1885 I decided to play with this by converting my old files I made just after the release of Forge for 1.8 With the base Minecraft system this is what it took to simply change textures: blockstate file was 4373 lines, with 550 models (24KB) With this new system its only taking ~300 lines and 2 models (might need 4), and its far cleaner. Sadly its not working 100% correctly yet, I don't know if I'm doing something wrong, I'm hitting a bug, or if the new system just can't do what I want. The old way works perfectly so I know its not in the code, its solely the blockstate. I'll sum up the issue right now and go deeper into what I've done bellow; It looks like the new system is unable to change the main model, and submodels get the wrong texture data If I do not define a model in "defaults" but define it in one of the variants Minecraft crashes telling me there is no model or submodel If I define a model in defaults, it is used for both blocks (thus ignoring that is gets changed in variants) but the overlay texture is correct. If I do not define a model in "defaults" but define a submodel in one of the variants, the models are correct but the overlays are wrong. regardless of what the spread number is the models seem to ignore it, every north+head will use the same texture, and every south+foot will use another, its like this for all eight blocks. So it appears like the main model can not be altered in variants, and submodels do not process texture data correctly. It also very possible it can do what I want but I'm making a mistake, but I can't seem to find what it is. EDIT: So I thought maybe textures are only screwy on models defined outside of the "defaults" but I ran into new issues and was unable to text that. First you can only have one model, this I expected. Second you don't seem to be able to define submodels in defaults. Error I kept getting when I tried: "defaults" variant cannot contain a simple "submodel" definition I tried all three submodel formats Zaggy1024 provided in the examples (Zaggy1024 wrote the sub model system) Even the submodel format shown in the "defaults" throws that error. https://github.com/LexManos/MinecraftForge/pull/1 & http://pastebin.com/TjW6V9a3

There is another option, B3D. I can't tell you anything about it as I haven't played with it yet. (I skipped it because it looks like textures are referenced in the model and I needed to be able to change them) https://github.com/RainWarrior/B3DExport Here is the link to the B3D example (you'll need the resources from the test folder as well) https://github.com/MinecraftForge/MinecraftForge/blob/master/src/test/java/net/minecraftforge/debug/ModelLoaderRegistryDebug.java When RainWarrior added it (Dec 27, 2014) he posted "OBJ loader is being written, will be included at some point in the future. For now you can convert OBJ to B3D via blender, or wait." https://github.com/MinecraftForge/MinecraftForge/commit/6eba0ebb93cafe8dd7c061d92bae0dd4c8d324e3

I've played around with this. AdvancedModelLoader is easily converted to function with 1.8, and using it with TileEntitySpecialRenderer renders blocks just like 1.7 did. But you can not render an item from an obj this way. (if you plan on using only 2d models this will do) I've toyed with a modified version of WavefrontObject (part of AdvancedModelLoader) that provides the needed info to use IBakedModel. You need to remake your .obj file - separate your faces into facing groups, so the shadows are correct. - make sure is created as quads (or you'll get noticeable lines on the faces) This is still flawed however, models that are bigger then a single block have incorrect shadows on parts that extend beyond. [in my case mine is double tall, while the base part is correct the upper half looks to be basing its shadows off the block bellow the main one] Items are also rendered too big in 3rd person but I'm sure that is fixed by using IPerspectiveAwareModel IMHO: BDcraft Cubik is a poor substitute to obj support.

So an idea hit me and I ran with it, looks good so far Using a modified version of the old WavefrontObject class (and other required classes), to load the model and create the baked quads needed by IBakedModel. I even got rotation and scaling working. Have two issues though both may only be fixable by changes in the obj its self. Issue 1: the model was made with triangles and quads are required, so I used the last vertex twice. This left noticeable triangles. Fix Idea: rebuild models using only quads. Issue 2: shadows are wrong due to me setting all faces to up, I don't think I can extract the direction based on the vertices Fix Idea: rebuild models and group faces into directions

Getting AdvancedModelLoader to work on 1.8 was surprisingly easy, I have to wonder why it is still missing from Forge. Setting my block's getRenderType to -1 gets rid of the black/purple cube. Using TileEntitySpecialRenderer allows my block to render correctly. Just need to figure out how to get the items to render again. Guess I need to see how the chest does it, might need to see about restoring IItemRenderer I think Forge for 1.7 was prematurely dropped, 1.8 is lacking in rendering abilities (and is the most poorly documented part of Forge)

I've gotten stuck I'll start with what worked in 1.7 - Items are crafted using stone and/or planks, and the materials are stored in nbt (for texture info while rendering) - When the block is placed the nbt is stored in the tile entity - While rendering the first texture was loaded and render part was called, this was done 4 time to render the full model Now for 1.8 - As expected crafting and storing the materials in nbt works, so does moving it to the tile entity. - Material info is placed in the block state so I'm ready for rendering. Using json models is out, due to shape and texture limits. Baked models seem to be restricted to cubes like the json files B3D looks to have the texture imbedded I need to be able load a texture obtained from the block state, that is unknown prior to crafting. Render part of the model, load the next texture from the block state, and render the next part. and so on until all four parts are rendered If your looking for code I have nothing useful to show, nothing has been done up for 1.8 rendering and the old 1.7 code is nothing special just bindTexture & renderPart sets.

I'm so frustrated and mentally exhausted am not sure what I type here will make since. My block has a few base models and several overlay models. Before 1.8 I rendered the needed base, then rendered the needed overlay on top. I have my json files build for both the bases and overlays, and tested (by directly setting them in the blockstate json, they load correctly). My blocks BlockStates are correctly functioning. I'm just down to rendering, but everything so far has failed. I'm trying to read two json model files, and create a merged model from them, that I then can register to a blockstate. I'm back to a blank slate. Currently in ModelBakeEvent, I've grabbed all my base & overlays as ModelBlock. EDIT: Looks like I just needed a break Not sure if there is a better way but I did get it working. Summery: TextureStitchEvent.Pre - Read json files to ModleBlock's - Set parents for ModelBlocks's - Read textures from ModelBlocks's and register for stitching ModelBakeEvent - Generate ModelResourceLocation - Grab and bake needed base model and overlay model - Merge models, new SimpleBakedModel based on base model with GeneralQuads and FaceQuads copied from both base and overlay - Register to ModelRegistry Edit2: After further testing this method is not recommended. It is much slower then having Minecraft load models listed the BlockState jsons. While this would be useful for a large amount of possible combinations the ~2sec load time per model ends up being a significant delay and with few combinations there is no point in not using json files.