LexManos

They accomplish this by creating fake air blocks that emit light.

public class DraftingProvider implements ICapabilityProvider{ https://github.com/MinecraftForge/MinecraftForge/blob/master/src/main/java/net/minecraftforge/common/capabilities/CapabilityDispatcher.java#L52-L61

1) Use the normal launcher 2) Update Forge 3) We have no idea what 'messsed up' means. MOST LIKELY your using a mac and the loading screen is screwing up because macs have crappy graphics drivers. So disable the loading screen.

1) No stencils will not be enabled by default but you cna opt-in to them yourself you don't need a library like cofh. They will never again be enabled by default in Forge because there are to many systems out there that break horribly when stencils are enabled. We have to support everyone do it's now a opt-in system instead of opt-out. 2) You SHOULD NOT be rendering your own things in 1.8+ 3) Yes 99% of everything you have/want to do with rendering can be done with the model system 4) DO NOT RENDER GL CRAP MANUALLY.

They have come forward and asked us for use of our jenkins and servers.

Forge manages the block ID mapping and will use the world ids BEFORE the new ids. So loading a 1.7.10 world in 1.8, if any mod blocks have the ids for newly added vanilla ones, for that world the vanilla ones will have new IDs. We store a table of block name -> IDs in the world itself so they are fine. MCEdit needs to support that table if they ever want to support modded stuff.

Don't care, Mojang is wrong, we will continue to fix this bug. Not fixing it would require us to special case the shit out of all stairs, or break a lot of Forge/Mod/Vanilla features. I'm not willing to do that so for now deal with it. And Mojang has a long history of claiming bugs as features because they do not want break old worlds. Its the same case for us.

Whatever inventory you are looking at or opening is messed up. We'd have to see what inventory that is. Beyond that, update to 1.8+ if you want support.

1) These mods are broken as they are not following the standard to be detected as mods. 2) Cheating is bad mmkay..

https://github.com/MinecraftForge/Documentation And no, giving copy paste code is bad, if you write 'tutorials' like that we will not accept them.

Yes, we fix a bug related to interacting with iron doors. We have for years, get over it.

Possibly, either way you should tell the mod author to update.

Give the exact page, and link you clicked to download. Screenshots help Just checked the files page everything is fine. Edit: Seems adfocus is having a caching issue, just use the direct downloads.

CCC has no valid uses for devs in 1.8+ Stop using it.

There is no crash here.

Known and fixed bug, update Forge.

"Pay us and we'll remove the need for credentials on your launcher!" Really... really not a cracked launcher!?!?

We do not support 1.6.4, you should update or do your own research. 1.7.10 is feasible, 1.8 is where we currently are at. 1.9 is just around the corner.

Make sure you have access to the internet, also post the logs. The EAQs exist for a reason.

{ "forge_marker" : 1, "defaults": { "textures" : { "texture": "blocks/quartz_ore" }, "model": "pressure_plate_down" }, "variants": { "power": { 0: {"model": "pressure_plate_up"}, 1: {}, 2: {}, 3: {}, 4: {}, 5: {}, 6: {}, 7: {}, 8: {}, 9: {}, 10: {}, 11: {}, 12: {}, 13: {}, 14: {}, 15: {} } } } Something like that should work, haven't tested it but it's the idea. 1.9 expands things to have predicates which can make this a little better but we'll see when it actually goes live and we see what we can deal with. Or, if you use POWERED as a unlisted property in getActualState and then filter out the power you can do this: { "forge_marker" : 1, "defaults": { "textures" : { "texture": "blocks/quartz_ore" }, "model": "pressure_plate_down" }, "variants": { "powerd": { "true": {}, "false": {"model": "pressure_plate_up"} } } }

Sadly you have to follow the basic rules that are put in place for blocks. The reason it 'bugs' out in Forge is because we treat stairs {and slabs, and other blocks} correctly allowing for the proper sides that are solid to be detected as solid. This is what allows us to let torches stay on the sides of stairs, or to have mods have covers that are treated as solid. Things like that. There may be a way to trick it into not doing this by making the solid block you're placing against not have any cull faces but that would be a waste for the rest of the world. I would just say, even tho that model looks cool, you need to keep some semblance of the same shapes as vanilla. Else your torches would look weird when placed on them as well. Remember that Minecraft knows about the blocks in code, and nothing about resources can change what the game thinks the blocks are shaped as.

Inequalities and stuff like that don't work. You have to specify all your variants. This isn't magic you have to tell it what states your block has.

Yes, every permutation of every property gets a blockstate created for it thus all your 'invalid' states STILL exist and take up memory. Even if they are not put into the ID mapping. Admittedly as BlockState implementation is a small class, that's not much memory for you, wasting maybe ~500 bytes. But waste is waste. As for why they don't use mTs/sTm in networking. state = MAP[(ID<<16) | meta] is thousands of times faster then state = MAP[iD].mTs(meta)

Take these with a rain of salt code-style wise as they are patches but: Furnaces Chests BrewingStands This is my original test code which shows my intention of how modders should so it with Caps that Forge/They don't provide {Doing it this way gives soft-dependencies} https://github.com/LexManos/MinecraftForge/blob/Capabilities/patches/minecraft/net/minecraft/tileentity/TileEntityFurnace.java.patch#L58 This shows my original test code which creates, and queries a TE for it's capability: https://github.com/LexManos/MinecraftForge/blob/Capabilities/src/test/java/net/minecraftforge/test/capabilitytest/TestCapabilityMod.java#L27-L62 It's not to difficult. Someone write better docs.

You should not be using POWERED then, as in memory you're taking up twice as much room as you need to because you have 'invalid' states in the IBlockState table. In your renderer you should just have a >0 check. Or, as others have suggested use IUnlistedProperty and fill it in in getActualState. Beyond that, depending on how you register your class things could get odd with the metadata. What state does that pass in that is 'invalid'?