Mystify

Its not quite spontaneous, but if you change the blockstate, it happens. With vanilla blocks, changing the blockstate to a different blockstate for the same block is fine, but not for non-vanilla blocks. I don't know why they felt that non-vanilla blocks should have a different default behavior.

I figured out my issue. The shouldRefresh method on TileEntity tells whether the tile entity should be removed if the blockstate is update. Its default implementation has a "!isVanilla" on the test, so the non-vanilla tile entities always returns true, and hence the TileEntity gets deleted, even when the block itself hasn't changed. I had to override this method, and this prevented my TileEntity from getting deleted before I was ready.

my guess would be that the world's spawnpoint is only used for spawning in new players, and the player's bed location is used otherwise, and that may default to the world's spawnpoint. Just a guess from reading the thread, I don't have time to dig into code right now.

That was the last thing I tried doing. Here is the output without that This does look a bit cleaner, but the basic issue is the same; it comes in and overwrites the TileEntity with a fresh one at the .Chunk.setBlockState(Chunk.java:725) call. I'll also remove the onBlockPlacedBy method, as it seems to be redundant. This makes the placement look like I want; it gets placed, then it loads the extra NBT data I wanted, setting the parameters, then writes them back out. However, the second part is still smashing over it with the wrong data.

I have a block that needs extra data stored on it, so I am using a tileEntity to store 1 integers. When I create the ItemStack containing the block, I add extra data to it storing these extra values. This part works fine. What I need to happen is, upon placing the block, a TileEntity is created for it and the values from the ItemStack are stored on it. The behavior I am seeing is that I am creating the TileEntity, setting the values, and they exist on the TileEntity, but then it creates another tileEntity without the right values and overwrites the old one. Relevant Code: Sample output from placing a block The first part is from initially placing the block. I see it create an unitialized tile enity, as expected. I then see it read a 0,9 block; this is also expected, as this should be the NBT data from the itemstack getting applied to the TileEntity and read in. Then there is a setting params call; this part should be redundant, and ws added as part of my expiremtnation, but it is just setting the 0,9 data again. Then it creates a new 0,0 unitialized tileentity. The stack trace shows this one is coming from teh code tileentity = this.getTileEntity(pos, Chunk.EnumCreateEntityType.CHECK); if (tileentity == null) { tileentity = block.createTileEntity(this.worldObj, state); on Chunk. which implies that the tileEntity from before is not on the chunk, so it is trying to load it again and overwrites the one with stored data. This again goes through the "load NBT data", and "set paramters" calls, and seems to end with the correct 0,9 data saved. After the ..., I triggered the block to read the data. It says "writing" and stores the correct 0,9 data, but then another call to create a TileEntity is made. This again seems to come from the Chunk call, where it is not finding a TileEntity at the the positon, and so makes a new one. I am changing the BlockState at this point, but it is the same block with a different blockstate, and it should be able to continue on with the existing TileEntity. This gets a 0,8 pair, since the getMetaFromState happens to return an 8, but that shouldn't be getting called in teh first place. This happens several times, leaving me with a different set of data than I inteded. This all seems to be stemming from the Chunk.getTileEntity returning null.

Ok, I was right. You refer to "MinePlus:blockStackOfSticks" in your blockstates, but the actual file is " MinePlus:MinePlus_block_stackOfSticks" When you register the item, you do it properly, with the MinePlus:MinePlus_block_stackOfSticks, which is why it shows up properly in the inventory.

What are the names of those files? I suspect your names for the blocks are not matching up with the file names properly, so the item manages to find the item, which in turn references the block model, but the block itself is not pointing at that same model.

the clean seemed to do the trick. Thank you all for your help

I tried making a smaller version with just the code I posted and it worked fine. My current theory is that it has something to do with the renamed folder. Does anyone know how gradle can be including deleted folders in the build, or use old folder names?

That is exactly the version of forge I rolled back to to test, and I had the same error.

I tried reverting to an earlier forge version from last month, but it changed nothing. I tried commenting out the method call the stack trace was being thrown on, but it just threw it at the next line instead. I made a simpler mod with a single crafting recipe and no new blocks and it ran without issue. Could it be an issue with the mappings? Are the ones I'm using actually for 1.8?

buildscript { repositories { mavenCentral() maven { name = "forge" url = "http://files.minecraftforge.net/maven" } maven { name = "sonatype" url = "https://oss.sonatype.org/content/repositories/snapshots/" } } dependencies { classpath 'net.minecraftforge.gradle:ForgeGradle:1.2-SNAPSHOT' } } apply plugin: 'forge' version = "1.8-0.1" group= "com.mystify.galactic" archivesBaseName = "Galactic Blocks" minecraft { version = "1.8-11.14.0.1289-1.8" runDir = "eclipse" // the mappings can be changed at any time, and must be in the following format. // snapshot_YYYYMMDD snapshot are built nightly. // stable_# stables are built at the discretion of the MCP team. // Use non-default mappings at your own risk. they may not allways work. // simply re-run your setup task after changing the mappings to update your workspace. mappings = "snapshot_nodoc_20141130" } dependencies { // you may put jars on which you depend on in ./libs // or you may define them like so.. //compile "some.group:artifact:version:classifier" //compile "some.group:artifact:version" // real examples //compile 'com.mod-buildcraft:buildcraft:6.0.8:dev' // adds buildcraft to the dev env //compile 'com.googlecode.efficient-java-matrix-library:ejml:0.24' // adds ejml to the dev env // for more info... // http://www.gradle.org/docs/current/userguide/artifact_dependencies_tutorial.html // http://www.gradle.org/docs/current/userguide/dependency_management.html } processResources { // this will ensure that this task is redone when the versions change. inputs.property "version", project.version inputs.property "mcversion", project.minecraft.version // replace stuff in mcmod.info, nothing else from(sourceSets.main.resources.srcDirs) { include 'mcmod.info' // replace version and mcversion expand 'version':project.version, 'mcversion':project.minecraft.version } // copy everything else, thats not the mcmod.info from(sourceSets.main.resources.srcDirs) { exclude 'mcmod.info' } }

package com.mystify.galactic.blocks; import net.minecraft.block.Block; import net.minecraft.item.EnumDyeColor; import net.minecraft.item.ItemBlock; import net.minecraft.item.ItemStack; import net.minecraftforge.fml.common.FMLCommonHandler; import net.minecraftforge.fml.common.registry.GameRegistry; public class ColoredBlockItemBlock extends ItemBlock { IColoredBlock cBlock; public ColoredBlockItemBlock(Block block) { super(block); cBlock=(IColoredBlock)block; this.setMaxDamage(0); this.setHasSubtypes(true); } /** * Converts the given ItemStack damage value into a metadata value to be placed in the world when this Item is * placed as a Block (mostly used with ItemBlocks). */ public int getMetadata(int damage) { return damage; } /** * Returns the unlocalized name of this item. This version accepts an ItemStack so different stacks can have * different names based on their damage or NBT. */ public String getUnlocalizedName(ItemStack stack) { return cBlock.getFullName(stack.getMetadata()); } } package com.mystify.galactic; import java.util.Collections; import java.util.Comparator; import java.util.List; import java.util.Iterator; import com.mystify.galactic.blocks.AlienCoarseDirt; import com.mystify.galactic.blocks.AlienCobble; import com.mystify.galactic.blocks.AlienCobbleMossy; import com.mystify.galactic.blocks.AlienCobbleSlab; import com.mystify.galactic.blocks.AlienCobbleSlabDouble; import com.mystify.galactic.blocks.AlienCobbleStairs; import com.mystify.galactic.blocks.AlienCobbleWall; import com.mystify.galactic.blocks.AlienCobbleWallMossy; import com.mystify.galactic.blocks.AlienDirt; import com.mystify.galactic.blocks.AlienDoor; import com.mystify.galactic.blocks.AlienFarmland; import com.mystify.galactic.blocks.AlienFence; import com.mystify.galactic.blocks.AlienFenceGate; import com.mystify.galactic.blocks.AlienGrass; import com.mystify.galactic.blocks.AlienGravel; import com.mystify.galactic.blocks.AlienLever; import com.mystify.galactic.blocks.AlienLog; import com.mystify.galactic.blocks.AlienPlankSlab; import com.mystify.galactic.blocks.AlienPlankSlabDouble; import com.mystify.galactic.blocks.AlienPlankStairs; import com.mystify.galactic.blocks.AlienPlanks; import com.mystify.galactic.blocks.AlienSand; import com.mystify.galactic.blocks.AlienSandstone; import com.mystify.galactic.blocks.AlienSandstoneCarved; import com.mystify.galactic.blocks.AlienSandstoneSlab; import com.mystify.galactic.blocks.AlienSandstoneSlabDouble; import com.mystify.galactic.blocks.AlienSandstoneSmooth; import com.mystify.galactic.blocks.AlienSandstoneStairs; import com.mystify.galactic.blocks.AlienStone; import com.mystify.galactic.blocks.AlienStoneBrick; import com.mystify.galactic.blocks.AlienStoneBrickCarved; import com.mystify.galactic.blocks.AlienStoneBrickCracked; import com.mystify.galactic.blocks.AlienStoneBrickMossy; import com.mystify.galactic.blocks.AlienStoneBrickSlab; import com.mystify.galactic.blocks.AlienStoneBrickSlabDouble; import com.mystify.galactic.blocks.AlienStoneBrickStairs; import com.mystify.galactic.blocks.AlienStoneButton; import com.mystify.galactic.blocks.AlienStonePressurePlate; import com.mystify.galactic.blocks.AlienStoneSlab; import com.mystify.galactic.blocks.AlienStoneSlabDouble; import com.mystify.galactic.blocks.AlienTrapdoor; import com.mystify.galactic.blocks.AlienWoodButton; import com.mystify.galactic.blocks.AlienWoodPressurePlate; import com.mystify.galactic.blocks.ColoredBlock; import com.mystify.galactic.blocks.ColoredBlockItemBlock; import com.mystify.galactic.blocks.IColoredBlock; import com.mystify.galactic.blocks.SlabItemBlock; import com.mystify.galactic.items.AlienDoorItem; import com.mystify.galactic.items.IColoredItem; import net.minecraft.block.Block; import net.minecraft.client.Minecraft; import net.minecraft.client.renderer.ItemModelMesher; import net.minecraft.client.renderer.entity.RenderItem; import net.minecraft.client.resources.model.ModelBakery; import net.minecraft.client.resources.model.ModelResourceLocation; import net.minecraft.creativetab.CreativeTabs; import net.minecraft.init.Blocks; import net.minecraft.item.EnumDyeColor; import net.minecraft.item.Item; import net.minecraft.item.ItemBlock; import net.minecraft.item.ItemStack; import net.minecraftforge.common.MinecraftForge; import net.minecraftforge.common.config.Configuration; import net.minecraftforge.fml.common.FMLCommonHandler; import net.minecraftforge.fml.common.Mod; import net.minecraftforge.fml.common.event.FMLInitializationEvent; import net.minecraftforge.fml.common.event.FMLPreInitializationEvent; import net.minecraftforge.fml.common.registry.GameRegistry; import net.minecraftforge.fml.relauncher.Side; import net.minecraftforge.fml.relauncher.SideOnly; @Mod(modid = References.MODID, version = References.VERSION) public class Galactic { public static Block alienStone; @Mod.EventHandler public void preinit(FMLPreInitializationEvent event) { alienStone = new AlienStone(); } @Mod.EventHandler public void init(FMLInitializationEvent event) { Recipes.initRecipies(); if(event.getSide() == Side.CLIENT) { //blocks addColorVariantsFor(alienStone); } } private void addColorVariantsFor(Block block){ EnumDyeColor[] aenumdyecolor = EnumDyeColor.values(); int i = aenumdyecolor.length; Item itemVersion = GameRegistry.findItem(References.MODID, ((IColoredBlock) block).getName()); String[] variants = new String[i]; for (int j = 0; j < i; ++j) { String fullySpecifiedName=References.MODID + ":" + ((IColoredBlock) block).getName()+"."+ aenumdyecolor[j].getUnlocalizedName(); variants[j]=fullySpecifiedName; String registeredName=References.MODID + ":" + ((IColoredBlock) block).getName()+"."+ aenumdyecolor[j].getUnlocalizedName(); registerBlock(block, j,registeredName); } ModelBakery.addVariantName(Item.getItemFromBlock(block), variants); } public static void registerBlock(Block block, int metadata, String blockName) { registerItem(Item.getItemFromBlock(block), metadata, blockName); } } public class AlienStone extends ColoredBlock { public static final PropertyEnum COLOR = PropertyEnum.create("color", EnumDyeColor.class); public AlienStone(){ super(Material.rock,"alienStone"); this.setDefaultState(this.blockState.getBaseState().withProperty(COLOR, EnumDyeColor.WHITE)); setHardness(1.5F).setResistance(10.0F).setStepSound(soundTypePiston); } public abstract class ColoredBlock extends Block implements IColoredBlock { public static final PropertyEnum COLOR = PropertyEnum.create("color", EnumDyeColor.class); private String name; public ColoredBlock(Material material, String name){ super(material); this.name=name; GameRegistry.registerBlock(this, ColoredBlockItemBlock.class,name); setUnlocalizedName(References.MODID+"_"+name); setCreativeTab(Galactic.tabColoredBlock); } I cut out most of the classes, but this should be all the relevant code for where the exception occurs

I did use gradlew build

When I run my mod from eclipse, it works fine. When I build it, I get a couple of issues. The first is that some deleted folders end up in the resulting jar. Specifically, the examplemod is still present, and a folder I renamed reverts back to an old name. I can delete the example mod folders again and rename it in the jar to resolve the errors that result. When I try to run the jar, I get an invocation target exception, the line that the error comes from is "this.setMaxDamage(0);" in the constructor of a class that extends ItemBlock