Draco18s

Its more than likely that you never set the field in your main class to anything.

http://mcforge.readthedocs.io/en/latest/blockstates/forgeBlockstates/ { "forge_marker": 1, "defaults": { "textures": { "texture": "blocks/planks_oak", "wall": "blocks/planks_oak" }, "model": "pressure_plate_up", "uvlock": true }, "variants": { // mossy is a boolean property. "mossy": { "true": { // if true it changes the pressure plate from oak planks to mossy cobble "textures": { "texture": "blocks/cobblestone_mossy" } }, "false": { // change nothing. The entry has to be here to be generated for internal usage by minecraft } }, // pillarcount is a property that determines how many pillar submodels we have. Ranges from 0 to 2 "pillarcount": { 0: { // no pillar. Remember, has to be there. }, 1: { // if it is true, it will add the wall model and combine it with the pressure plate "submodel": "wall_n" }, 2: { "textures": { "wall": "blocks/cobblestone" }, "submodel": { "pillar1": { "model": "wall_n" }, "pillar2": { "model": "wall_n", "y": 90 } } } } } } The "pillarcount" section is not valid JSON (ignoring the comments). "Expecting 'STRING', '}', got 'NUMBER'" It should be: { "forge_marker": 1, "defaults": { "textures": { "texture": "blocks/planks_oak", "wall": "blocks/planks_oak" }, "model": "pressure_plate_up", "uvlock": true }, "variants": { // mossy is a boolean property. "mossy": { "true": { // if true it changes the pressure plate from oak planks to mossy cobble "textures": { "texture": "blocks/cobblestone_mossy" } }, "false": { // change nothing. The entry has to be here to be generated for internal usage by minecraft } }, // pillarcount is a property that determines how many pillar submodels we have. Ranges from 0 to 2 "pillarcount": { "0": { // no pillar. Remember, has to be there. }, "1": { // if it is true, it will add the wall model and combine it with the pressure plate "submodel": "wall_n" }, "2": { "textures": { "wall": "blocks/cobblestone" }, "submodel": { "pillar1": { "model": "wall_n" }, "pillar2": { "model": "wall_n", "y": 90 } } } } } }

"meta:15" and "water" are not related here. The metadata 15 check is "how long has the reeds/seaweed been growing." It's AGE. Water is merely the "is there water above me?" check so that the seaweed doesn't grow up into air.

Doesn't render in the world either. Went back to using vanilla textures (it worked). Moved to my custom block model (it has an overlay). That worked. Then added a particle (that was fine). Changed one texture to my texture. And it worked. I'm confused. I can ctrl-z back to something that doesn't work and ctrl-y back to something that does. WTH. Edit: Tried to isolate what made it break and somehow lost that state.

I literally copied the texture from my 1.7.10 mod. http://s31.postimg.org/hst3mvyi3/iron_ore.png[/img]

Looks like you copied the code from BlockReeds. The code as you have it does not do what you say you think it does. Check the block positions again: "If the block above is water, then loop through the blocks below checking that they are the same block as this. If there are less than 3 and the metadata of this block is 15, set the metadata to 0 and place this block above."

I finally got around to setting up a 1.10 workspace to start messing around, slowly easing myself into the new systems and start working on an update to on of my most popular mods. Thing is, I'm not getting any textures on my first block: http://s32.postimg.org/o0346qu11/2016_07_18_13_35_43.png[/img] But no errors about it in the console: Block json: And the texture(s) I wish to use do exist: I'm going to assume that the block class and the block registration aren't needed as the json is being utilized (that is: if I change the texture to something else, e.g. "all": "doesntexist:blocks/iron_ore" , I get a "could not find texture for domain "doesntexist" error. Similiarly if I use "all": "blocks/dirt" , then it works and renders just fine), implying that I have correctly registered the block, item block, and its custom model and that the problem is elsewhere.

Be sure to change the search parameters from "all markets" to "tools" or you will never find it.

It's in the constrictor for his generator

Also, drop that new Object[]{} nonsense. You don't need it because varargs is magic.

I would store the FACING in the metadata (so many blocks already do, if a mod comes along with a tool that can rotate blocks, your block would be automatically rotatable with no effort if you do) and the BLOCKTYPE in the TileEntity.

You tried to create a recipe that isn't the correct size. Post your code. Always ALWAYS post your code.

Metadata is only 4 bits worth of data. Facing takes (minimum) 2 of those bits, leaving you 2 (four possible values) for BLOCKTYPE. Show your BLOCKTYPE property declaration/definition.

That line is likely the problem. Do what Diesieben07 says and get rid of the TE.

Do not instantiate your own main class, the @Instance annotation does it for you as Forge loads your mod.

1) You're in the wrong board. 2) You didn't install Code Chicken Core like the instructions said. 3) Update.

You effectively need two methods in your IEEP (possibly more, but these two are key): addMana(amount) subtractMana(amount) You could even make them one method, but we'll assume that they perform different checks and might have to be separate. However the general structure is the same: addSubMana(int amount) { /* check if able, floor/ceiling to min/max if needed */ theManaAmount += amount; sendPacketToClient(....); } Then in private sendPacketToClient you...send an update packet to the client informing them of their new mana amount.

http://stackoverflow.com/a/778275/1663383

...What?

Mm. Yep, that's client side code. The server has no idea WTF is going on.

3. You should be passing a 3.

Or I could do everything in the base mod class and delegate to the proxy when, and only when, sided code is required. i.e. the registering of event handlers, renderers, and suchlike.

No, no one has ever done that ever. Also, NEI is "dead." It's not going to update. I think JEI is the "hot shit" now.

IBlockAccess is "world-lite" or "read-only World." World implements IBlockAcess and IBlockAccess provides access to blocks (every single getter). Please look at world#setBlock to know what that last parameter does. 1 is not the right value to pass.

Eehhh. I prefer that common goes goes in the base mod class. I see way to much "it should be in the proxy" so the main mod class tells the proxy about the init events, then the proxy goes "well all the code is over in the ModBlocks class" and shunts the event over there. It's a right pain in the ass to debug when the person has a problem because we have to ask for THREE classes to identify the problem (oops, their ModBlocks.preInit() method is actually called durring an init event). There's no reason to shunt method calls around, sure it adheres to some abstract notion of encapsulation, but encapsulation really isn't that good (if encapsulation is followed to the letter, then no package would ever import any package other than itself, its direct parent, and its direct children sub-packages and all cross-package invocation would be fired up or down this chain*). *That is, in order for a block to reference an item, the block would have to ask ModBlocks to forward a call to BaseMod, which would then forward the call to ModItems, and so forth.