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

Perfect illustration of the implicit difference between buzzwords and jargon. Also your typical minecraft user will not be packing a Ti. A metric shit ton of them use soley integrated which is why barebones GL must be used. And correct me if I'm wrong but a Cocoa variant is already made for pocket edition.

You'll need to trace back and find what matrix mode was being used previously and set it back to that when you're done then

I'd need to see the whole class so I can see the ordering of your calls but you've forgotten to pop part of the stack and have fucked the GLState, plain and simple here (done this countless times myself ;]) IE you call GlStateManager.disableTexture2D(); I've got no clues if you've reenabled the textures or not

I will definitely back this. Mostly because it's a nightmare starting out with 1) You're dealing with byte code which works on a token stack, totally different approaches 2) Errors are sparse and often difficult to read in comparison to 'normal java errors' 3) Very little documentation to be found on the matter. Took me ages to track down the references I needed for it to click 4) Getting help with it will be next to impossible since it takes a lot off back and forth (effort) to troubleshoot something you're being discouraged from doing anyways 5) You can easily mess something up that will take a ton of debugging to actually present itself as an issue 6) Murphy is lurking

Your pattern is an object and it's looking for a char... You're going to need a different workaround because that pattern method won't work

Made a PR on this a few weeks back and it got shot down because expansion here is bad for performance. https://github.com/MinecraftForge/MinecraftForge/pull/2458 In short you can't do it easily. Even swapping out the render item instances with your own results in a lot of issues caused by the surplus of private methods and GLState headaches. The other option is ASM- which is frowned upon. I've recently written a class transformer for implementing a wrapper for custom effects that does the job but it's skewed towards shader use at the moment. Thinking about pushing it out as an API to make the handling of effect passes an optional thing if there's the demand for it.

Sounds like you're not registering the itemblock to the ItemMesher Nevermind it's just missing. What do your JSONs look like?

Are you referring to how grass has biome dependent coloring? Or are you trying for more of a highlight effect?

It's actually not actually all that difficult. Just will take a bit of time to learn what is what since most of what you want will turn out to be adding one list of bake quads to another one and either caching those lists or combining them on the fly if you have a metric shit ton of combinations and memory is an issue.

https://en.m.wikibooks.org/wiki/OpenGL_Programming/Motion_Blur Works in more than just Minecraft; it just needs to be applied in the same fashion