Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

SuperGeniusZeb

Forge Modder
  • Posts

    70
  • Joined

  • Last visited

Everything posted by SuperGeniusZeb

  1. Use the latest version. 1.9 isn't as big a gap from 1.8.9 as 1.7.10 to 1.8 was, so most mods will be updating to 1.9 pretty soon, especially thanks to the neat changes/additions like potion and villager profession registries, universal bucket system, loot tables, and the upcoming Forge Multipart API, all of which are considerably useful additions to modding. It really isn't worth it to develop for anything before 1.8.9, and ESPECIALLY not 1.7.10.
  2. Use the latest version. 1.9 isn't as big a gap from 1.8.9 as 1.7.10 to 1.8 was, so most mods will be updating to 1.9 pretty soon, especially thanks to the neat changes/additions like potion and villager profession registries, universal bucket system, loot tables, and the upcoming Forge Multipart API, all of which are considerably useful additions to modding. It really isn't worth it to develop for anything before 1.8.9, and ESPECIALLY not 1.7.10.
  3. Here's a helpful article on Forge events, though some info might be out-of-date as it was written back in the days of 1.7.10.) http://greyminecraftcoder.blogspot.com/2013/12/forge-techniques-events.html
  4. Here's a helpful article on Forge events, though some info might be out-of-date as it was written back in the days of 1.7.10.) http://greyminecraftcoder.blogspot.com/2013/12/forge-techniques-events.html
  5. Ah, ok, that makes sense. I've now made the methods static. I would have merged the 2 interfaces into one that extends IForgeRegistryEntry, but it became impossible (as far as I know, correct me if I'm wrong) to call setUnlocalizedName() since that isn't one of IForgeRegistryEntry's methods. Thanks for the advice!
  6. Ah, ok, that makes sense. I've now made the methods static. I would have merged the 2 interfaces into one that extends IForgeRegistryEntry, but it became impossible (as far as I know, correct me if I'm wrong) to call setUnlocalizedName() since that isn't one of IForgeRegistryEntry's methods. Thanks for the advice!
  7. I know you can use "this" in default methods, but since the methods are defined in separate classes from the ones they are used in (IItemName.java & IBlockName.java), using something like "this.setRegistryName()" in the method won't work because it will try to call IItemName.setRegistryName() or IBlockName.setRegistryName(), which obviously don't exist. here's my interface classes: IBlockName.java package com.supergeniuszeb.colore.common.blocks; import com.supergeniuszeb.colore.Reference; import net.minecraft.block.Block; public interface IBlockName { //A utility method for setting both the registryName & unlocalizedName of blocks. default void setBlockName(Block block, String blockName) { block.setRegistryName(Reference.MOD_ID, blockName); block.setUnlocalizedName(block.getRegistryName().toString()); } } IItemName.java package com.supergeniuszeb.colore.common.items; import com.supergeniuszeb.colore.Reference; import net.minecraft.item.Item; public interface IItemName { //A utility method for setting both the registryName & unlocalizedName of items. default void setItemName(Item item, String itemName) { item.setRegistryName(Reference.MOD_ID, itemName); item.setUnlocalizedName(item.getRegistryName().toString()); } } Am I missing something or have I just not explained things properly?
  8. You also can't push TileEntities with pistons (or at least not until Mojang ports MCPE 0.15.0's piston changes, which may not be until 1.11), so there's that, too.
  9. Hmmm... it looks like I'm stuck then, unless someone else has an answer or the format gets updated. I guess I'll have to go back to the vanilla format. One more question, though. Is it possible to have define what happens if 2 or more properties are true in the Forge blockstates format? (As in ' "shade=true,half=false,north=true,shape=straight":{} ' like in the vanilla format or something like that.) Because I haven't found any examples where you can define what happens with more than one condition at a time, and I feel like that may be one advantage of the vanilla format that should be added to Forge's format if it doesn't already exist. If that's possible in the Forge format, I'll be able to still do what I want to do, albeit in a more lengthy way and using the vanilla stairs models instead of constructing models from submodels.
  10. The methods are defined once in the interfaces called IItemName & IBlockName and aren't actually defined in any of the classes that implement it, hence the "default" modifier and the need to use "this" as a parameter (so the method knows what class it is registering). I probably should have made that clear in my first post. Is that a good way to do it, or should the interfaces just have blank methods (like most of the Forge interfaces) and leave it to the implementing classes to define what the method does? Because by doing it this way, I can easily change what the method does without having to go into every item/block class and change each implementation individually.
  11. To quote Choonster: I personally use an interface containing a method called setItemName (or setBlockName for blocks) that looks like this: //items default void setItemName(Item item, String itemName) { item.setRegistryName(Reference.MOD_ID, itemName); item.setUnlocalizedName(item.getRegistryName().toString()); } //blocks default void setBlockName(Block block, String blockName) { block.setRegistryName(Reference.MOD_ID, blockName); block.setUnlocalizedName(block.getRegistryName().toString()); } And all my item/block classes implement the interface and use the method in their constructor like so: public BlockExample(String name) { super(Material.ROCK); this.setBlockName(this, name); } //or public ItemExample(String name) { super(); this.setItemName(this, name); } And also, you should be using ModelLoader.setCustomModelResourceLocation() instead of Minecraft.getMinecraft().getRenderItem().getItemModelMesher().register(). See this helpful document on the model-loading process as of 1.9, also by Choonster: https://gist.github.com/Choonster/1ee75eecb82c001ec10eca75be924bce
  12. When you rotate an asymmetric model 180 around z or x axis to turn stairs upside-down, then you will change one facing in the process (x-axis flips N-S; z flips E-W). If you have trouble visualizing this in your head, then get something wedge-shaped that you can turn in your hands. Then for this particular model, the default facing is east (the rotation zero need not be written into the json file). Are you sure? I thought Y was vertical, hence rotating around it to face E-S-W-N. Don't confuse the axis of rotation with the faces around it. Get that wedge in your hands and start playing with it to see what I mean. I think so: You may apply X, Y & Z rotations. That's 3 axes. You should never need more. Whoops. Yeah, you're right about the axis. And I know the zero rotation didn't need to be written, but strangely enough, when I specify it to be zero, the east-facing stairs stops being an anomaly. But the thing about the x rotation is that it isn't even being applied at all. As in the upside-down stairs look identical to right-side-up stairs of the same "facing" and "shape" values. If I remove the y rotations, the x rotations suddenly work, but (of course) the stairs model will only face one direction. So while yes, the models would look wrong if they were simply rotated 180 degrees in the x axis, that's not my problem because the models aren't getting rotated in the x axis at all. It's like it won't let me rotate the entire model in more than one axis at a time, so I can only have either y-rotation or x-rotation, but not both. Is this intended behavior, is it a bug, or am I missing something in my .json?
  13. So I've been converting all my blocks to use the Forge blockstate .json format instead of the vanilla one, and changing my item models so that most block model jsons are unnecessary, allowing me to reduce the total number of .json files in my mod, which is pretty much entirely comprised of basic-shaped blocks (full cubes, slabs, stairs, fences, etc.) It has gone great so far up until this point. I'm currently trying to create a blockstates .json for my custom stairs using the Forge format. (In the example here its the "stairs_of_red_normal"... keep in mind that unlike my previous examples in my mod, the shade "normal" is not metadata here but just part of the name as the stairs metadata didn't have enough room for my "shade" property I used on my other blocks.) I've created 2 model .jsons, "cube_quarter_horizontal" & "cube_eighth", which are basically equivalent to the top half of an outer stairs and the top half of a straight stairs respectively. I'm using these with the vanilla "half_slab" model to try and contruct the proper stairs shape using the forge blockstates .json format. The stairs work perfectly for bottom half stairs, but for top half (upside-down) stairs, the models are the same as their top half counterparts (though the block itself changes). Interestingly, it looks like an east-facing stairs is the exception to the rule, as it DOES rotate the model 180 degrees when it is placed upside-down. Looking at the .json, "east" is the only value of "facing" that does not have a y rotation specified (remember that y is left-right in block .jsons and x is up-down), so I have a feeling that there is a limit to the number of rotations you can apply to a model or submodel in the Forge blockstates format. Is this the case? Can I not rotate the entire model in more than one axis? Is this a limitation of Forge blockstates, vanilla, or is it a bug? Is there anyway around this? Logically, I would think that the .json I've created should work. Any ideas? blockstates/stairs_of_red_normal.json (Forge blockstates .json) { "forge_marker": 1, "defaults": { "textures": { "bottom": "colore:blocks/block_of_red_normal", "top": "colore:blocks/block_of_red_normal", "side": "colore:blocks/block_of_red_normal" }, "model": "half_slab" }, "variants": { "facing": { "east": { }, "south": { "y": 90 }, "west": { "y": 180 }, "north": { "y": 270 } }, "shape": { "straight": { "submodel": { "quarter": { "model": "colore:cube_quarter_horizontal" } } }, "outer_right": { "submodel": { "eighth": { "model": "colore:cube_eighth" } } }, "outer_left": { "submodel": { "eighth": { "model": "colore:cube_eighth", "y": 270 } } }, "inner_right": { "submodel": { "quarter": { "model": "colore:cube_quarter_horizontal" }, "eighth": { "model": "colore:cube_eighth" , "y": 90 } } }, "inner_left": { "submodel": { "quarter": { "model": "colore:cube_quarter_horizontal" }, "eighth": { "model": "colore:cube_eighth", "y": 180 } } } }, "half": { "bottom": { }, "top": { "x": 180 } } } } models/block/cube_eighth.json (block model which is literally the vanilla outer_stairs model with the bottom slab shape removed and is used in outer & inner stairs shapes) { "elements": [ { "from": [ 8, 8, 8 ], "to": [ 16, 16, 16 ], "faces": { "down": { "uv": [ 8, 0, 16, 8 ], "texture": "#bottom", "cullface": "down" }, "up": { "uv": [ 8, 8, 16, 16 ], "texture": "#top", "cullface": "up" }, "north": { "uv": [ 0, 0, 8, 8 ], "texture": "#side" }, "south": { "uv": [ 8, 0, 16, 8 ], "texture": "#side", "cullface": "south" }, "west": { "uv": [ 8, 0, 16, 8 ], "texture": "#side" }, "east": { "uv": [ 0, 0, 8, 8 ], "texture": "#side", "cullface": "east" } } } ] } models/block/cube_quarter_horizontal.json (cube_eighth extended in the z direction and used for straight and inner stairs shapes) { "elements": [ { "from": [ 8, 8, 0 ], "to": [ 16, 16, 16 ], "faces": { "down": { "uv": [ 8, 0, 16, 8 ], "texture": "#bottom", "cullface": "down" }, "up": { "uv": [ 8, 8, 16, 16 ], "texture": "#top", "cullface": "up" }, "north": { "uv": [ 0, 0, 8, 8 ], "texture": "#side" }, "south": { "uv": [ 8, 0, 16, 8 ], "texture": "#side", "cullface": "south" }, "west": { "uv": [ 8, 0, 16, 8 ], "texture": "#side" }, "east": { "uv": [ 0, 0, 8, 8 ], "texture": "#side", "cullface": "east" } } } ] }
  14. Found a bug (not sure if it was there before or not): When typing a post, if you try to expand the editor box by dragging the double-lined bar at the bottom, it won't work. The double-diagonal line in the corner does work, however. Not really that big of an issue, but I thought I'd let you know anyway.
  15. Probably never The Java version has some very things that the C++ version does not have: a large modding community. This alone will prevent the C++ version from becoming the 'main' Minecraft version. Until it has a good, functioning modding API with a lot of mods ported, people MIGHT go over the the Windows 10 edition. But all the Linux and Mac players can't, so even then the Java version will be used a lot. Never? Not quickly and not too soon for sure, but "never" is a bit of a strong term, and I can't say I personally agree with it. PE is confirmed to be getting an official mod API, and unlike the Java edition's fabled mod API, I think this one will come much quicker, given the recent speed of MCPE updates and the much larger dev team behind it, not to mention the PE codebase being more clean & optimized than Java MC, which would probably help a lot. I think the modding community would be VERY eager to develop for a MC edition that runs on pretty much everything except the aforementioned Linux & Mac, and has both cleaner/faster code AND an OFFICIAL mod API. And as for Linux & Mac, PE will almost definitely get ported to both at some point, and as for Linux, it's already technically possible thanks to this: https://github.com/MCMrARM/mcpelauncher-linux So it wouldn't be that hard of a port. I think the only reason it hasn't happened yet is that it's not a top priority right now (feature parity is), and also that PE needs an official account system. (And judging by the Realms beta test and Win10 Edition, it looks like Xbox Live may be that system.) The devs have already stated they want Minecraft to run on everything, and so while it may take a while I highly doubt that PE will never be ported to those 2 OSes. So will MCPE become the main edition? Absolutely. Definitely not now (due to the reasons you've stated), but both obstacles are almost definitely going to be overcome at some point or another. But I guess to know for sure, we can only wait, hope, and see...
  16. Liking the new changes so far! (Especially the code syntax highlighting!)
  17. Well, I've played around some more with the Forge blockstates format and figured out how to use "submodel" properly... here is the working blockstates .json for those with similar problems: { "forge_marker": 1, "defaults": { "textures": { "texture": "colore:blocks/block_of_red_normal" }, "model": "fence_post", "uvlock": true }, "variants": { "shade": { "normal": { "textures": { "texture": "colore:blocks/block_of_red_normal" } }, "light": { "textures": { "texture": "colore:blocks/block_of_red_light" } }, "lighter": { "textures": { "texture": "colore:blocks/block_of_red_lighter" } }, "dark": { "textures": { "texture": "colore:blocks/block_of_red_dark" } }, "darker": { "textures": { "texture": "colore:blocks/block_of_red_darker" } } }, "north": { "true": { "submodel": "fence_side" }, "false": { } }, "east": { "true": { "submodel": { "sideeast": { "model": "fence_side", "y": 90 } } }, "false": { } }, "south": { "true": { "submodel": { "sidesouth": { "model": "fence_side", "y": 180 } } }, "false": { } }, "west": { "true": { "submodel": { "sidewest": { "model": "fence_side", "y": 270 } } }, "false": { } } } } Note that "sideeast", "sidesouth", & "sidewest" can be named anything you like and are not named after anything in the code or any other .json. You just have to make sure they all have different names from each other. Also, as you can see with the first use of "submodel", there's a short way of defining a submodel to use if you don't need to rotate it. Using the Forge blockstates format has also made the custom "side" and "post" block model .jsons that I was using unnecessary. The break particles are now working properly, so my fences are now working perfectly! Hopefully my working blockstates .json will provide a good reference example to others confused about using submodels in the Forge blockstates .json format.
  18. Because I couldn't derive from the vanilla fence blockstates .json as it wouldn't work with my fences since they had additonal metadata that vanilla fences don't. I also tried to use the Forge blockstates format but I couldn't figure out how to use "submodel" properly. Is it possible to use multiple conditions (as in if X & Y then use this_model) in the Forge blockstates format similar to the vanilla method?
  19. I don't think you can have empty pairs of quotation marks when registering a recipe. Try removing them.
  20. I've added fences to my mod, and they work almost perfectly, but there is one minor visual problem. When breaking (or after breaking) the fences, the particles that appear are based off of the default variant of the fence, rather than on the variant that's being broken. For example, my fence_of_red (with a "shade" property with the possible values of "normal", "light", "lighter", "dark", and "darker") always uses the "normal" texture for the breaking particles, regardless of what variant is being broken. I have a feeling this has something to do with the fence .json models that I'm using, but I'm not sure how to get it working... BlockColoreFence.java (custom fence class that extends BlockFence) package com.supergeniuszeb.colore.common.blocks; import com.supergeniuszeb.colore.common.init.ModCreativeTabs; import net.minecraft.block.BlockFence; import net.minecraft.block.material.MapColor; import net.minecraft.block.material.Material; import net.minecraft.block.properties.IProperty; import net.minecraft.block.properties.PropertyEnum; import net.minecraft.block.state.BlockStateContainer; import net.minecraft.block.state.IBlockState; import net.minecraft.entity.player.EntityPlayer; import net.minecraft.item.Item; import net.minecraft.item.ItemStack; import net.minecraft.util.IStringSerializable; import net.minecraft.util.math.BlockPos; import net.minecraft.util.math.RayTraceResult; import net.minecraft.world.World; public class BlockColoreFence extends BlockFence implements IBlockName, IBlockSpecialName { public BlockColoreFence(String name, MapColor mapColor) { super(Material.rock, mapColor); this.setHardness(1.5f); this.setHarvestLevel("pickaxe", 0); this.setResistance(10.0f); this.setBlockName(this, name); this.setDefaultState(this.blockState.getBaseState().withProperty(SHADE, EnumType.NORMAL)); this.setCreativeTab(ModCreativeTabs.fenceTab); } public enum EnumType implements IStringSerializable { NORMAL(0, "normal"), LIGHT(1, "light"), LIGHTER(2, "lighter"), DARK(3, "dark"), DARKER(4, "darker"); private int ID; private String name; private EnumType(int ID, String name) { this.ID = ID; this.name = name; } @Override public String getName() { return name; } @Override public String toString() { return getName(); } public int getID() { return ID; } } public static final PropertyEnum SHADE = PropertyEnum.create("shade", BlockColoreFence.EnumType.class); @Override protected BlockStateContainer createBlockState() { return new BlockStateContainer(this, new IProperty[] {SHADE, NORTH, EAST, SOUTH, WEST}); } //Converts an metadata into an IBlockState. @Override public IBlockState getStateFromMeta(int meta) { switch (meta) { case 0: return getDefaultState().withProperty(SHADE, EnumType.NORMAL); case 1: return getDefaultState().withProperty(SHADE, EnumType.LIGHT); case 2: return getDefaultState().withProperty(SHADE, EnumType.LIGHTER); case 3: return getDefaultState().withProperty(SHADE, EnumType.DARK); case 4: return getDefaultState().withProperty(SHADE, EnumType.DARKER); default: return null; } } //Converts an IBlockState into metadata. @Override public int getMetaFromState(IBlockState state) { EnumType shade = (EnumType) state.getValue(SHADE); return shade.getID(); } //So the meta block drops a block with the same metadata when mined. @Override public int damageDropped(IBlockState state) { return getMetaFromState(state); } //Used to get the last part of the unlocalized name for the item-block. //The structure of the unlocalized name is: tile.blockname.specialname.name @Override public String getSpecialName(ItemStack stack) { switch (stack.getItemDamage()) { case 0: return "normal"; case 1: return "light"; case 2: return "lighter"; case 3: return "dark"; case 4: return "darker"; default: return "normal"; } } //This ensures that the pick-block button (normally middle-click) will give //an item-block with the correct metadata. @Override public ItemStack getPickBlock(IBlockState state, RayTraceResult target, World world, BlockPos pos, EntityPlayer player) { return new ItemStack(Item.getItemFromBlock(this), 1, this.getMetaFromState(world.getBlockState(pos))); } } BlockRenders.java (class that handles registration of item-block models) package com.supergeniuszeb.colore.client.render; import com.supergeniuszeb.colore.Reference; import com.supergeniuszeb.colore.common.init.ModBlocks; import com.supergeniuszeb.colore.utility.ModUtilities; import net.minecraft.block.Block; import net.minecraft.client.renderer.block.model.ModelResourceLocation; import net.minecraft.item.Item; import net.minecraft.util.ResourceLocation; import net.minecraftforge.client.model.ModelLoader; import net.minecraftforge.fml.common.registry.ForgeRegistries; //All this handles are the item-block models, not the actual block models, which are //defined in the .json files. public class BlockRenders { //This method is called by the preInit method every time it adds an item-block model without metadata specified. public static void registerRender(Block block) { Item item = Item.getItemFromBlock(block); ModelLoader.setCustomModelResourceLocation(item, 0, new ModelResourceLocation(block.getRegistryName(), "inventory")); } //This method is called by the preInit method every time it adds an item-block model with metadata specified. public static void registerRender(Block block, int meta, String metaName) { Item item = Item.getItemFromBlock(block); ModelLoader.setCustomModelResourceLocation(item, meta, new ModelResourceLocation(block.getRegistryName() + "_" + metaName, "inventory")); } public static void preInit() { int i = 0; for (String shade : ModUtilities.shadeList) { for (String color : ModUtilities.colorList) { for (String blockType : ModUtilities.itemBlockTypeWShadeMetaList) { //standard blocks, half slabs, double slabs, & fences registerRender(ForgeRegistries.BLOCKS.getValue(new ResourceLocation(Reference.MOD_ID, blockType + "_of_" + color)), i, shade); } //stairs registerRender(ForgeRegistries.BLOCKS.getValue(new ResourceLocation(Reference.MOD_ID, "stairs_of_" + color + "_" + shade))); } i++; } i = 0; for (String color : ModUtilities.baseColorList) { //ore blocks registerRender(ModBlocks.essence_ore, i, color); i++; } } public static void init() { } } blockstates/fence_of_red.json { "multipart": [ { "when": { "shade": "normal" }, "apply": { "model": "colore:fence_of_red_normal_post", "uvlock": true } }, { "when": { "shade": "light" }, "apply": { "model": "colore:fence_of_red_light_post", "uvlock": true } }, { "when": { "shade": "lighter" }, "apply": { "model": "colore:fence_of_red_lighter_post", "uvlock": true } }, { "when": { "shade": "dark" }, "apply": { "model": "colore:fence_of_red_dark_post", "uvlock": true } }, { "when": { "shade": "darker" }, "apply": { "model": "colore:fence_of_red_darker_post", "uvlock": true } }, { "when": { "north": "true", "shade": "normal" }, "apply": { "model": "colore:fence_of_red_normal_side", "uvlock": true } }, { "when": { "east": "true", "shade": "normal" }, "apply": { "model": "colore:fence_of_red_normal_side", "y": 90, "uvlock": true } }, { "when": { "south": "true", "shade": "normal" }, "apply": { "model": "colore:fence_of_red_normal_side", "y": 180, "uvlock": true } }, { "when": { "west": "true", "shade": "normal" }, "apply": { "model": "colore:fence_of_red_normal_side", "y": 270, "uvlock": true } }, { "when": { "north": "true", "shade": "light" }, "apply": { "model": "colore:fence_of_red_light_side", "uvlock": true } }, { "when": { "east": "true", "shade": "light" }, "apply": { "model": "colore:fence_of_red_light_side", "y": 90, "uvlock": true } }, { "when": { "south": "true", "shade": "light" }, "apply": { "model": "colore:fence_of_red_light_side", "y": 180, "uvlock": true } }, { "when": { "west": "true", "shade": "light" }, "apply": { "model": "colore:fence_of_red_light_side", "y": 270, "uvlock": true } }, { "when": { "north": "true", "shade": "lighter" }, "apply": { "model": "colore:fence_of_red_lighter_side", "uvlock": true } }, { "when": { "east": "true", "shade": "lighter" }, "apply": { "model": "colore:fence_of_red_lighter_side", "y": 90, "uvlock": true } }, { "when": { "south": "true", "shade": "lighter" }, "apply": { "model": "colore:fence_of_red_lighter_side", "y": 180, "uvlock": true } }, { "when": { "west": "true", "shade": "lighter" }, "apply": { "model": "colore:fence_of_red_lighter_side", "y": 270, "uvlock": true } }, { "when": { "north": "true", "shade": "dark" }, "apply": { "model": "colore:fence_of_red_dark_side", "uvlock": true } }, { "when": { "east": "true", "shade": "dark" }, "apply": { "model": "colore:fence_of_red_dark_side", "y": 90, "uvlock": true } }, { "when": { "south": "true", "shade": "dark" }, "apply": { "model": "colore:fence_of_red_dark_side", "y": 180, "uvlock": true } }, { "when": { "west": "true", "shade": "dark" }, "apply": { "model": "colore:fence_of_red_dark_side", "y": 270, "uvlock": true } }, { "when": { "north": "true", "shade": "darker" }, "apply": { "model": "colore:fence_of_red_darker_side", "uvlock": true } }, { "when": { "east": "true", "shade": "darker" }, "apply": { "model": "colore:fence_of_red_darker_side", "y": 90, "uvlock": true } }, { "when": { "south": "true", "shade": "darker" }, "apply": { "model": "colore:fence_of_red_darker_side", "y": 180, "uvlock": true } }, { "when": { "west": "true", "shade": "darker" }, "apply": { "model": "colore:fence_of_red_darker_side", "y": 270, "uvlock": true } } ] } models/item/fence_of_red_darker.json (item-block model) { "parent": "colore:block/fence_of_red_darker_inventory" } models/block/fence_of_red_darker_inventory.json { "parent": "block/fence_inventory", "textures": { "texture": "colore:blocks/block_of_red_darker" } } models/block/fence_of_red_darker_post.json { "parent": "block/fence_post", "textures": { "texture": "colore:blocks/block_of_red_darker" } } models/block/fence_of_red_darker_side.json { "parent": "block/fence_side", "textures": { "texture": "colore:blocks/block_of_red_darker" } } I've looked in the fence model .jsons, but I'm not sure what's causing the problem... I do know that vanilla fences don't have to worry about metadata since every wood-variant of fence is a separate block altogether. To clarify, there are no error messages of any sort in the Forge logs when I start up the game, and everything else about the fences and their textures/models works flawlessly. It's just the breaking particles that aren't being assigned according to the blockstate. Any ideas? Thanks in advance for your time and help.
  21. It's pretty much at the top of the BlockSlab.java file: public static final PropertyEnum<BlockSlab.EnumBlockHalf> HALF = PropertyEnum.<BlockSlab.EnumBlockHalf>create("half", BlockSlab.EnumBlockHalf.class); protected static final AxisAlignedBB AABB_BOTTOM_HALF = new AxisAlignedBB(0.0D, 0.0D, 0.0D, 1.0D, 0.5D, 1.0D); protected static final AxisAlignedBB AABB_TOP_HALF = new AxisAlignedBB(0.0D, 0.5D, 0.0D, 1.0D, 1.0D, 1.0D); public BlockSlab(Material materialIn) { super(materialIn); this.fullBlock = this.isDouble(); this.setLightOpacity(255); } protected boolean canSilkHarvest() { return false; } public AxisAlignedBB getBoundingBox(IBlockState state, IBlockAccess source, BlockPos pos) { return this.isDouble() ? FULL_BLOCK_AABB : (state.getValue(HALF) == BlockSlab.EnumBlockHalf.TOP ? AABB_TOP_HALF : AABB_BOTTOM_HALF); } I would think that all you would have to do to change the bounding box of a block to be like a slab would be to create an AxisAlignedBB with the same params as AABB_BOTTOM_HALF and use that in your own block class by overriding the vanilla getBoundingBox method. It would look something like this: protected static final AxisAlignedBB CUSTOM_BLOCK_AABB = new AxisAlignedBB(0.0D, 0.0D, 0.0D, 1.0D, 0.5D, 1.0D); public AxisAlignedBB getBoundingBox(IBlockState state, IBlockAccess source, BlockPos pos) { return CUSTOM_BLOCK_AABB; } The 6 numbers represent the xyz coordinates within the shape of a full cube for 2 corners which can be used to define any given rectangular/cubic shape. (See the AxisAlignedBB constructor.) The values used are doubles, not integers, hence the Ds at the end of the numbers. 1.0 is the full length from one end of a standard Minecraft cube to the other. As you can see, the bottom half slab's shape is defined by a corner at x=0.0, y=0.0, z=0.0 and a corner at x=1.0, y=0.5, z=1.0. Stairs (and various other blocks) are actually made of several bounding boxes combined. I'm assuming that you're only trying to create a block that has the shape of a half slab, and not an actual "slab", complete with all the slab properties like stacking into double slabs, having the ability to be placed in either the top or bottom half of a block, and dropping 2 slabs when broken as a double slab. If you are, I recommend doing some research on metadata and blockstates if you haven't already, as a good understanding of those will make modding a whole lot easier, and you should also take a look at the BlockSlab, BlockSlabHalf, BlockSlabDouble, and ItemSlab classes for a complete understanding of how they work. So basically, go look at the slab classes again because one of the first things in the BlockSlab class is the answer to your question.
  22. I have now released the 1.1 update for 1.9! I've also released a bugfix update, 1.1.1, for the 1.9 version, so download that instead of 1.1 if you're playing on 1.9. The 1.9 port of 1.1 is virtually identical to the 1.8.9 version, except that the armor now has sounds for when you equip it. The armor and tools all have the default cooldown times and are currently unchanged from 1.8/1.8.9. I may release another update with some rebalancing of the tools/armor for 1.9 after I've played around with it for a while, or I may just include that in the 1.2 update. 1.1.1 was created to fix a bug where loading a world previously created with 1.8.9 would cause all existing Colore slab items to be deleted. (Keep in mind that because of this fix, loading worlds created with 1.1 for 1.9 will have all their slab items deleted if updated to 1.1.1, so I made sure to get this update out as soon as I could when I discovered the bug.) I've also cleaned up & optimized some code again, and I've removed double slab items. They were unnecessary, vanilla slabs don't have them, and they were causing problems like crashing the game when you tried to place them.
  23. Optimized C++ Minecraft already exists... it's called Minecraft: Pocket/Gear VR/Windows 10 Edition. It's C++, it's super-optimized, and is probably the future "main" Minecraft edition anyway. It doesn't have feature parity with Java Minecraft yet, but at the rate it gets updates it probably will within a couple of years. (I bet it will also get an official mod API before Java Minecraft as well... )
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.