I am making a coal block mod and I was wondering how do you apply flammable properties settings? I don't understand how to do that. I have looked for hours and I quit. I want a modder to explain to me in terms I can understand how do you apply the block property flammable settings: flammable , fire can spread, burning time before block is removed and I also want it to be = to a coal block. Yes I have tried messing with materials. I changed it to wood and nothing happened. I tried importing both the fire functions and the coal block please help.
Either override the methods GotoLink posted to return constant spread speed/flammability values (look at BlockFire.func_149843_e to see the values used by vanilla blocks) or call BlockFire#setFireInfo after registering the block to set the values. See this commit for examples.
Rollback Post to RevisionRollBack
Chisel Facades: For all your decorative pipe-hiding needs.
Please don't PM me to ask for help or to join your mod development team. Asking your question in a public thread preserves it for people who are having the same problem in the future. I'm not interested in developing mods with people.
I simply replaced the entire BlockFire class with my own edited version, BlockFireFix - this is what makes MCP vastly superior to Forge, given how often I see threads asking how to do something that is as trivial as editing a single line of code, and this is a major reason why I never learned how to use it (a proper mod API would expose absolutely everything with no need for reflection/ASM or any of that nonsense):
public class BlockFireFix extends BlockFire
{
private final byte[] chanceToEncourageFire = new byte[256];
private final byte[] chanceToCatchFire = new byte[256];
protected BlockFireFix(int par1)
{
super(par1);
}
public void initializeBlock()
{
this.setBurnRate(Block.planks.blockID, 5, 20);
this.setBurnRate(Block.woodDoubleSlab.blockID, 5, 20);
this.setBurnRate(Block.woodSingleSlab.blockID, 5, 20);
this.setBurnRate(Block.fence.blockID, 5, 20);
this.setBurnRate(Block.stairsWoodOak.blockID, 5, 20);
this.setBurnRate(Block.stairsWoodBirch.blockID, 5, 20);
this.setBurnRate(Block.stairsWoodSpruce.blockID, 5, 20);
this.setBurnRate(Block.stairsWoodJungle.blockID, 5, 20);
this.setBurnRate(Block.wood.blockID, 5, 5);
this.setBurnRate(Block.leaves.blockID, 30, 60);
this.setBurnRate(Block.bookShelf.blockID, 30, 20);
this.setBurnRate(Block.tnt.blockID, 15, 100);
this.setBurnRate(Block.tallGrass.blockID, 60, 100);
this.setBurnRate(Block.cloth.blockID, 30, 60);
this.setBurnRate(Block.vine.blockID, 15, 100);
this.setBurnRate(Block.coalBlock.blockID, 5, 5);
this.setBurnRate(Block.hay.blockID, 60, 20);
// Added new flammable blocks
this.setBurnRate(Block.fenceGate.blockID, 5, 20);
this.setBurnRate(Block.plantYellow.blockID, 60, 100);
this.setBurnRate(Block.plantRed.blockID, 60, 100);
this.setBurnRate(Block.doublePlant.blockID, 60, 100);
this.setBurnRate(Block.deadBush.blockID, 60, 100);
this.setBurnRate(Block.carpet.blockID, 60, 20);
this.setBurnRate(Block.sapling.blockID, 60, 100);
this.setBurnRate(Block.sapling2.blockID, 60, 100);
this.setBurnRate(Block.leaves2.blockID, 30, 60);
this.setBurnRate(Block.leaves3.blockID, 30, 60);
}
public void updateTick(World par1World, int posX, int posY, int posZ, Random par5Random)
{
// Added check for loaded chunks to fix MC-119994
if (par1World.getGameRules().getGameRuleBooleanValue("doFireTick") && par1World.doChunksNearBlockExist(posX, posZ, 16))
{
int block = par1World.getBlockId(posX, posY - 1, posZ);
// Added Nether quartz ore, Nether gold ore, and magma blocks as a permanent fire sustaining
// block
boolean isFirePermanent = (block == Block.netherrack.blockID || block == Block.oreNetherQuartz.blockID || block == Block.magmaBlock.blockID || (block == Block.oreGold.blockID && par1World.getBlockMetadata(posX, posY - 1, posZ) == BlockMetadataOre.NETHERRACK));
if (block == Block.bedrock.blockID && par1World.provider instanceof WorldProviderEnd) isFirePermanent = true;
. . .
// Halves update rate for permanent fires
meta = 30 + par5Random.nextInt(10);
if (isFirePermanent) meta *= 2;
par1World.scheduleBlockUpdate(posX, posY, posZ, this.blockID, meta);
}
}
I simply replaced the entire BlockFire class with my own edited version, BlockFireFix - this is what makes MCP vastly superior to Forge, given how often I see threads asking how to do something that is as trivial as editing a single line of code, and this is a major reason why I never learned how to use it (a proper mod API would expose absolutely everything with no need for reflection/ASM or any of that nonsense):
public class BlockFireFix extends BlockFire
{
private final byte[] chanceToEncourageFire = new byte[256];
private final byte[] chanceToCatchFire = new byte[256];
protected BlockFireFix(int par1)
{
super(par1);
}
public void initializeBlock()
{
this.setBurnRate(Block.planks.blockID, 5, 20);
this.setBurnRate(Block.woodDoubleSlab.blockID, 5, 20);
this.setBurnRate(Block.woodSingleSlab.blockID, 5, 20);
this.setBurnRate(Block.fence.blockID, 5, 20);
this.setBurnRate(Block.stairsWoodOak.blockID, 5, 20);
this.setBurnRate(Block.stairsWoodBirch.blockID, 5, 20);
this.setBurnRate(Block.stairsWoodSpruce.blockID, 5, 20);
this.setBurnRate(Block.stairsWoodJungle.blockID, 5, 20);
this.setBurnRate(Block.wood.blockID, 5, 5);
this.setBurnRate(Block.leaves.blockID, 30, 60);
this.setBurnRate(Block.bookShelf.blockID, 30, 20);
this.setBurnRate(Block.tnt.blockID, 15, 100);
this.setBurnRate(Block.tallGrass.blockID, 60, 100);
this.setBurnRate(Block.cloth.blockID, 30, 60);
this.setBurnRate(Block.vine.blockID, 15, 100);
this.setBurnRate(Block.coalBlock.blockID, 5, 5);
this.setBurnRate(Block.hay.blockID, 60, 20);
// Added new flammable blocks
this.setBurnRate(Block.fenceGate.blockID, 5, 20);
this.setBurnRate(Block.plantYellow.blockID, 60, 100);
this.setBurnRate(Block.plantRed.blockID, 60, 100);
this.setBurnRate(Block.doublePlant.blockID, 60, 100);
this.setBurnRate(Block.deadBush.blockID, 60, 100);
this.setBurnRate(Block.carpet.blockID, 60, 20);
this.setBurnRate(Block.sapling.blockID, 60, 100);
this.setBurnRate(Block.sapling2.blockID, 60, 100);
this.setBurnRate(Block.leaves2.blockID, 30, 60);
this.setBurnRate(Block.leaves3.blockID, 30, 60);
}
public void updateTick(World par1World, int posX, int posY, int posZ, Random par5Random)
{
// Added check for loaded chunks to fix MC-119994
if (par1World.getGameRules().getGameRuleBooleanValue("doFireTick") && par1World.doChunksNearBlockExist(posX, posZ, 16))
{
int block = par1World.getBlockId(posX, posY - 1, posZ);
// Added Nether quartz ore, Nether gold ore, and magma blocks as a permanent fire sustaining
// block
boolean isFirePermanent = (block == Block.netherrack.blockID || block == Block.oreNetherQuartz.blockID || block == Block.magmaBlock.blockID || (block == Block.oreGold.blockID && par1World.getBlockMetadata(posX, posY - 1, posZ) == BlockMetadataOre.NETHERRACK));
if (block == Block.bedrock.blockID && par1World.provider instanceof WorldProviderEnd) isFirePermanent = true;
. . .
// Halves update rate for permanent fires
meta = 30 + par5Random.nextInt(10);
if (isFirePermanent) meta *= 2;
par1World.scheduleBlockUpdate(posX, posY, posZ, this.blockID, meta);
}
}
Only allowing 256 blocks for a modding environment is a no! Second not only is the size of the array wrong blocks should be stored as integers. Use dynamic arrays!
Also I know forge was messing up with their patch in some versions for the fire blocks. This won't be the case for jredfox mod loader - mc api
Only allowing 256 blocks for a modding environment is a no! Second not only is the size of the array wrong blocks should be stored as integers. Use dynamic arrays!
Also I know forge was messing up with their patch in some versions for the fire blocks. This won't be the case for jredfox mod loader - mc api
Vanilla 1.6.4 only allows for 256 blocks without significant modifications to allow blocks to use IDs above 255 (as items use IDs starting at 256 and ItemStack and other code only distinguishes between block/items by their ID), I even removed the limited support it had for 4096 block IDs as an optimization to get rid of unnecessary code so it is impossible for a block ID to ever go out of bounds (256 IDs is more than enough when most of the new "blocks" I've added are variants of existing blocks and I never see myself using all of them up, nor is TMCW your usual mod, even as a non-Forge jar mod - it is literally a separate branch of development with extremely extensive modifications (I've since combined what was EntityRenderer and RenderGlobal into a single class, as IMO they should have been due to how much they reference each other) to dozens of core vanilla classes, probably as different as, say 1.16 is). Also, I prefer simple/fast code over "good programming practices", like the sort Mojang does:
The general trend is that the developers do not care that much about memory allocation and use "best industry practices" without understanding the consequences.
The old Notch code was straightforward and relatively easy to follow. The new rendering system is an over-engineered monster full of factories, builders, bakeries, baked items, managers, dispatchers, states, enums and layers. Object allocation is rampant, small objects are allocated like there is no tomorrow. No wonder that the garbage collector has to work so hard.
Also, this is the code from vanilla 1.6.4, which my class is based on, the only difference is that the arrays are ints instead of bytes (none of the values will ever exceed 100 so there is no need to use ints, and this helps reduce the memory overhead of having to extend the vanilla class to maintain compatibility with vanilla code that references Block.fire, I found if I just replaced the entire class MCP would reobfuscate a whole bunch of extra classes which referenced it since the reference to Block.fire changed):
public class BlockFire extends Block
{
/** The chance this block will encourage nearby blocks to catch on fire */
private int[] chanceToEncourageFire = new int[256];
/**
* This is an array indexed by block ID the larger the number in the array the more likely a block type will catch
* fires
*/
private int[] abilityToCatchFire = new int[256];
// Note that the game casts to BlockFire, hence why I had to extend BlockFire instead of Block, as I do in most cases (most blocks are cast to the Block base class, e.g. "Block stone = ..." so the whole class can be completely replaced, I even delete the original classes to ensure nothing references it)
// Vanilla code
public static final BlockFire fire = (BlockFire)(new BlockFire(51)).setHardness(0.0F).setLightValue(1.0F).setStepSound(soundWoodFootstep).setUnlocalizedName("fire").disableStats().setTextureName("fire");
// Modified code
public static final BlockFire fire = (BlockFire)(new BlockFireFix(51)).setHardness(0.0F).setStepSound(soundWoodFootstep).setUnlocalizedName("fire").disableStats().setTextureName("fire");
// Another example where I completely replaced the original class
public static final Block oreGold = (new BlockOre(14)).setHardness(3.0F).setResistance(5.0F).setStepSound(soundStoneFootstep).setUnlocalizedName("oreGold").setTextureName("gold_ore");
public static final Block oreGold = (new BlockMetadataOre(14, BlockMetadataOre.GOLD)).setHardness(3.0F).setResistance(5.0F).setStepSound(soundStoneFootstep).setUnlocalizedName("oreGold").setTextureName("gold_ore_overlay");
Try getting this performance in a modern version - those are truly huge trees, vastly larger than a jungle, yet I get 375 FPS, 3 ms server tick time, and 256 MB used memory at maximum settings (16 chunks, Fancy), which is far better than what I've seen others getting in the latest versions on much more powerful hardware (and no, I have made no optimizations that enable the game to make better use of more cores, a single thread each for the client/server, and rendering is all OpenGL 1.1-1.2, the same as vanilla 1.6.4 (check the system requirements from back then!), so no VBOs or anything that might perform better, the code only uses Java 6 features since that is what MCP is set to compile to and I've never needed to change it. Worlds also generate in a couple seconds despite no multithreaded worldgen like in 1.13, and the game loads just as quickly, even with more textures to load - no need for fancy loading screens):
I've even completely changed vanilla block IDs as well as various NBT data (for example, I combined red and brown mushrooms into a single block, along with more variants; redstone torches and lamps are likewise a single block, with the data value determining whether it is on or off - my custom lighting engine is able to use data values so they can determine the light level (vanilla uses a lookup table indexed by block ID while I added a method with a metadata parameter), same for many other block properties, for example, amethyst ore is actually obsidian and the hardness is different, even for diamond vs amethyst tools, the latter of which mine it faster than the raw tool speed would suggest). Because of this, I effectively have 4096 blocks to play with without having to modify the game to actually make use of more block IDs, which I just use to group common blocks together (e.g. all fences are a single block ID so anything that refers to them such as torch placement or the fence rendering code, only needs to check for a single block ID, including unmodified vanilla code).
Meanwhile, Mojang acted like there were infinite block IDs, even doing crazy things like making every color of shulker box a separate block instead of using NBT data (they were already a tile entity, which could also allow for infinite colors in custom NBT data, much as I made flower pots a tile entity with literally infinite variations on what they can render, even including miniature trees with the same variation of full-size trees. Some of my other blocks have 100+ variants without even using a tile entity; stalagmites just use the block they are on, such as stained clay, to determine how they render with only 6 real variants). This is also probably a big reason why vanilla is so slow, 1.13+ has thousands of different blocks now, and complicated registry-based hashmap lookups instead of simple ID-based tables:
I noticed in 1.12.x that getBlockState (in World, Chunk, and ChunkCache) accounted for substantial amount of CPU overhead. I developed a block state cache (write-through direct-mapped cache using a specially tuned hash to map from coordinates to cache entries), which made a HUGE difference. That plus a BlockPos neighbor cache literally doubled Minecraft performance for the test cases we tried.
In 1.13, I knew that getBlockState was going to get more expensive, at lease because of the extra liquid layer, but I had my concerns about block numbers being fully abstracted (the flattening and all that). This was a performance problem for 1.12.x. It's going to be really serious in 1.13.
Likewise, my biome generator would probably horrify you, I use arrays indexed by biome ID and/or a "sub-biome" index to store the sub-biome variations, replacing huge if-else chains in vanilla, yet it is 180 times faster than 1.13 if the data on this page is any indication, taking about 200 ms to generate the same area with my own biome mapping tool (assuming the same system specs but there is absolutely no way my system is that much faster, even my old computer had 1/4 the single-thread performance of the fastest CPUs. While using a lookup table does have some overhead I've found it is faster than an if-else if there are more than a few cases involved, and the code that uses it can be much simpler - a single lookup and check for a sub-biome vs a huge if-else for every biome).
Vanilla 1.6.4 only allows for 256 blocks without significant modifications to allow blocks to use IDs above 255 (as items use IDs starting at 256 and ItemStack and other code only distinguishes between block/items by their ID), I even removed the limited support it had for 4096 block IDs as an optimization to get rid of unnecessary code so it is impossible for a block ID to ever go out of bounds (256 IDs is more than enough when most of the new "blocks" I've added are variants of existing blocks and I never see myself using all of them up, nor is TMCW your usual mod, even as a non-Forge jar mod - it is literally a separate branch of development with extremely extensive modifications (I've since combined what was EntityRenderer and RenderGlobal into a single class, as IMO they should have been due to how much they reference each other) to dozens of core vanilla classes, probably as different as, say 1.16 is). Also, I prefer simple/fast code over "good programming practices", like the sort Mojang does:
Also, this is the code from vanilla 1.6.4, which my class is based on, the only difference is that the arrays are ints instead of bytes (none of the values will ever exceed 100 so there is no need to use ints, and this helps reduce the memory overhead of having to extend the vanilla class to maintain compatibility with vanilla code that references Block.fire, I found if I just replaced the entire class MCP would reobfuscate a whole bunch of extra classes which referenced it since the reference to Block.fire changed):
public class BlockFire extends Block
{
/** The chance this block will encourage nearby blocks to catch on fire */
private int[] chanceToEncourageFire = new int[256];
/**
* This is an array indexed by block ID the larger the number in the array the more likely a block type will catch
* fires
*/
private int[] abilityToCatchFire = new int[256];
// Note that the game casts to BlockFire, hence why I had to extend BlockFire instead of Block, as I do in most cases (most blocks are cast to the Block base class, e.g. "Block stone = ..." so the whole class can be completely replaced, I even delete the original classes to ensure nothing references it)
// Vanilla code
public static final BlockFire fire = (BlockFire)(new BlockFire(51)).setHardness(0.0F).setLightValue(1.0F).setStepSound(soundWoodFootstep).setUnlocalizedName("fire").disableStats().setTextureName("fire");
// Modified code
public static final BlockFire fire = (BlockFire)(new BlockFireFix(51)).setHardness(0.0F).setStepSound(soundWoodFootstep).setUnlocalizedName("fire").disableStats().setTextureName("fire");
// Another example where I completely replaced the original class
public static final Block oreGold = (new BlockOre(14)).setHardness(3.0F).setResistance(5.0F).setStepSound(soundStoneFootstep).setUnlocalizedName("oreGold").setTextureName("gold_ore");
public static final Block oreGold = (new BlockMetadataOre(14, BlockMetadataOre.GOLD)).setHardness(3.0F).setResistance(5.0F).setStepSound(soundStoneFootstep).setUnlocalizedName("oreGold").setTextureName("gold_ore_overlay");
Try getting this performance in a modern version - those are truly huge trees, vastly larger than a jungle, yet I get 375 FPS, 3 ms server tick time, and 256 MB used memory at maximum settings (16 chunks, Fancy), which is far better than what I've seen others getting in the latest versions on much more powerful hardware (and no, I have made no optimizations that enable the game to make better use of more cores, a single thread each for the client/server, and rendering is all OpenGL 1.1-1.2, the same as vanilla 1.6.4 (check the system requirements from back then!), so no VBOs or anything that might perform better, the code only uses Java 6 features since that is what MCP is set to compile to and I've never needed to change it. Worlds also generate in a couple seconds despite no multithreaded worldgen like in 1.13, and the game loads just as quickly, even with more textures to load - no need for fancy loading screens):
I've even completely changed vanilla block IDs as well as various NBT data (for example, I combined red and brown mushrooms into a single block, along with more variants; redstone torches and lamps are likewise a single block, with the data value determining whether it is on or off - my custom lighting engine is able to use data values so they can determine the light level (vanilla uses a lookup table indexed by block ID while I added a method with a metadata parameter), same for many other block properties, for example, amethyst ore is actually obsidian and the hardness is different, even for diamond vs amethyst tools, the latter of which mine it faster than the raw tool speed would suggest). Because of this, I effectively have 4096 blocks to play with without having to modify the game to actually make use of more block IDs, which I just use to group common blocks together (e.g. all fences are a single block ID so anything that refers to them such as torch placement or the fence rendering code, only needs to check for a single block ID, including unmodified vanilla code).
Meanwhile, Mojang acted like there were infinite block IDs, even doing crazy things like making every color of shulker box a separate block instead of using NBT data (they were already a tile entity, which could also allow for infinite colors in custom NBT data, much as I made flower pots a tile entity with literally infinite variations on what they can render, even including miniature trees with the same variation of full-size trees. Some of my other blocks have 100+ variants without even using a tile entity; stalagmites just use the block they are on, such as stained clay, to determine how they render with only 6 real variants). This is also probably a big reason why vanilla is so slow, 1.13+ has thousands of different blocks now, and complicated registry-based hashmap lookups instead of simple ID-based tables:
Likewise, my biome generator would probably horrify you, I use arrays indexed by biome ID and/or a "sub-biome" index to store the sub-biome variations, replacing huge if-else chains in vanilla, yet it is 180 times faster than 1.13 if the data on this page is any indication, taking about 200 ms to generate the same area with my own biome mapping tool (assuming the same system specs but there is absolutely no way my system is that much faster, even my old computer had 1/4 the single-thread performance of the fastest CPUs. While using a lookup table does have some overhead I've found it is faster than an if-else if there are more than a few cases involved, and the code that uses it can be much simpler - a single lookup and check for a sub-biome vs a huge if-else for every biome).
again no. The block ids were not 256 in vanilla they were 4096 or something weird. Hard coding arrays like that is a no no in any language.
My mod loader will be using the 1.6.4 codebase heavily modified. Minecraft uses lwjgl which isn't very over engineered. I agree they differently did something wrong when trying to convert java models into more optimized process. Plan is to get DTS 7.1 Adobe and OpenGl 4.6 into minecraft. I am not an expert but, I know paulscode was just a work around for when java 5-6 sound apis were broken and possibly even OpenAL which is in lwjgl now.
again no. The block ids were not 256 in vanilla they were 4096 or something weird. Hard coding arrays like that is a no no in any language.
My mod loader will be using the 1.6.4 codebase heavily modified. Minecraft uses lwjgl which isn't very over engineered. I agree they differently did something wrong when trying to convert java models into more optimized process. Plan is to get DTS 7.1 Adobe and OpenGl 4.6 into minecraft. I am not an expert but, I know paulscode was just a work around for when java 5-6 sound apis were broken and possibly even OpenAL which is in lwjgl now.
No, vanilla 1.6.4 does not have full internal support for block IDs above 255 so it may as well be the same thing. For example:
for (int var0 = 0; var0 < 256; ++var0)
{
if (blocksList[var0] != null)
{
if (Item.itemsList[var0] == null)
{
Item.itemsList[var0] = new ItemBlock(var0 - 256);
blocksList[var0].initializeBlock();
}
protected Item(int par1)
{
this.itemID = 256 + par1;
public class EntityEnderman extends EntityMob
{
private static boolean[] carriableBlocks = new boolean[256];
(etc)
In other words, vanilla only initializes blocks with IDs of 0-255 and items have IDs starting at 256 (the constructor is called with values starting at 0; e.g. the item ID for an iron shovel is 256 but 0 is passed to the constructor), and any slots already occupied by items won't be overwritten (e.g. a block with an ID of 256 will be an iron shovel in item form), and elsewhere it doesn't even consider the possibility of higher IDs (e.g. giving an Enderman a block ID of 256+ using an NBT editor will crash the game). Also, I even removed the support for block IDs above 255 so you can't even ever go out of bounds unless you did something silly like setBlock(x, y, z, 256), and even then the game stores block IDs as bytes so it just wraps back around to 0. Sure, this can corrupt worlds but why would you try loading a modded world in a completely different modded version (as vanilla worlds will never have IDs above 255) but loading a modded world in vanilla will delete blocks as well and it still wouldn't be as bad as what current vanilla versions do (at least, when downgrading, even by a single version, all loaded chunks are nuked; IMO, Mojang really needs to (like years ago) make it so that worlds can only be loaded in the last version it was played on or newer).
Also, I only do this because I didn't want to have to replace/modify/add a bunch of new classes for just the purpose of adding a methods to properly get/set their flammability properties (as I've done in many other cases, including my own code; for example, vanilla uses an array indexed by block ID to store the light level of a block - I got rid of that entirely and instead use a method which accepts a data value, enabling blocks to have different light levels for each data value, if at the cost of a bit of extra code as I have to make sure that the block isn't air (a null check would be better but is is guaranteed that there will never be an invalid block ID unless there is memory corruption or something; the chunk loading code also removes any invalid blocks present in the save data. Also, if null is never encountered the JVM can optimize out the null check it would do anyway to catch NPEs):
int var5 = this.getBlockId(par1, par2, par3);
int var6 = par4EnumSkyBlock == EnumSkyBlock.Sky ? 0 : Block.lightValue[var5];
int var7 = Block.lightOpacity[var5];
if (var7 >= 15 && Block.lightValue[var5] > 0) var7 = 1;
if (var7 < 1) var7 = 1;
if (var7 >= 15)
{
return 0;
}
else if (var6 >= 14)
{
return var6;
}
// TMCW
int block = this.getBlockState(x, y, z);
int lightValue;
int opacity;
if ((block & 255) > 0)
{
// Enables data values to affect light value (e.g. empty mob spawners)
lightValue = Block.blocksList[block & 255].getLightValue(block >> 8);
if (lightValue >= 14) return lightValue;
opacity = clampedLightOpacity[block & 255];
// Prevents solid blocks like glowing redstone ore from passing a higher light level through,
// as well as "saving" it
if (opacity >= 15) return lightValue;
}
else
{
lightValue = 0;
opacity = 1;
}
(getBlockState() is my own version of a "block state"; data value << 8 | block ID, enabling in this case a single chunk/block lookup to be done instead of separately looking up the ID and data value; I even use a local chunk cache to speed up access as much as possible (including other optimizations light updates are so much faster that world generation time decreased by 3-fold in a Mega Forest; a bunch of pistons moving blocks over holes in a high ceiling went from unplayably laggy to mild stutters). Block.blocksList is from vanilla, an array indexed by block ID (4096 in vanilla, 256 in TMCW), while clampedLightOpacity[] is the same as vanilla's Block.lightOpacity except values are clamped to a minimum of 1 to avoid having to check for 0)
Otherwise, you have to remember that my code is not designed with any support for mods in mind (even Optifine is not compatible, it may not even do anything if TMCW is installed after it as its own classes are overwritten or even completely bypassed, e.g. it modifies RenderGlobal and EntityRenderer, both of which were completely replaced with my own class; RenderBlocks and ItemRenderer are now simple wrappers whose methods are redirected to my own classes to maintain compatibility with vanilla code, and so on) so I don't need to worry about handling anything that isn't already in the game (i.e. mod blocks registering themselves).
I am making a coal block mod and I was wondering how do you apply flammable properties settings? I don't understand how to do that. I have looked for hours and I quit. I want a modder to explain to me in terms I can understand how do you apply the block property flammable settings: flammable , fire can spread, burning time before block is removed and I also want it to be = to a coal block. Yes I have tried messing with materials. I changed it to wood and nothing happened. I tried importing both the fire functions and the coal block please help.
Here is the answer by Choonster
https://github.com/Choonster/TestMod2/commit/3f225404a8c40b64177472a40357131a668ed83d
See those methods in Block class related to fire:
#getFireSpreadSpeed
#getFlammability
Override them in your block class.
it then errors because, I don't know what numbers to use (world x y z face)
I have even went into vanilla code and tried to use that . a video would be helpful.
doesn't seem to work somebody else help who knows what they are doing.
Either override the methods GotoLink posted to return constant spread speed/flammability values (look at BlockFire.func_149843_e to see the values used by vanilla blocks) or call BlockFire#setFireInfo after registering the block to set the values. See this commit for examples.
Chisel Facades: For all your decorative pipe-hiding needs.
Please don't PM me to ask for help or to join your mod development team. Asking your question in a public thread preserves it for people who are having the same problem in the future. I'm not interested in developing mods with people.
Thank you. My Charcoal Block mod now has burnable charcoal blocks.
Actualy there is an mod "Mo burnables" on 1.7.10 that can do this already. U just need to write 2 lines of code in JSON.
But when i look at date of last post here, I dont think so there is still somebody wondering about...
no you use Blocks.FIRE.something to make them flamable you can use the func_ but, they won't work past 1.7.10
I simply replaced the entire BlockFire class with my own edited version, BlockFireFix - this is what makes MCP vastly superior to Forge, given how often I see threads asking how to do something that is as trivial as editing a single line of code, and this is a major reason why I never learned how to use it (a proper mod API would expose absolutely everything with no need for reflection/ASM or any of that nonsense):
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
Only allowing 256 blocks for a modding environment is a no! Second not only is the size of the array wrong blocks should be stored as integers. Use dynamic arrays!
Also I know forge was messing up with their patch in some versions for the fire blocks. This won't be the case for jredfox mod loader - mc api
Vanilla 1.6.4 only allows for 256 blocks without significant modifications to allow blocks to use IDs above 255 (as items use IDs starting at 256 and ItemStack and other code only distinguishes between block/items by their ID), I even removed the limited support it had for 4096 block IDs as an optimization to get rid of unnecessary code so it is impossible for a block ID to ever go out of bounds (256 IDs is more than enough when most of the new "blocks" I've added are variants of existing blocks and I never see myself using all of them up, nor is TMCW your usual mod, even as a non-Forge jar mod - it is literally a separate branch of development with extremely extensive modifications (I've since combined what was EntityRenderer and RenderGlobal into a single class, as IMO they should have been due to how much they reference each other) to dozens of core vanilla classes, probably as different as, say 1.16 is). Also, I prefer simple/fast code over "good programming practices", like the sort Mojang does:
Also, this is the code from vanilla 1.6.4, which my class is based on, the only difference is that the arrays are ints instead of bytes (none of the values will ever exceed 100 so there is no need to use ints, and this helps reduce the memory overhead of having to extend the vanilla class to maintain compatibility with vanilla code that references Block.fire, I found if I just replaced the entire class MCP would reobfuscate a whole bunch of extra classes which referenced it since the reference to Block.fire changed):
Try getting this performance in a modern version - those are truly huge trees, vastly larger than a jungle, yet I get 375 FPS, 3 ms server tick time, and 256 MB used memory at maximum settings (16 chunks, Fancy), which is far better than what I've seen others getting in the latest versions on much more powerful hardware (and no, I have made no optimizations that enable the game to make better use of more cores, a single thread each for the client/server, and rendering is all OpenGL 1.1-1.2, the same as vanilla 1.6.4 (check the system requirements from back then!), so no VBOs or anything that might perform better, the code only uses Java 6 features since that is what MCP is set to compile to and I've never needed to change it. Worlds also generate in a couple seconds despite no multithreaded worldgen like in 1.13, and the game loads just as quickly, even with more textures to load - no need for fancy loading screens):
I've even completely changed vanilla block IDs as well as various NBT data (for example, I combined red and brown mushrooms into a single block, along with more variants; redstone torches and lamps are likewise a single block, with the data value determining whether it is on or off - my custom lighting engine is able to use data values so they can determine the light level (vanilla uses a lookup table indexed by block ID while I added a method with a metadata parameter), same for many other block properties, for example, amethyst ore is actually obsidian and the hardness is different, even for diamond vs amethyst tools, the latter of which mine it faster than the raw tool speed would suggest). Because of this, I effectively have 4096 blocks to play with without having to modify the game to actually make use of more block IDs, which I just use to group common blocks together (e.g. all fences are a single block ID so anything that refers to them such as torch placement or the fence rendering code, only needs to check for a single block ID, including unmodified vanilla code).
Meanwhile, Mojang acted like there were infinite block IDs, even doing crazy things like making every color of shulker box a separate block instead of using NBT data (they were already a tile entity, which could also allow for infinite colors in custom NBT data, much as I made flower pots a tile entity with literally infinite variations on what they can render, even including miniature trees with the same variation of full-size trees. Some of my other blocks have 100+ variants without even using a tile entity; stalagmites just use the block they are on, such as stained clay, to determine how they render with only 6 real variants). This is also probably a big reason why vanilla is so slow, 1.13+ has thousands of different blocks now, and complicated registry-based hashmap lookups instead of simple ID-based tables:
Likewise, my biome generator would probably horrify you, I use arrays indexed by biome ID and/or a "sub-biome" index to store the sub-biome variations, replacing huge if-else chains in vanilla, yet it is 180 times faster than 1.13 if the data on this page is any indication, taking about 200 ms to generate the same area with my own biome mapping tool (assuming the same system specs but there is absolutely no way my system is that much faster, even my old computer had 1/4 the single-thread performance of the fastest CPUs. While using a lookup table does have some overhead I've found it is faster than an if-else if there are more than a few cases involved, and the code that uses it can be much simpler - a single lookup and check for a sub-biome vs a huge if-else for every biome).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
again no. The block ids were not 256 in vanilla they were 4096 or something weird. Hard coding arrays like that is a no no in any language.
My mod loader will be using the 1.6.4 codebase heavily modified. Minecraft uses lwjgl which isn't very over engineered. I agree they differently did something wrong when trying to convert java models into more optimized process. Plan is to get DTS 7.1 Adobe and OpenGl 4.6 into minecraft. I am not an expert but, I know paulscode was just a work around for when java 5-6 sound apis were broken and possibly even OpenAL which is in lwjgl now.
No, vanilla 1.6.4 does not have full internal support for block IDs above 255 so it may as well be the same thing. For example:
In other words, vanilla only initializes blocks with IDs of 0-255 and items have IDs starting at 256 (the constructor is called with values starting at 0; e.g. the item ID for an iron shovel is 256 but 0 is passed to the constructor), and any slots already occupied by items won't be overwritten (e.g. a block with an ID of 256 will be an iron shovel in item form), and elsewhere it doesn't even consider the possibility of higher IDs (e.g. giving an Enderman a block ID of 256+ using an NBT editor will crash the game). Also, I even removed the support for block IDs above 255 so you can't even ever go out of bounds unless you did something silly like setBlock(x, y, z, 256), and even then the game stores block IDs as bytes so it just wraps back around to 0. Sure, this can corrupt worlds but why would you try loading a modded world in a completely different modded version (as vanilla worlds will never have IDs above 255) but loading a modded world in vanilla will delete blocks as well and it still wouldn't be as bad as what current vanilla versions do (at least, when downgrading, even by a single version, all loaded chunks are nuked; IMO, Mojang really needs to (like years ago) make it so that worlds can only be loaded in the last version it was played on or newer).
Also, I only do this because I didn't want to have to replace/modify/add a bunch of new classes for just the purpose of adding a methods to properly get/set their flammability properties (as I've done in many other cases, including my own code; for example, vanilla uses an array indexed by block ID to store the light level of a block - I got rid of that entirely and instead use a method which accepts a data value, enabling blocks to have different light levels for each data value, if at the cost of a bit of extra code as I have to make sure that the block isn't air (a null check would be better but is is guaranteed that there will never be an invalid block ID unless there is memory corruption or something; the chunk loading code also removes any invalid blocks present in the save data. Also, if null is never encountered the JVM can optimize out the null check it would do anyway to catch NPEs):
(getBlockState() is my own version of a "block state"; data value << 8 | block ID, enabling in this case a single chunk/block lookup to be done instead of separately looking up the ID and data value; I even use a local chunk cache to speed up access as much as possible (including other optimizations light updates are so much faster that world generation time decreased by 3-fold in a Mega Forest; a bunch of pistons moving blocks over holes in a high ceiling went from unplayably laggy to mild stutters). Block.blocksList is from vanilla, an array indexed by block ID (4096 in vanilla, 256 in TMCW), while clampedLightOpacity[] is the same as vanilla's Block.lightOpacity except values are clamped to a minimum of 1 to avoid having to check for 0)
Otherwise, you have to remember that my code is not designed with any support for mods in mind (even Optifine is not compatible, it may not even do anything if TMCW is installed after it as its own classes are overwritten or even completely bypassed, e.g. it modifies RenderGlobal and EntityRenderer, both of which were completely replaced with my own class; RenderBlocks and ItemRenderer are now simple wrappers whose methods are redirected to my own classes to maintain compatibility with vanilla code, and so on) so I don't need to worry about handling anything that isn't already in the game (i.e. mod blocks registering themselves).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?