GalianRyu

I cannot believe this actually worked, but it does! I glanced over the code that makes the blockstates from the new system and test this and it works: { "forge_marker": 1, "defaults": { "textures": { "top": "millenaire:blocks/tilestopvert", "bottom": "blocks/stonebrick", "front": "millenaire:blocks/tilesfront", "back": "millenaire:blocks/tilesfront", "side": "millenaire:blocks/tilesfront" } }, "variants": { "facing": { "north,half=bottom": { "y": 270 }, "south,half=bottom": { "y": 90 }, "east,half=bottom": { "y": 0 }, "west,half=bottom": { "y": 180 }, "north,half=top": { "y": 270, "x": 180 }, "south,half=top": { "y": 90, "x": 180 }, "east,half=top": { "y": 0, "x": 180 }, "west,half=top": { "y": 180, "x": 180 } }, "shape": { "straight": { "submodel": { "stonePart": { "model": "millenaire:byzantineStairsStonePart", "uvlock": true }, "tilePart": { "model": "millenaire:byzantineStairsTilePart", "uvlock": false } } }, While this is somewhat of a hack, I'd suggest actually making it a thing, because it greatly increases the options available in this new system. Immense gratitude to Jeffryfisher for giving me the idea to keep experimenting!

Is there a way to do that without having to change the Enum values in the code itself Jeffery?

Ah, okay that makes sense. Means I have to either abandon doing the stairs this way and just use a simpler model, or I have to switch from inheriting stairs and define a blockstate that would let me include both directional rotations in one variable (upper-north, upper-south, lower-north, etc). Okay, well thank you both for helping me out!

If that's the case, wouldn't it also fail to work on "facing"? It orients to the correct Y value on all of those. And if I take out the changes to Y in facing, then if flips on X just fine. I guess I'm failing to understand exactly what you mean, aside from update to 1.10? (which is the plan eventually, but this is not a small mod and that's a fair bit of work).

For further info: I tried editing it this way, as a test. "variants": { "half": { "top": { "x": 180 }, "bottom": { "x": 90 } }, "facing": { "north": { "y": 270 }, "south": { "y": 90 }, "east": { "y": 0 }, "west": { "y": 180 } }, And now it ignores "half" completely, even when facing is east. So it seems like multiple variables can't both be affecting the rotation, is this a bug in Forge itself?

I'm trying to use the new Submodel Blockstates to make some unique stairs and I've encounterted something odd, hoping you guys might know what I can do. Here is an excerpt from the JSON file in question: { "forge_marker": 1, "defaults": { "textures": { "top": "millenaire:blocks/tilestopvert", "bottom": "blocks/stonebrick", "front": "millenaire:blocks/tilesfront", "back": "millenaire:blocks/tilesfront", "side": "millenaire:blocks/tilesfront" } }, "variants": { "half": { "top": { "x": 180 }, "bottom": {} }, "facing": { "north": { "y": 270 }, "south": { "y": 90 }, "east": {}, "west": { "y": 180 } }, "shape": { "straight": { "submodel": { "stonePart": { "model": "millenaire:byzantineStairsStonePart", "uvlock": true }, "tilePart": { "model": "millenaire:byzantineStairsTilePart", "uvlock": false } } }, No errors in the console, no problem rendering the block, but the issue is that it won't flip the stairs unless they facing East. Basically unless "facing" is East, "half" is being completely ignored. I've run many tests and isolated that as the problem. Anyone know what I can do?

Hey All, So all I want to do is present a user with a simple "Yes/No" option when an Item is used that determines what the item actually does. I have utilized GuiScreen a lot (for books/tutorials), so making a GUI isn't hard, but I'm curious what the best way is to make the server aware of which button is pressed? Most GUI tutorials literally just say "do something here" and I've looked at packeting tutorials and every different one has you doing different things to create a packet so I'm not sure what's the best/cleanest/least-likely-to-cause-problems way to handle this fairly simple return to the server? Any help is greatly appreciated.

Looks like I after somewhat more careful analysis, need to extend PathNavigateGround and have it use a custom WalkNodeProcessor. In my custom WalkNodeProcessor I need to override GetVerticalOffSet() to return 1 or 2 for a FenceGate, probably 2. Now I just need to figure out how to open the gate, other than just straight up changing it's Blockstate.

So I'm building a mob and I want it to be able to go through Fence Gates, unlike vanilla mobs. I'm playing around with a few ideas for how to have it "open" the gate without getting hacky, but my primary question to the forums is this: How can I make path-finding smart enough to navigate through the gate? I have studied the path finding code somewhat, and I know how to call the normal pathfinding algorithms, but I'm a little lost if I was to start trying to make a custom PathNavigate; it's fairly complex. Is there a tutorial somewhere on setting up custom pathfinding? Anyone have any ideas on the simplest way to do this?

Hey All, I wanted to use the Lang File to actually localize books that are found in my mod, but in order to do this I need to be able to have a line in the Lang File recognize a line break. Does anyone know what I can put in to have it read a carriage return? I've tried every variation of the Unicode Carriage Return I can find.

Found It! It's in BlockChest.getLockableContainer(), it sets the displayname of the LargeInventory when it returns it. You have to override it and just switch the name it passes.

Hey All, I have a custom chest in my mod and I have overridden getDisplayName() to return my own name. This custom string shows for a single chest, but whenever I have a large chest, its still displaying the vanilla chest name. I've looked all through guiHandler, guiChest, containerChest and I can't find where it swaps up a different name for a large chest, heck guiChest looks like it just straight up calls the normal getDisplayName. what do I need to override to change the name in the large chest inventory?

SO I have an Item and I want to update getColorFromItemStack() so that the color shifts based on a value from 0 to 100 that's stored in the itemStack. Does anyone know the best way to...math all of this so that I can take a color, say Red, and have the number value shift from nothing to bright red as the value goes up?

SO I have an Item and I want to update getColorFromItemStack() so that the color shifts based on a value from 0 to 100 that's stored in the itemStack. Does anyone know the best way to...math all of this so that I can take a color, say Red, and have the number value shift from nothing to bright red as the value goes up?

Well I went from not knowing how to do it to having three different options. Thank you guys

Well, it doesn't necessarily need to be attached to the world, just saved and read in as NBT. Its going to be values like a player's reputation with different factions, and those faction's relationship with each other, which should be visible (and editable) no matter which Faction Base Block is actually loaded. Is WorldSavedData the best way to implement that? This is deeper than I have yet dived into Forge, so I'm not even sure which classes to check out.

So the goal I have is to have a file that is instantiated in memory while a particular world is running. It will hold data that other pieces of the mod need to reference and change, no matter what chunks are loaded. I want it to write to NBT when the world is closed and read from NBT when the world is opened. It seems like this is thoroughly doable with capabilities, but I'm getting lost in the exact implementation. Do I need to register it as a new capability with CapabilityManager, or can I use ICapabilitySerializable<NBTTagCompound>? If so, how do I handle the hasCapability and getCapability functions? Here the very small amount of code I have so far: import net.minecraft.nbt.NBTTagCompound; @SuppressWarnings("rawtypes") public class VillageTracker implements net.minecraftforge.common.capabilities.ICapabilitySerializable<NBTTagCompound> { public int test; public VillageTracker() { } private void readFromNBT(NBTTagCompound nbt) { if(nbt.hasKey("testInt")) test = nbt.getInteger("testInt"); } private void writeToNBT(NBTTagCompound nbt) { nbt.setInteger("testInt", test); } @Override public boolean hasCapability(net.minecraftforge.common.capabilities.Capability<?> capability, net.minecraft.util.EnumFacing facing) { } @Override public <T> T getCapability(net.minecraftforge.common.capabilities.Capability<T> capability, net.minecraft.util.EnumFacing facing) { } @Override public void deserializeNBT(NBTTagCompound nbt) { this.readFromNBT(nbt); } @Override public NBTTagCompound serializeNBT() { NBTTagCompound nbt = new NBTTagCompound(); this.writeToNBT(nbt); return nbt; } }

Right now in vanilla Minecraft/Forge, BlockFenceGate specifically looks for the vanilla cobblestone walls and thats it to properly position the gate. Can Forge add a function in Block (public boolean isWall() as a possibility) that can be overridden and make BlockFenceGate check it? Seems like that would be pretty easy to do, much better than the only solution I can see with the current set up(which is to override all the vanilla gates in your mod with one that recognizes your added walls and then immediately screws up any other mod with Walls).

World.sendBlockBreakProgress() looks like the function I need, but what can I reference to know what break progress the current block wshould have? Seriously, any help at all would be appreciated...

Okay, I figured out the issue (was a problem with my entire eclipse environment). The event handler is working, woo! Now I just need to know what function to call on the other block to make it start/continue breaking.

Okay, so I backed up my src folder and then just completely deleted the entire folder, emptying .gradle and then set up the workspace from scratch and everything seems to be working correctly now. Must have just been the differences from 14.3 to 14.4, what with the switch to MDK... Still odd as hell though.

Just confirmed it by adding a dummy block. The Block doesn't show up, so my Run Client is holding onto some bizarro copy of my code and not reading any actual changes. How does that happen, and how can I fix it?

So it had been a while since I updated Forge, enough time I had to basically rebuild my workspace to do it. Since doing so, I have a strange error - Every time I run my debug client, it says this in the output: [23:31:03] [Thread-10/INFO]: (The LWJGL binding of OpenAL. For more information, see http://www.lwjgl.org) [23:31:03] [Thread-10/INFO]: OpenAL initialized. [23:31:04] [sound Library Loader/INFO]: Sound engine started [23:31:05] [Client thread/WARN] [FML]: Unable to load block model: 'rpcraft:block/beds/beds/bedOakLimeHead' for variant: 'rpcraft:bedBlockOakLime#facing=east,occupied=true,part=head': java.io.FileNotFoundException: rpcraft:models/block/beds/beds/bedOakLimeHead.json [23:31:05] [Client thread/WARN] [FML]: Unable to load block model: 'rpcraft:block/beds/beds/bedOakLimeHead' for variant: 'rpcraft:bedBlockOakLime#facing=west,occupied=true,part=head': java.io.FileNotFoundException: rpcraft:models/block/beds/beds/bedOakLimeHead.json [23:31:05] [Client thread/WARN] [FML]: Unable to load block model: 'rpcraft:block/beds/beds/bedOakLimeHead' for variant: 'rpcraft:bedBlockOakLime#facing=south,occupied=false,part=head': java.io.FileNotFoundException: rpcraft:models/block/beds/beds/bedOakLimeHead.json [23:31:05] [Client thread/WARN] [FML]: Unable to load block model: 'rpcraft:block/beds/beds/bedOakLimeHead' for variant: 'rpcraft:bedBlockOakLime#facing=north,occupied=true,part=head': java.io.FileNotFoundException: rpcraft:models/block/beds/beds/bedOakLimeHead.json [23:31:05] [Client thread/WARN] [FML]: Unable to load block model: 'rpcraft:block/beds/beds/bedOakLimeHead' for variant: 'rpcraft:bedBlockOakLime#facing=east,occupied=false,part=head': java.io.FileNotFoundException: rpcraft:models/block/beds/beds/bedOakLimeHead.json [23:31:05] [Client thread/WARN] [FML]: Unable to load block model: 'rpcraft:block/beds/beds/bedOakLimeFoot' for variant: 'rpcraft:bedBlockOakLime#facing=west,occupied=false,part=foot': java.io.FileNotFoundException: rpcraft:models/block/beds/beds/bedOakLimeFoot.json [23:31:05] [Client thread/WARN] [FML]: Unable to load block model: 'rpcraft:block/beds/beds/bedOakLimeHead' for variant: 'rpcraft:bedBlockOakLime#facing=north,occupied=false,part=head': java.io.FileNotFoundException: rpcraft:models/block/beds/beds/bedOakLimeHead.json [23:31:05] [Client thread/WARN] [FML]: Unable to load block model: 'rpcraft:block/beds/beds/bedOakLimeFoot' for variant: 'rpcraft:bedBlockOakLime#facing=north,occupied=false,part=foot': java.io.FileNotFoundException: rpcraft:models/block/beds/beds/bedOakLimeFoot.json [23:31:05] [Client thread/WARN] [FML]: Unable to load block model: 'rpcraft:block/beds/beds/bedOakLimeFoot' for variant: 'rpcraft:bedBlockOakLime#facing=west,occupied=true,part=foot': java.io.FileNotFoundException: rpcraft:models/block/beds/beds/bedOakLimeFoot.json [23:31:05] [Client thread/WARN] [FML]: Unable to load block model: 'rpcraft:block/beds/beds/bedOakLimeFoot' for variant: 'rpcraft:bedBlockOakLime#facing=east,occupied=false,part=foot': java.io.FileNotFoundException: rpcraft:models/block/beds/beds/bedOakLimeFoot.json [23:31:05] [Client thread/WARN] [FML]: Unable to load block model: 'rpcraft:block/beds/beds/bedOakLimeFoot' for variant: 'rpcraft:bedBlockOakLime#facing=south,occupied=false,part=foot': java.io.FileNotFoundException: rpcraft:models/block/beds/beds/bedOakLimeFoot.json [23:31:05] [Client thread/WARN] [FML]: Unable to load block model: 'rpcraft:block/beds/beds/bedOakLimeHead' for variant: 'rpcraft:bedBlockOakLime#facing=west,occupied=false,part=head': java.io.FileNotFoundException: rpcraft:models/block/beds/beds/bedOakLimeHead.json [23:31:05] [Client thread/WARN] [FML]: Unable to load block model: 'rpcraft:block/beds/beds/bedOakLimeHead' for variant: 'rpcraft:bedBlockOakLime#facing=south,occupied=true,part=head': java.io.FileNotFoundException: rpcraft:models/block/beds/beds/bedOakLimeHead.json [23:31:05] [Client thread/WARN] [FML]: Unable to load block model: 'rpcraft:block/beds/beds/bedOakLimeFoot' for variant: 'rpcraft:bedBlockOakLime#facing=north,occupied=true,part=foot': java.io.FileNotFoundException: rpcraft:models/block/beds/beds/bedOakLimeFoot.json [23:31:05] [Client thread/WARN] [FML]: Unable to load block model: 'rpcraft:block/beds/beds/bedOakLimeFoot' for variant: 'rpcraft:bedBlockOakLime#facing=east,occupied=true,part=foot': java.io.FileNotFoundException: rpcraft:models/block/beds/beds/bedOakLimeFoot.json [23:31:05] [Client thread/WARN] [FML]: Unable to load block model: 'rpcraft:block/beds/beds/bedOakLimeFoot' for variant: 'rpcraft:bedBlockOakLime#facing=south,occupied=true,part=foot': java.io.FileNotFoundException: rpcraft:models/block/beds/beds/bedOakLimeFoot.json [23:31:05] [Client thread/INFO] [FML]: Max texture size: 16384 [23:31:06] [Client thread/INFO]: Created: 1024x512 textures-atlas That was a typo I fixed 2 versions ago, but it keeps saying it's there. It also won't render that bed. However, my blockstate file is { "variants": { "facing=north,occupied=true,part=foot": { "model": "rpcraft:beds/bedOakLimeFoot", "y": 180 }, "facing=east,occupied=true,part=foot": { "model": "rpcraft:beds/bedOakLimeFoot", "y": 270 }, "facing=south,occupied=true,part=foot": { "model": "rpcraft:beds/bedOakLimeFoot" }, "facing=west,occupied=true,part=foot": { "model": "rpcraft:beds/bedOakLimeFoot", "y": 90 }, "facing=north,occupied=true,part=head": { "model": "rpcraft:beds/bedOakLimeHead", "y": 180 }, "facing=east,occupied=true,part=head": { "model": "rpcraft:beds/bedOakLimeHead", "y": 270 }, "facing=south,occupied=true,part=head": { "model": "rpcraft:beds/bedOakLimeHead" }, "facing=west,occupied=true,part=head": { "model": "rpcraft:beds/bedOakLimeHead", "y": 90 }, "facing=north,occupied=false,part=foot": { "model": "rpcraft:beds/bedOakLimeFoot", "y": 180 }, "facing=east,occupied=false,part=foot": { "model": "rpcraft:beds/bedOakLimeFoot", "y": 270 }, "facing=south,occupied=false,part=foot": { "model": "rpcraft:beds/bedOakLimeFoot" }, "facing=west,occupied=false,part=foot": { "model": "rpcraft:beds/bedOakLimeFoot", "y": 90 }, "facing=north,occupied=false,part=head": { "model": "rpcraft:beds/bedOakLimeHead", "y": 180 }, "facing=east,occupied=false,part=head": { "model": "rpcraft:beds/bedOakLimeHead", "y": 270 }, "facing=south,occupied=false,part=head": { "model": "rpcraft:beds/bedOakLimeHead" }, "facing=west,occupied=false,part=head": { "model": "rpcraft:beds/bedOakLimeHead", "y": 90 } } } Which is correct. This is really worrying me, because if it won't let this go, I'm worried other changes I'm making aren't showing up when I run tests either. Anyone have any idea what might be causing this?

So I tried making an Event Handler, put this in my init method: MinecraftForge.EVENT_BUS.register(new BlockLargeCrate.PlayerInteractEventHandler()); And here's the body: public static class PlayerInteractEventHandler { @SubscribeEvent public void onPlayerInteract(PlayerInteractEvent event) { System.out.println("caught Interaction"); if(event.action == PlayerInteractEvent.Action.LEFT_CLICK_BLOCK && event.world.getBlockState(event.pos).getBlock() == BlockCrate.blockLargeCrate) { System.out.println("caught Block"); BlockPos pos1 = ((BlockLargeCrate)BlockCrate.blockLargeCrate).findTileBlock(event.world, event.pos); if(pos1 != event.pos) { System.out.println("this works"); } } } } But nothing ever fires, I don't even see the first println. Really need help on this one.

I have a block that has two BlockStates and I want to make it where using a pickaxe on one actually breaks the other one in a different position. I have been able to make everything work except the actual breaking texture. From what I've seen, it looks like this can be achieved, but it involves using PlayerInteractEvent, and I still don't fully understand how to correctly utilize events. Does anyone have an idea how I can make this happen?