This one is weird.
I have added a proxy client world system for rendering other dims client-side.
While this rendering was occurring, bigreactors decided to throw an exception because it didn't like something's metadata. I don't think an exception it the correct response to that; at least not client-side. I'd recommend a fallback and maybe a log message instead.
Regardless, if you have more insight into how I can better sync your things let me know. :)

Exception log below.

java.lang.IllegalArgumentException: Unrecognized metadata
at erogenousbeef.bigreactors.common.multiblock.block.BlockMultiblockGlass.func_149915_a(BlockMultiblockGlass.java:56)
at net.minecraft.block.Block.createTileEntity(Block.java:1446)
at net.minecraft.world.chunk.Chunk.func_150806_e(Chunk.java:850)
at net.minecraft.world.ChunkCache.func_147438_o(ChunkCache.java:97)
at net.minecraft.client.renderer.WorldRenderer.func_147892_a(WorldRenderer.java:163)
at net.minecraft.client.renderer.RenderGlobal.func_72716_a(RenderGlobal.java:1553)
at net.minecraft.client.renderer.EntityRenderer.func_78471_a(EntityRenderer.java:1187)
at com.xcompwiz.mystcraft.client.linkeffects.LinkPanelRenderer.renderWorldToTexture(LinkPanelRenderer.java:224)
at com.xcompwiz.mystcraft.proxyworld.DLPTickEventHandler.onRenderTick(DLPTickEventHandler.java:73)
at cpw.mods.fml.common.eventhandler.ASMEventHandler_422_DLPTickEventHandler_onRenderTick_RenderTickEvent.invoke(.dynamic)
at cpw.mods.fml.common.eventhandler.ASMEventHandler.invoke(ASMEventHandler.java:54)
at cpw.mods.fml.common.eventhandler.EventBus.post(EventBus.java:138)
at cpw.mods.fml.common.FMLCommonHandler.onRenderTickEnd(FMLCommonHandler.java:340)
at net.minecraft.client.Minecraft.func_71411_J(Minecraft.java:992)
at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:887)
at net.minecraft.client.main.Main.main(SourceFile:148)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at net.minecraft.launchwrapper.Launch.launch(Launch.java:135)
at net.minecraft.launchwrapper.Launch.main(Launch.java:28)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.multimc.onesix.OneSixLauncher.launchWithMainClass(OneSixLauncher.java:286)
at org.multimc.onesix.OneSixLauncher.launch(OneSixLauncher.java:376)
at org.multimc.EntryPoint.listen(EntryPoint.java:165)
at org.multimc.EntryPoint.main(EntryPoint.java:54)

I disagree. A crash will be swiftly reported and can then be diagnosed. Fail-quiet behavior will be ignored and can then amplify into other weird, seemingly-unexplainable behavior.

In this case, you now know there's some sort of problem whereby a block can receive incorrect metadata when calling World.getBlockMetadata() while your dimension-overlay system is active. If I'd had it fail silently, we'd probably both get odd bug reports of blocks turning purple or disappearing or something, and not until much further down the line.

So, just guessing here, but it seems that your code is causing client-side tile entities from the proxy world to get created when you're just trying to render the block to generate a link panel. (The tile-entity creation sort-of makes sense, as some types of blocks use TE state info to determine their render state.)

The question is: Are you interested in the actual state of the block in the other dimension, or just in the general shape/form of it? I'm not sure how you'd resolve the former in the general case.

In the latter case, you may need to find some way to get the WorldRenderer to not call createTileEntity when you're trying to render a link panel, and hope that a pure blockID/metadata render is sufficient.

I see your point, but I still dislike killing a player's game during a render pass. Particularly, I don't think your argument applies well to modding.

Many TEs won't ever render properly if I don't get them their data, and they would probably crash/fail more. Fortunately, getting the TE packet is pretty easy. The TE data is synced, I just seem to have a bug in my chunkdata packing/unpacking. There have been a couple metadata errors and a few cases of chunks being raised or lowered.

Fortunately I can insulate this all to prevent crashes and clean up state anyway, so if it crashes during my render the player should at most experience a brief screen flicker.

Thanks :)