RANKSHANK

ItemStack.setTagCompound(NbtTagCompound)

Make sure you attach this to the itemstack too.

Reloading the world sounds like a desync issue... or you're using a global value to set the on/off flags on cap init And you're not changing the capabilities, you're just denying access when a particular side is 'off'. All you should have to do is return false for hasCapability() and null for getCapability() on the corresponding sides.

Face culling is based on the vertex draw order.... You'd have to have the opposite facing quad in the same area as the quad itself, so you'd have the northern quad, with a ' reflected' southern quad with the internal texture in the same space. Even when you're inside the block the direction is preserved, so there's no reason you can't have a southern face on the northern end of the block. even if it's 'inside' of the block, if that makes sense.

Buffer builder is not the way to go Buffer builder only creates things according to the VertexFormat that's assigned to it when it's initialized. A quick look provides BLOCK.addElement(POSITION_3F); BLOCK.addElement(COLOR_4UB); BLOCK.addElement(TEX_2F); BLOCK.addElement(TEX_2S); So per vertex you have a 3 float component for the vertex position, a 4 unsigned byte component for the color and transparency of the vertex, a 2 float component for the texture UV of the vertex, and a 2 short component for the light map coords of the vertex, that last bit being just an assumption Each primitive/face will have 4 vertices, so 4 sets of that info, as this is all rendered using GL_QUADS. With all that said I think you'd want to do your .png building in game. Because getting the texture UV's to function correctly is going to be a nightmare in an external program... you could export the texture sheet, but then if you have to load more images up at a later date it'd be up to the TextureAtlas stitcher to maintain the same sprite order, which wouldn't be too bad without other mods in the mix, and granted you're using the same version of minecraft, updates will likely mess the order up Also note things that directly manipulate the GL state, like chests, signs, and banners, either won't be included in the buffer, or will have only the static component baked into it, depending on the how they're rendered So overall I'd say your best bet would be something like using a custom dimension with all the unnecessary bits removed, that clones itself from the target world. Then I'd look into how to capture scenes in opengl for things like in game security cameras, and use that to write the captures to a png.

*Rolls for attention* It's a one

Jesus christ man. It's not possible for one world survival servers. Those other servers load one world per core since each core can handle one logical thread at a time, leaving the additional cores for things like file loading and networking. A single world's logic IS NOT run on more than one thread. If they do have something for the premium IE Shotbow servers that alleviate some of the load on a separate thread (scoreboard/networking related shizz most likely), then that is an in house solution. Having multiple, consecutive threads working on the same data in a game is a concurrent access filled nightmare, and half of the life cycle you'd be waiting on some form of access lock to be released when accessing common content. TLDR; Forge does not, and almost certainly(I'm speaking logistically here; not on their behalf) will not split up a world's logical thread for multicore support.

I think the question really is what suits your fancy? Sounds like you have a portfolio to tout so getting in on a project as a code monkey won't be too much of a challenge, and as far as pure ideas go there's a huge dumping ground on Curse's minecraft forum. It's more hinged on what you're good at, and what you're interested in doing. Hell if you're up for it you can bash out a few PR's to forge's git and build up forge itself. As far as contacts go, if you're interested the IRC has a few hours a day when it's full of traffic.

Programs have to be written to take advantage of multiple cores. You'll run into the same issue with vanilla. And multithreading Minecraft properly is well out of the scope of forge/modding in general as it's a literal full engine rewrite.

... And you can't just check if the NBT data pertains to an entity? In otherwords if entity data exists?

https://athenadennisfreelancewriter.files.wordpress.com/2014/02/bug_vs_feature.gif[/img] This feels relevant.

I'm more getting at how to turn the flag off when the item ceases to be held such as when thrown, moved in inventory, on player death, etc. I'm not aware of whether or not a final tick is sent to the item somewhere before it's unequipped though

So... like how a book opens a GUI to open on a right click? Or are you using an Item that isn't yours to modify?

This is the method public void onUpdate(ItemStack stack, World worldIn, Entity entityIn, int itemSlot, boolean isSelected) Probe around the isSelected flag. You'll probably need to be hacky to make sure you can revert the effect flag though.

It's just a rim shader that's being applied