HalibutBarn

The 'blinking' and weird noises could have been the MFE running out of stored energy because you're consuming more than the solar panels are generating, which could easily happen with that many machines. In that case, the machines start turning on and off very rapidly because not all of them are getting the energy they need each tick.

Are you using the NoLagg plugin? I can't be 100% sure it's related, but I tried using it a while back and very soon after users found a few chunks that were out of place but already had some torches placed on them, like they were copied from somewhere else on that map. That was a bit too coincidental for me so I disabled NoLagg and it didn't happen again.

From sct's commits:

You can't force the GUI to go away on the client, but they won't be able to cheat with it anymore.

Works fine for me. Just install the Essentials .jar files in the plugin directory, and enable the sign types you want in the config.yml (by default, all sign types are disabled).

If your vanilla world is Minecraft 1.2.5, you'll need to use the Tekkit 3.0.4 server. 2.1.1 doesn't understand the new map format.

I should note that I haven't actually tested that conversion process with a 2.0 server, just with 2.1.1. Looking at the configs, they should be close enough, the only thing that looks like it might be trouble is that the block ID for Forestry growers is different, and they'll wind up becoming ComputerCraft peripherals. You can have it properly remove them by changing the "255 -> 0" line in Patch.txt to "208 -> 0".

Items registered through Forge get 256 added to their values, so the teleport pipe item ID of 4047 in the config file becomes 4047+256=4303 in the actual world.

Increase the draw distance in the video settings, the default for this version of Optifine is really low.

Are you running the Multiverse plugin? It's a known problem with that and IC2, if so. It's just cosmetic and it should still behave properly, but it is annoying and there's no fix that I know of.

Block IDs have changed, so old worlds need to be converted before being used under Tekkit 3.0.3. If you want to revert back to 2.1.1, go to your world directory and copy level.dat_mcr back to level.dat.

178 is the default value of EE interdiction torches, so it's apparently ignoring the config file. Did you move any files around? Running the tekkit.jar from a different directory than the one it unpacks to will cause these kinds of problems, for example.

What does your server's mod_EE.props file say, for the 'BlockEETorch' line in particular? It's strange that you would start seeing that error now and not in your first run, since it's a configuration error and the conversion doesn't change the config, and it hasn't even gotten to the point of loading the world yet.

I suspect you're using an old version of the launcher, as it's trying to load stuff from the vanilla Minecraft directory (where you appear to have a bunch of other mods installed) and that's a known problem with older versions. Get the latest version and try again.

It looks like the block IDs haven't been converted. Did you go through the full conversion process here?: http://www.technicpack.net/forums/threads/so-you-want-to-convert-your-world-to-tekkit-3-0.9492/

It's a far bigger hassle to make people who do want to use it have to manually patch their clients and servers than it is to make people who don't want it disable it on the server, so it's better to just leave it in.

It's probably not a bukkitized version of the mod. The server uses Forge Mod Loader instead of Risugami's ModLoader now, and mods have to be ported to use that too. That's why you're pretty much limited to this set of mods.

If you have the files after the mIDas or tekkit3fix steps, that's good enough, look for any .mca files and delete them before copying them to the 3.0 server. And right, the wireless receiver isn't at 127 in 3.0 anymore, but there's a block in your world with value 127, and the only reason it would have that value after the conversion is if it was an EE pedestal before, but then the tile entity for that block is for a wireless receiver, which implies that it was one before, so its value hasn't changed from 127, which implies that it didn't get converted.

This is a long shot, but I did see one case of it recently: if you go back to the 2.1.1 world files, and look in the 'region' directory, are there any .mca files? If the world was ever loaded in Minecraft 1.2.5, even as a brief test, stray .mca files can be left behind that interfere with the conversion; the server will use the existing .mca files instead of converting the old world, and the data in those will be old and have the wrong block IDs. If there are, delete them and redo the conversion. That's what I'm seeing in the messages: it thinks there's an EE pedestal there but gets confused because the associated tile entity is for a wireless receiver. Wireless receivers are ID 127 in 2.1.1 and pedestals are ID 127 in 3.0, so it's like the world didn't actually get converted in mIDas, and that could happen if it's loading an old .mca file instead of the converted .mcr.

Set "debug: true" in the PermissionsEx config.yml, and in the server log you'll be able to see exactly what permission node it's testing for whenever you try to craft or place something.

What are the exact errors you're getting now that the right world is in place? There might be slight differences in wording that are important.

Did you happen to run mIDas Gold against the same copy of the world more than once? If so, that'll mess up some of the EE block IDs as they'll get converted more than once and wind up the wrong value. I haven't tested the tekkit3fix script against Python 3, but if you have Python 2.7 installed, you could try forcing it to run against that with something like "/usr/bin/python2.7 tekkit3fix.py ..." Edit: The errors about wireless redstone are actually expected since the blocks get removed, but the EE ones are still strange.

Edit: Oh wait, this probably won't work because it'll pull fuel from lower tanks too, not just the one it's facing. This is just brainstorming, I certainly haven't tried it, but you might be able to do it with deployers facing the tanks at the levels you want to test. Put a bucket in the deployer, pulse it, pulse a filter attached to the deployer set to extract empty buckets, route it through an item detector, then back to the deployer, and then pulse the deployer again. If the tank has fuel in it, nothing will happen and the bucket stays in the deployer and puts the fuel back into the tank. If the tank is empty, the bucket trips the item detector and that can trigger your refinery starting. Flip it to a full bucket in the deployer to detect when the fuel has reached a tank instead. Trickiest part would be setting it up so that everything fires in the right order.

Re: NEI disappears when in full screen mode Try messing with the GUI Scale option in the video settings. 'Auto' seems to give NEI less and less room as the window gets bigger and eventually squeezes it off the screen entirely, but 'Large' works well for me.

That config file is, oddly enough, not in the 'config' directory but up in the main server directory, in the mod_EE.props file.