Someone a little more intelligent is going to have to translate this into English for me,i assume it's a block id issue between the mod packs
Looks to me like some light detector block in Applied Energistics, RFTools' Endergenic Generator, and a Thermal Expansion Reactant Dynamo are all somehow crammed into the same space.
What did you
do?
If you're trying to copy stuff between worlds that weren't generated with the exact same mods and versions, then that's probably the cause. Since 1.7 removed numeric block and item IDs from some (but not all) of the game's code, each mod's blocks' unlocalized names (such as mcjty.rftools.blocks.endergen.EndergenicBlock) are assigned to "hidden" integer IDs that are stored with, and potentially unique to, each individual save file. If you create two worlds with the exact same versions of the exact same mods, the blocks and items will usually be loaded and assigned in the same order. However, if you do so much as update a single mod to a version that adds a single new block, the new block will be added to the end of the list of blocks in any existing worlds, but will be inserted in the middle somewhere on any new worlds that you create. MCEdit's schematics only make use of the world-specific numeric IDs, and do not, as far as I'm aware, carry any information about the actual blocks involved. Copying stuff within the same world is fine, but trying to copy stuff between worlds will usually scramble what blocks are what.
Do note that vanilla blocks and items are immune to this scrambling, as they are always loaded first. This is probably why MCEdit doesn't make any attempt to unscramble mod blocks' IDs- it's built for editing Vanilla worlds, where there's no need to worry about it.
It's also worth noting that tile entity data seems to be stored somewhere separately of block data (which is essentially a big 3D array of integers), in a format something like "The block at coordinates x, y, and z in dimension w is a modder.mod.unlocalizedName with data [NBT tags]". Maybe. Something like that. I'm guessing.
What I'm guessing happened here is that in a world you created in some modpack, some particular hidden block ID was assigned to the Reactant Dynamo from Thermal Expansion. You then tried to copy a build including this dynamo from that world to a different world, where that particular hidden ID was assigned to RFTools' Endergenic Generator. The separate tile entity data, however, still thought that the block was a reactant dynamo. So, when the endergenic generator tried to look up its tile entity data, perhaps to see what its power level was or to make sure the block it's linked to was actually another endergenic generator, it instead got data for a reactant dynamo. The dynamo data didn't have the particular NBT tags that the endergenic generator expected to see, so when it tried to make use of them, it caused the NullPointerException that crashed your game.
As for how to fix it, or why the crash report also mentions AE... I have no idea.
