This is from the console

http://pastebin.com/j6AKyMaD

Crashlog: http://pastebin.com/dQenHykx

Currently IMultipartTile has most of the TileEntity methods in it with implementation that does the call via getTileEntity.

This makes sense when you are implementing IMultipartTile in a separate class that wraps an existing TileEntity. But when they are implemented by the same class it gets very annoying, at least in scala, because you have to manually override every single method like this

override def getWorld: World = super[TileEntity].getWorld

Otherwise either the compiler complains about conflicting inheritance or you get infinite recursion that never proceeds to the base method in TileEntity (YourClass.whatever -> IMultipartTile.whatever -> calls getTileEntity() and gets YourClass ->YourClass.whatever -> repeat until StackOverFlowError)

Moreover i'm not sure why those methods have to be there to begin with. Anything that calls them can just call getTileEntity().whatever.

All of that also applies to Block/IMultipart, though to lesser extent as it only has a handful of methods like that, unlike IMultipartTile which has all of them.

Also i suspect having the same names will in some cases trigger this bug when reobfuscating - md-5/SpecialSource#12, which i don't think was ever fully fixed.

My suggestion is to remove all the vanilla methods from IMultipart/IMultipartTile and leave only stuff that needs to be aware of multipart data. The normal methods can be called via getBlock/getTileEntity.

Edit: It's less of a problem for java mods since it prioritizes the implementation in a superclass over the default in the interface.

https://gist.github.com/74c837a8998da1a54320a2e7f6f8bc16

(I'm trying to create a memory cell for a brainfuck computer's memory that can shift forward and backward)

This error happen when we try to break a Mekanism's cable. (I'm not alone with this glitch)

Minecraft version: 1.10.2
Forge version: 12.18.2.2118
MCMultiPart version: 1.3.0
Mekanism version: 9.2.0.292

Crash-Report: http://pastebin.com/rfGq1aG0

When Update packets are sent it seems that MCMP orphans any parts and just re-creates them from scratch, this isn't ideal, is there anyway to not do this? or at least have some trigger to tells a part that its been orphaned so it can clean itself up?

Code in question,

Placing a cable from Fluxed Redstone produces this threading-related error:

java.util.ConcurrentModificationException
 at com.google.common.collect.HashBiMap$Itr.checkForConcurrentModification(HashBiMap.java:339)
 at com.google.common.collect.HashBiMap$Itr.hasNext(HashBiMap.java:345)
 at reborncore.mcmultipart.multipart.MultipartContainer.getExtendedStates(MultipartContainer.java:484)
 at reborncore.mcmultipart.block.BlockMultipartContainer.getExtendedState(BlockMultipartContainer.java:399)
 at reborncore.mcmultipart.block.BlockMultipartContainer.getExtendedState(BlockMultipartContainer.java:66)
 at net.minecraft.client.renderer.BlockRendererDispatcher.func_175018_a(BlockRendererDispatcher.java:80)
 at net.minecraft.client.renderer.chunk.RenderChunk.func_178581_b(RenderChunk.java:277)
 at net.minecraft.client.renderer.chunk.ChunkRenderWorker.func_178474_a(ChunkRenderWorker.java:118)
 at net.minecraft.client.renderer.chunk.ChunkRenderWorker.run(ChunkRenderWorker.java:46)
 at java.lang.Thread.run(Thread.java:745)

It looks like the client or server thread changed MultipartContainer.partMap while the rendering thread was iterating through it?

RebornCore embeds a copy of MCMultipart that appears to correspond to 91bb73d.

BlockCoverable#collisionRayTrace calls BlockCoverable#getSelectedBoundingBoxDefault which calls Block#getSelectedBoundingBox which is clientside only...

The workaround for this is to remove the call to Block#getSelectedBoundingBox and replace it with:

@Override
public AxisAlignedBB getSelectedBoundingBoxDefault(IBlockState state, World worldIn, BlockPos pos) {
    return state.getBoundingBox(worldIn, pos).offset(pos);
}

(which is the exact same code as in Block#getSelectedBoundingBox, but just to bypass the vanilla issue)

client is using forge 1.9 build 1811

fml log http://paste.ee/p/KgtH5
crash http://paste.ee/p/HlxX2

I think it'd be useful to have replaceable parts, like tall grass. I'd use it so the top of my catwalks stair block can be replaced with a normal block if all the sides are disabled.

SonarSonic/Bagelsmore#5

Determined that removing MCMultipart made placing blocks placeable again.

Calling MultipartHelper#canAddPart seems to crash due to a temporary tile trying to set a blockstate in a null-world.
I assume that this temporary tile should not be added as a listener to the part container, but you'll probably know better what's going on than I do ;-)

MCMP version 1.2.0_71
Crashlog: http://pastebin.com/UmiKiVTC

I'm told by the Mekanism dev @AidanBrady that this is an issue with MultiPart?

Here's the Mek issue I logged:

mekanism/Mekanism#3751

The problem is when any of his pipes are placed OR removed there is major latency between the time you click to place and the time it actually places. Super laggy.

Can you please look at the linked issue and address? If not a Multipart issue, any help in "where to take the issue" would be appreciated.

MC 1.10.2
MCMultiPart 1.2.1
Mekanism 9.1.1
Forge 2065

Having similar issue with EnderIO but haven't got confirmation from that dev that he uses multipart for anything. Will update when I hear back on that one.

Thanks :)

Hello Amadornes,

First of all, I hope I spelled your name correctly lol. Second of all, I have an idea, and would like to help you. I am absolutely in love with this, Super Circuit Maker and Chisels&Bits. But I would like to increase the amount of blocks in C&B. It's not your mod, but the mod-author said that basically everything compatible with this, would be compatible with C&B. Seeing as I can't mod yet, I would like it if there was an editor for MCMultiPart, similar to MCreator but not for making mods, just for adding some blocks. I know that that is a very hard task, so I would like to help you by making the editor itself. If you could help me by telling me how to add new blocks to MCMultiPart, I might be able to make an editor for this, that could make a mod that adds the new blocks desired, so that people can make their own mods. Long story short: A program that provides a GUI to make a mod that adds new blocks that are compatible with MCMultiPart, to make sure people like me can add tiny chests and rails :P.

Thanks for reading all this.

Sincerely,
Luuk, Team TaL Wolf

I can probably just work around the issue at the moment, but I think you're missing a "&& block.canPlaceBlockOnSide(world, pos, facing)" in ItemBlockMultipart#placeBlockAtTested.

I crash every time I use the elevator when I have Optifine installed, without Optifine it works and McJty said it's not his mod and that its your mod that crashed the game

I'm pretty sure you've already considered this, but it'd be great if you could place a Multipart inside of liquids.

Hi Client Crash and get this crash log : http://pastebin.com/C3MKNEDR

Hey,

I'm developing a new mod around this framework which is fantastic to work with btw.
My only question is I don't see a way to prevent a Multiblock being destroyed when it is left clicked,
I thought PartEvents would be cancelable, or if there was an interface which allows you to override this behaviour. Although I may have missed this.

Thank you for all your work :)

I suggest adding a simulate parameter to the convert() methods in IPartConverter and IReversePartConverter.
The IPartConverter for example is always called twice, once in the context of MultipartHelper#canAddPart() and once in MultipartHelper#addPart().

I need this for a converter that can drop items is some special cases, and I don't want these items to drop twice.

An alternative would be to add a method canConvert() to the converter interfaces instead.

I've been having a problem with multipart light levels

When two slab furnaces are placed in the same block and one of them is activated it looks like this:

When one slab furnace is removed, it looks like this:

But when another furnace slab is placed in the block, it still looks normal and doesn't revert to the original state:

All the code is available here.

Missing getParts on IMultipartContainer api

It would be great to have API documentation.

If that already exists, and I haven't found it, then consider this a request to add it to README.md. Otherwise... well, I don't expect it'd be quick to write, but it'd help adoption.

Every time I try to run minecraft with Mekanism-1.10.2-9.2.1.295 it says "Mekanism DepLoader was unable to download required library MCMultiPart-experimental-2.0.0_88-universal.jar "

Hello,

I am getting some error messages in the console. The mod loads okay, but I wanted to bring it to your attention.

1. [06:41:56] [Client thread/ERROR]: Exception loading model for variant mcmultipart:multipart#ticking=false
   net.minecraftforge.client.model.ModelLoaderRegistry$LoaderException: Exception loading model mcmultipart:multipart#ticking=false with loader VariantLoader.INSTANCE, skipping
2. [06:41:56] [Client thread/ERROR]: Exception loading model for variant mcmultipart:multipart#ticking=true
   net.minecraftforge.client.model.ModelLoaderRegistry$LoaderException: Exception loading model mcmultipart:multipart#ticking=true with loader VariantLoader.INSTANCE, skipping

Full Log

Sometimes when i place a Pipe or a Conduit from Mekanism or an other mod, this will happen:

---- Minecraft Crash Report ----

WARNING: coremods are present:
LoadingHook (Mekanism-1.10.2-9.1.1.290.jar)
FMLPlugin (InventoryTweaks-1.61-58.jar)
MalisisCorePlugin (malisiscore-1.9.4-4.1.1.jar)
Contact their authors BEFORE contacting forge

// Would you like a cupcake?

Time: 9/5/16 8:04 PM
Description: Tesselating block in world

java.util.ConcurrentModificationException
at com.google.common.collect.HashBiMap$Itr.checkForConcurrentModification(HashBiMap.java:339)
at com.google.common.collect.HashBiMap$Itr.hasNext(HashBiMap.java:345)
at mcmultipart.multipart.MultipartContainer.getExtendedStates(MultipartContainer.java:484)
at mcmultipart.block.BlockMultipartContainer.getExtendedState(BlockMultipartContainer.java:402)
at mcmultipart.block.BlockMultipartContainer.getExtendedState(BlockMultipartContainer.java:66)
at net.minecraft.client.renderer.BlockRendererDispatcher.func_175018_a(BlockRendererDispatcher.java:80)
at net.minecraft.client.renderer.chunk.RenderChunk.func_178581_b(RenderChunk.java:278)
at net.minecraft.client.renderer.chunk.ChunkRenderWorker.func_178474_a(ChunkRenderWorker.java:119)
at net.minecraft.client.renderer.chunk.ChunkRenderWorker.run(ChunkRenderWorker.java:47)
at java.lang.Thread.run(Thread.java:745)

A detailed walkthrough of the error, its code path and all known details is as follows:

-- Head --
Thread: Client thread
Stacktrace:
at com.google.common.collect.HashBiMap$Itr.checkForConcurrentModification(HashBiMap.java:339)
at com.google.common.collect.HashBiMap$Itr.hasNext(HashBiMap.java:345)
at mcmultipart.multipart.MultipartContainer.getExtendedStates(MultipartContainer.java:484)
at mcmultipart.block.BlockMultipartContainer.getExtendedState(BlockMultipartContainer.java:402)
at mcmultipart.block.BlockMultipartContainer.getExtendedState(BlockMultipartContainer.java:66)

-- Block being tesselated --
Details:
Block type: ID #348 (tile.null // mcmultipart.block.BlockMultipartContainer)
Block data value: 0 / 0x0 / 0b0000
Block location: World: (1660,238,-1033), Chunk: (at 12,14,7 in 103,-65; contains blocks 1648,0,-1040 to 1663,255,-1025), Region: (3,-3; contains chunks 96,-96 to 127,-65, blocks 1536,0,-1536 to 2047,255,-1025)
Stacktrace:
at net.minecraft.client.renderer.BlockRendererDispatcher.func_175018_a(BlockRendererDispatcher.java:80)

-- Affected level --
Details:
Level name: MpServer
All players: 1 total; [EntityPlayerSP['ZeetherTX'/983933, l='MpServer', x=1660.35, y=237.00, z=-1034.04]]
Chunk stats: MultiplayerChunkCache: 121, 121
Level seed: 0
Level generator: ID 01 - flat, ver 0. Features enabled: false
Level generator options:
Level spawn location: World: (1670,4,-1035), Chunk: (at 6,0,5 in 104,-65; contains blocks 1664,0,-1040 to 1679,255,-1025), Region: (3,-3; contains chunks 96,-96 to 127,-65, blocks 1536,0,-1536 to 2047,255,-1025)
Level time: 12059 game time, 12059 day time
Level dimension: 0
Level storage version: 0x00000 - Unknown?
Level weather: Rain time: 0 (now: false), thunder time: 0 (now: false)
Level game mode: Game mode: creative (ID 1). Hardcore: false. Cheats: false
Forced entities: 2 total; [EntityPlayerSP['ZeetherTX'/983933, l='MpServer', x=1660.35, y=237.00, z=-1034.04], EntityMinecartChest['Minecart with Chest'/983837, l='MpServer', x=1601.50, y=123.06, z=-1002.50]]
Retry entities: 0 total; []
Server brand: fml,forge
Server type: Integrated singleplayer server
Stacktrace:
at net.minecraft.client.multiplayer.WorldClient.func_72914_a(WorldClient.java:498)
at net.minecraft.client.Minecraft.func_71396_d(Minecraft.java:2660)
at net.minecraft.client.renderer.chunk.ChunkRenderWorker.run(ChunkRenderWorker.java:57)
at java.lang.Thread.run(Thread.java:745)

-- System Details --
Details:
Minecraft Version: 1.10.2
Operating System: Windows 7 (amd64) version 6.1
Java Version: 1.8.0_25, Oracle Corporation
Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation
Memory: 1853971864 bytes (1768 MB) / 3200253952 bytes (3052 MB) up to 5726797824 bytes (5461 MB)
JVM Flags: 2 total; -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xmx6G
IntCache: cache: 0, tcache: 0, allocated: 13, tallocated: 95
FML: MCP 9.32 Powered by Forge 12.18.1.2076 Optifine OptiFine_1.10.2_HD_U_C3 27 mods loaded, 27 mods active
States: 'U' = Unloaded 'L' = Loaded 'C' = Constructed 'H' = Pre-initialized 'I' = Initialized 'J' = Post-initialized 'A' = Available 'D' = Disabled 'E' = Errored
UCHIJAAAAAAAAAAAAAA mcp{9.19} Minecraft Coder Pack
UCHIJAAAAAAAAAAAAAA FML{8.0.99.99} Forge Mod Loader
UCHIJAAAAAAAAAAAAAA Forge{12.18.1.2076} Minecraft Forge
UCHIJAAAAAAAAAAAAAA BiomesOPlenty{5.0.0.2080} Biomes O' Plenty
UCHIJAAAAAAAAAAAAAA Chameleon{1.10-2.1.7} Chameleon
UCHIJAAAAAAAAAAAAAA mcmultipart{1.2.0_74} MCMultiPart
UCHIJAAAAAAAAAAAAAA chiselsandbits{12.1} Chisels & Bits
UCHIJAAAAAAAAAAAAAA inventorytweaks{1.61-58-a1fd884} Inventory Tweaks
UCHIJAAAAAAAAAAAAAA JEI{3.9.0.246} Just Enough Items
UCHIJAAAAAAAAAAAAAA journeymap{1.10.2-5.2.4} JourneyMap
UCHIJAAAAAAAAAAAAAA malisiscore{1.9.4-4.1.1} MalisisCore
UCHIJAAAAAAAAAAAAAA malisisdoors{1.9.4-5.0.4} MalisisDoors
UCHIJAAAAAAAAAAAAAA mantle{1.10.2-0.10.4.jenkins163} Mantle
UCHIJAAAAAAAAAAAAAA Mekanism{9.1.1} Mekanism
UCHIJAAAAAAAAAAAAAA MekanismGenerators{9.1.1} MekanismGenerators
UCHIJAAAAAAAAAAAAAA MekanismTools{9.1.1} MekanismTools
UCHIJAAAAAAAAAAAAAA reborncore{2.6.2.27} RebornCore
UCHIJAAAAAAAAAAAAAA reborncore-mcmultipart{2.6.2.27} reborncore-MCMultiPart
UCHIJAAAAAAAAAAAAAA rftools{5.21} RFTools
UCHIJAAAAAAAAAAAAAA StorageDrawers{1.10.2-3.2.6} Storage Drawers
UCHIJAAAAAAAAAAAAAA tconstruct{1.10.2-2.4.0.jenkins325} Tinkers' Construct
UCHIJAAAAAAAAAAAAAA techreborn{1.4.0.45} TechReborn
UCHIJAAAAAAAAAAAAAA tesla{1.2.1.49} TESLA
UCHIJAAAAAAAAAAAAAA VeinMiner{0.34.1_1.9-73be663} Vein Miner
UCHIJAAAAAAAAAAAAAA VeinMinerModSupport{0.34.1_1.9-73be663} Mod Support
UCHIJAAAAAAAAAAAAAA icse{1.1.0.0} I Can See Everything
UCHIJAAAAAAAAAAAAAA wawla{2.3.0.202} What Are We Looking At
Loaded coremods (and transformers):
LoadingHook (Mekanism-1.10.2-9.1.1.290.jar)

FMLPlugin (InventoryTweaks-1.61-58.jar)
invtweaks.forge.asm.ContainerTransformer
MalisisCorePlugin (malisiscore-1.9.4-4.1.1.jar)
net.malisis.core.util.chunkcollision.ChunkCollisionTransformer
net.malisis.core.util.chunkblock.ChunkBlockTransformer
net.malisis.core.renderer.transformer.MalisisRendererTransformer
net.malisis.core.renderer.icon.asm.TextureMapTransformer
net.malisis.core.util.clientnotif.ClientNotifTransformer
GL info: ERROR RuntimeException: No OpenGL context found in the current thread.
Pulsar/tconstruct loaded Pulses:

• TinkerCommons (Enabled/Forced)
• TinkerWorld (Enabled/Not Forced)
• TinkerTools (Enabled/Not Forced)
• TinkerSmeltery (Enabled/Not Forced)
• TinkerGadgets (Enabled/Not Forced)
• TinkerOredict (Enabled/Forced)
• TinkerIntegration (Enabled/Forced)
• TinkerFluids (Enabled/Forced)
• TinkerMaterials (Enabled/Forced)
• chiselsandbitsIntegration (Enabled/Not Forced)

Launched Version: 1.10.2-forge1.10.2-12.18.1.2076
LWJGL: 2.9.4
OpenGL: ERROR RuntimeException: No OpenGL context found in the current thread.
GL Caps: Using GL 1.3 multitexturing.
Using GL 1.3 texture combiners.
Using framebuffer objects because OpenGL 3.0 is supported and separate blending is supported.
Shaders are available because OpenGL 2.1 is supported.
VBOs are available because OpenGL 1.5 is supported.

Using VBOs: Yes
Is Modded: Definitely; Client brand changed to 'fml,forge'
Type: Client (map_client.txt)
Resource Packs:
Current Language: English (US)
Profiler Position: N/A (disabled)
CPU: 4x Intel(R) Core(TM)2 Quad CPU Q6700 @ 2.66GHz
OptiFine Version: OptiFine_1.10.2_HD_U_C3
Render Distance Chunks: 5
Mipmaps: 4
Anisotropic Filtering: 1
Antialiasing: 0
Multitexture: false
Shaders: null
OpenGlVersion: 4.5.0 NVIDIA 372.70
OpenGlRenderer: GeForce GTX 750 Ti/PCIe/SSE2
OpenGlVendor: NVIDIA Corporation
CpuCount: 4
Hopefully this will be fixed in a later update ;)

ZeetherTX

MC crash if the player left click a multipart with a empty hand.

It seems like ItemStack=null is not handled in the getStrength() method in Multipart.java

Is there a way to make levers and torches compatible with MCMultiPart? For example, make Simple Covers covers be able to be placed in the same block space as a lever, or Chisel and Bits bits?

That would be much appreciated.

RayTraceResult clearly takes a MovingObjectPosition, but reTrace casts it to a PartMOP, maybe it should enforce PartMOP instead?

java.lang.ClassCastException: net.minecraft.util.MovingObjectPosition cannot be cast to mcmultipart.raytrace.PartMOP
at mcmultipart.block.BlockMultipart.reTrace(BlockMultipart.java:313)
at mcmultipart.block.BlockMultipart.addDestroyEffects(BlockMultipart.java:246)

When rendering a model in a GUI, this crash occurs http://pastebin.com/fsHtnVwn

Crash: http://pastebin.com/k3aMbumg

All I can think of is maybe add a te != null check there as that's the only thing i can see it crashing on.

Then again, maybe its my block

Caused by: java.lang.NullPointerException
    at mcmultipart.block.BlockCoverable.canConnectRedstone(BlockCoverable.java:399) ~[BlockCoverable.class:?]
    at net.minecraft.block.BlockRedstoneWire.canConnectTo(BlockRedstoneWire.java:454) ~[BlockRedstoneWire.class:?]
    at net.minecraft.block.BlockRedstoneWire.isPowerSourceAt(BlockRedstoneWire.java:431) ~[BlockRedstoneWire.class:?]
    at net.minecraft.block.BlockRedstoneWire.getWeakPower(BlockRedstoneWire.java:403) ~[BlockRedstoneWire.class:?]
    at net.minecraft.block.state.BlockStateContainer$StateImplementation.getWeakPower(BlockStateContainer.java:381) ~[BlockStateContainer$StateImplementation.class:?]
    at net.minecraft.world.World.getRedstonePower(World.java:3470) ~[World.class:?]

Error is in this method:

    @Override
    public final boolean canConnectRedstone(IBlockState state, IBlockAccess world, BlockPos pos, EnumFacing side) {

        if (side == null) return false;
        IMicroblockContainerTile tile = getMicroblockTile(world, pos);
        MicroblockContainer container = tile != null ? tile.getMicroblockContainer() : null;
        if (container.getPartContainer().canConnectRedstone(side)) return true;
        return canConnectRedstoneDefault(state, world, pos, side, container);
    }

You appear to be accessing container when it is null.

with MCMultiPart-1.3.0-universal crash mineing mek cable with MCMultiPart-1.2.1-universal no crash here is the crash report http://pastebin.com/FftDwSL2

Instead of making 2 TileEntity classes which are very limited to ticking TileEntities just make a differend system its way more modular & it can change very easy between none ticking & ticking.

Simply: Add a Shifted World Tick (using the WorldTickEvent) which asks then if the multipart ticks (adding a custom canUpdateFunction) if that is returned false it deletes it out of the TickingTileEntityList or adding it to it. With that you also can allow clientTileEntity Ticks and do not have to swtich TileEntityClasses...
(Which with my Experience causes only trouble)

`[20:53:05] [Client thread/INFO] [STDOUT/]: [net.minecraft.init.Bootstrap:func_179870_a:529]: ---- Minecraft Crash Report ----

WARNING: coremods are present:
CorePlugin (Fluxed Redstone-1.3.0.31.jar)
BetterFoliageLoader (BetterFoliage-MC1.8.x-2.0.3.jar)
FMLPlugin (InventoryTweaks-1.60-beta-38.jar)
MovingWorldCoreMod (movingworld-MC1.8.9-INDEV-E-full.jar)
NowWithRendering (redstonepaste-mc1.8.8-1.7.2.jar)
Contact their authors BEFORE contacting forge

// I bet Cylons wouldn't have this problem.

Time: 3/4/16 8:53 PM
Description: Tesselating block model

java.lang.NullPointerException: Tesselating block model
at mcmultipart.client.multipart.ModelMultipartContainer.func_177551_a(ModelMultipartContainer.java:49)
at ConnectedTextures.getNeighbourIcon(ConnectedTextures.java:886)
at ConnectedTextures.isNeighbour(ConnectedTextures.java:853)
at ConnectedTextures.getConnectedTextureCtm(ConnectedTextures.java:657)
at ConnectedTextures.getConnectedTexture(ConnectedTextures.java:407)
at ConnectedTextures.getConnectedTextureSingle(ConnectedTextures.java:234)
at ConnectedTextures.getConnectedTextureMultiPass(ConnectedTextures.java:180)
at ConnectedTextures.getConnectedTexture(ConnectedTextures.java:101)
at net.minecraft.client.renderer.BlockModelRenderer.renderModelAmbientOcclusionQuads(BlockModelRenderer.java:261)
at net.minecraft.client.renderer.BlockModelRenderer.renderModelAmbientOcclusion(BlockModelRenderer.java:130)
at net.minecraft.client.renderer.BlockModelRenderer.func_178267_a(BlockModelRenderer.java:66)
at net.minecraft.client.renderer.BlockModelRenderer.func_178259_a(BlockModelRenderer.java:52)
at net.minecraft.client.renderer.BlockRendererDispatcher.func_175018_a(BlockRendererDispatcher.java:109)
at gcewing.architecture.BaseModClient$CustomBlockRendererDispatcher.func_175018_a(BaseModClient.java:547)
at mods.betterfoliage.client.Hooks.renderWorldBlock(Hooks.kt:88)
at net.minecraft.client.renderer.chunk.RenderChunk.func_178581_b(RenderChunk.java:287)
at net.minecraft.client.renderer.chunk.ChunkRenderWorker.func_178474_a(SourceFile:78)
at net.minecraft.client.renderer.chunk.ChunkRenderWorker.run(SourceFile:38)
at java.lang.Thread.run(Thread.java:745)

`

fml log: http://paste.ee/p/wvzQ3
crash report: http://paste.ee/p/ZCY3J

mekanism/Mekanism#3361

A simple array with integer indexes would work the same way, and would reduce computational overhead of looking through the a bimap, as well as reduce memory footprint and complexity.

Unless I'm missing some magic happening behind the scenes (that has only been added in 1.9), every multipart tile entity is tickable. This is obviously suboptimal. In the case of covering (OC) cables, this will turn previously not ticking blocks into ticking ones, e.g.

Are there plans on avoiding this? If not, I propose having the tile entity be non-ticking and having a tick event handler that updates a list of all live ticking parts (alike the list of ticking tile entities managed by Minecraft). This would also do away with having to iterate all parts every tick and check if they are tickable. The other option might be an alternative non-ticking tile entity and swapping tile entities on demand, but that seems less robust to me.

Game crashes when looking at a MultiPart block such as a microblock from Simple Covers, and Mekanism cables, whilst also using the Placement Preview mod, which renders a preview of the block you're about to place. It crashes when trying to render the preview of the block.

To quote @maruohon:

"Seems that MCMultipart is not checking that the world is actually a WorldServer before trying to cast it to one."

Full crash report: pastebin.com/CHEhbPYW

Placement Preview version: 0.1.0
Minecraft version: 1.10.2
Forge version: 12.18.1.2046

Need Block.isAABBInsideMaterial / Block.isEntityInsideMaterial for Multiparts.

Woops, I broke something!
Log: https://gist.github.com/ruyanve/1a5d3e8ce105b0f08b95548ac7836c98

ref ticket here: mekanism/Mekanism#3369

There is a check here that makes only parts that take the top slot, or no slots work with that interface.

Is there any specific reason for that?

I have a centered column microblock in my covers mod that would be nice to be able to place a torch on, but it can't be in the top slot as covers should be placeable together with it.

I'm getting a bunch of warnings like

[23:08:28] [Client thread/ERROR] [FML]: Exception loading model for variant covers:corner#multipart for blockstate "minecraft:air"

But all my parts are using "covers:microblock" as their model (since it's shared between them) and return that from getModelPath while "covers:corner" is the type of the part.

In game they use the correct model, so i guess MCMP is just registering the wrong names somewhere along with the right one.

http://pastebin.com/YKGaSeLT

TeamBR-Modding/Neotech#190

when using a custom model that makes use of uv setting, MCMP ignores it.

the thing on the left is the multipart, and is meant to be a scaled down form of the thing on the right. it renders properly in the hand

Grouping together all part changes might be worth considering, as the overhead per packet can quickly add up, especially if you have a large number of parts per tile. Heres how I think it can be handled better.

1. Don't use the built in tile update method on tile entities. Chunk watch/unwatch events can be used to send tile descriptions to clients as necessary. As players enter chunks, all multipart tiles in the chunk are asked to write data to a single buffer which is flushed at end-of-tick

2. Part data updates which contain small, incremental updates (not the full description of the part, as that would be handled above) would also be handled the same way. All part updates for the entire chunk would be written to a single buffer and flushed end-of-tick. Should a part wish to send a full description, that can easily be handled by said part.

CB's ForgeMultipart had a similar implementation to this, and it had been tested and proven to drastically reduce packet overhead especially when you had a large number of multipart tiles in a small area that were rapidly changing. I am quite familiar with it's networking system and I can quickly write this up for you for your consideration.

For an example, consider a redstone circuit consisting of 500 wires. Each one needs to write a byte to describe its signal strength. That would mean sending 500 packet updates, each with an overhead more than double the actual data.

Pretty much everything else has been switched out for ResourceLocations (in particular the part factories as well), so it seems somewhat inconsistent to have the registry take strings instead of ResourceLocations (i.e. registerPart and registerPartFactory). Since they get converted to ResourceLocations internally anyway, I'd suggest a compatibility overload still taking strings, but the main methods take a ResourceLocation instead?

Edit: and PartPlacementWrapper.register, too, I guess?

I have an ItemMultiPart that places a scaffold part, the thing is that part can be immediately converted to a normal block. Whenever I place it on it's own it doesn't appear client-side until an update is caused nearby (no raytrace so it isn't just a rendering issue) and this error is fired.

A very similar issue is the following: If I have the same scaffold block and remove the last part sharing the block space it throws this error, though it seems to work ok. (Charset wires going around a corner don't update so I think the parts aren't being notified that they're removed)

This also brings up the fact that in the convertToBlock method I have to remove all the parts from the container. I would think setting the block would do that.

I found a crash when connecting a CharSet redstone cable next to a block containing a redstone cable and a some Chisel&Bits bits.

The block contains the redstone cable and some pink wool bits. When I place a redstone cable on the currently highlighted block, it crashes with the following crash log: http://paste.ee/p/1sCvm

Upon reloading the world, everything is fine, with the cables placed and connected as expected. The crash also occurs if the wires are placed in the opposite order, with the bits already in place.