Bitterholz

Another way of doing it, is Building your Model as an .obj, loading it via the OBJLoader, and since i suspect you have a TileEntity as you want to store items inside a Block, you can then dynamicly show the Cheeses as Parts of the Model using the ExtendedBlockState and IModelState. Its a rather Simple way of getting high quality dynamic state Models working, I use it e.g. for my Item Pipes. If you need help ill happily provide an example

Hi, its me again Ive got a Problem with a MultiLayer model of a Item Pipe. I split the Old model into the Solid and Translucent parts(now both a unique OBJ-File) to allow rendering the fancy Glass as well, while being able to use the depth buffer for the solid parts(needed since some faces intersect when there is connections in 90° angles). The Block determines its Extended State, wether or not to show a connection to another Block, via its TileEntity, using the IModelState. Now ive debug-moded through the Parts list of that Model State, and noticed the Parts from the glass.obj are not in there, aka never shown in world. Strangely the Model does render the translucent glas in inventory. How would I get the Parts of the glass into the Parts List, or is there another way of getting this working. Here is the code of what i have in place: Block: Tile: Blockstate:

Allright, i figured out i had a derp in my Code, where i was constantly trying to hide parts of the model, spamming the hiding list with entries all fixed now, stuff behaves beautifully!

Logging the calls of the State changes i found out that adding a new pipe to an existing network causes a massive spam of state updates...

Oh that was just me trying to see if it makes a difference(Hint it doesnt) Both times updates DO happen most of the time but they happen awfully slow. Sometimes no update occurs

I see... Well, now im doing if(worldObj.isRemote) { this.worldObj.markBlockRangeForRenderUpdate(this.pos, this.pos); this.worldObj.notifyBlockUpdate(pos, getState(), getState(), 3); this.worldObj.scheduleBlockUpdate(this.pos, this.getBlockType(), 0, 0); markDirty(); } At the end of checkConnections() The Pipes do Update their State, but it does by no means happen immediately as i place a neighboring Pipe. rather just happens slowly over time.

@Draco18s Does the Tile have to be ITickable for that? ive added those calls to my checkConnections(), but it didnt change anything about the behavior. Also what do you refer to with getState() ?

Sadly no change with requiresUpdate(); Pipe Block Code: Tile Code

Trying with @Override public void onNeighborChange(IBlockAccess world, BlockPos pos, BlockPos neighbor) { this.requiresUpdates(); } right now. lets hope thats a success. Also if you mean "Item renders its OBJ model in the hand/UI, then Yes, my Pipe does render its model in hand.

This is a Network of 2 Pipes just been placed. They connect up perfectly. Now when I add in another Pipe: Watch how the New Pipe sets its connection accordingly, while the 2 older ones remain unchanged. Now if i add ANOTHER one like this: See how it Updates the Oldest Pipe but does not form a connection to the newest one.

Hi, Quick Question: How do i enforce an update to the Blockstate when a neighboring block is changed? My Pipe System currently doesnt update its model Correctly if neighboring Pipes are being placed. AKA they are very lazy in updating their State. Any tips?

Shameless Bump

Hi, Ive got a Model of a Item Transporting Pipe I want to render. The model is split into 7 groups for the Center piece and each side Connection. Now ive got this thing to render fine in 1.8 once quite some time ago, using ExtendedState to get my model to render the right Groups of Parts.(Used a Tile Entity to check for neighboring Pipes) Now in 1.10.2 id like to do the same, but were to notice OBJModel.OBJState and OBJModel.Group are both depricated. Can someone hint me how Id go about the rendering of Groups based on the Extended State? or rather what to use instead of OBJModel.OBJState .

Ive not been refering to the qword Bit wrongly. All my Textures are, of course 16x16px in size. Though it apparently made a difference wether the color Depth was 24bit or 32bit. Because 24bit allways return "Bad PNG signature" during stitching for me. Using 32bit color depth mitigates this problem and all textures work as intended.

Its strange tho, back in 1.8, the texture was 24-bit as well but got accepted fine. Guess that doesnt matter now tho. Thanks for the assistance everyone!