Thunder, 99% of the players of your mod will be using it in SMP. I'd strongly recommend that you do 99% of your testing on the SMP version.
Also, latency can cause bugs of it's own...just testing on "localhost" isn't as good as testing on a remote server somewhere. If you have access to one, I'd recommend uploading your builds to there and testing it that way.
Please make it compatible with alternative track types, such as the tracks found in the mod Railcraft. A spacing pattern would be nice, as well (aka place this track every X blocks with a GUI) so you could specify boosters.
It looks like you might already have that more or less implemented, but it doesn't look like it would "know" it could use it if you stuck a rail type in the cargo inventory that was of a type other than standard rails.
As it is right now, your code seems to be better implemented than Eloraam's Frames....
Have you considered writing extensions to the mod to allow other types of moving machines?
What's wrong with dedicated batboxes to your luminators if you want a battery backup? Why should a luminator store 10k power, anyway? There's no battery in the recipe, the only reason for the high storage is because of a nasty bug I found and because of the stand alone mode.
It would be easy to make them respond to redstone...except that defeats half the purpose of luminators. If you are playing with RedPower 2 Installed, the main drawback to those light cubes is that the redstone needed to activate them interferes with other redstone devices.
I know the reason : Energy Net subtracts 1 power before it sends anything (I was tracing the code today). So solar panels, since they only output 1 per tick, get no power through to a luminator.
A video of what luminators working properly should look like.
It isn't instant, since if I made it work instantly it would require more server CPU and a typical player is going to place hundreds and hundreds of luminators.
SMP of course, what would the point of using this mod in SSP be? I dont think you should even release an SSP version, since creepers can't get through a cobblestone wall, you don't need an indestructible energy shield.
Hmm. I just tested this to try to confirm it. Couldn't reproduce, shift clicking worked fine when I tried it with the macerator..
Issue fixed : I just manually went to every reference to "NetworkManager" and made it explicitly "ic2.platform.NetworkManager". Annoying, but it works now. Also I commented out a line of code in the main mod_IC2 java file that was causing an issue, since I don't need to change that file anyway.
Alright, I fixed Luminators. Here's the code :
Summary of changes : Luminators update 4 times less often, reducing unnecessary CPU load. They also take their time adding themselves to the energy net.
When you charge a luminator with a battery, it takes 11 times less clicks to empty the battery into a luminator.
Luminators when attached to a wire will turn off within a few seconds after power is cut. However, if you manually charge a luminator, even if it is attached to a wire, it will stay lit for as long as the internal power buffer lasts. The internal power buffer is 10k EU when you manually charge one with a battery but only 20 EU when attached to a wire.
MJEvans : you manually use a battery on the luminator in that case. That would charge it up to the full 10k. Or you just have dedicated batboxes to your luminators.
I'd post a tutorial on how to do this except that I don't know 2 things : first, I don't know where the battery actually interfaces with the luminator, it must be in the client code only. Second, I don't know how to make it recompile since the MCP addon has not been updated.
Another bug found : the storage upgrades for the projector do not work, either.
And I just tried an area shield with an inhibitor and a directional projector inside the area shield boundary on a DIFFERENT frequency. Inhibitor still deleted the directional projector's shield.
Another bug : on log in and log out, the direction that directional projectors are facing is lost.
Just tried 2 area shields, on different frequencies, with an inhibitor on one of the area shields : the inhibitor still inhibits area shields.
Bug : The GUIDs by default conflict with the advanced machines mod.
Sheesh...I'd say there's at least 10 severe bugs so far, and we haven't tested everything. What exactly did you do to test your mod?
I can confirm : range upgrade is broken.
ALSO, the EU injector works but it no longer comes "on" like it did before.
And frequency doesn't save, yep. Just like you found out. It works but display is broken.
And yes, radius of projector will no longer change.
Mod is still unusably broken, actually worse than it was last beta 
I hope you can fix these issues so we can actually use it!
The problem is your default block IDs conflict with buildcraft, which is a VERY commonly used mod.
After about 5 tries I found that 191, 192, and 193 are unused. I am running Buildcraft/Power Converters/Industrial Craft 2/Redstone Power 2.
This is a VERY common configuration in terms of mods, I would recommend you adjust your defaults to something that won't conflict.
And why are you using 3 block IDs? Can you not fit it all in 2? Machines/Upgrades in the same ID?
This is really, really easy to fix.
I looked in the code for luminators : there's a MaxEnergy variable set to 10,000. If you reduce that to a smaller number, lights will go out soon after cutting off power instead of running for hours after.
BUT...that means that if you use a battery, they won't charge up enough.
So it's really really simple...add another variable to the entity that you reference in "injectEnergy" which is where the luminator takes power from the energy network to keep itself charged. Call it "MaxWiredEnergy" and set it to a low value. If you set it to 1 the lights will turn off in 6 seconds after hitting the switch. Making it nearly instant would require another tweak. The part of the code where it says if(energy <= 0) {shut down the light}. Make it if(energy <= 32) and the lights will shut off instantly.
For some unknown reason Alblaka and team want machines to be able to store a full packet of energy (32 in this case) more than their maximum storage..I don't know the reason for this, but it's easy enough to work around.
EDIT : I get it. The reason it is done this way is to reduce CPU load. So, to make the lights instant would increase CPU load. The safest fix would be to make maxWiredenergy = 1 and no other changes.
When you decompile 1.337b, you get a screenful of errors that say "reference to NetworkManger is ambiguous, both class.net.minecraft.src.NetworkManager and class ic2.platform.NetworkManager in ic2.platform match"
I can't ask in the addons forum because I'm trying to create a set of private tweaks to IC2 that won't be distributed as an addon, I can't ask in support since decompiling IC2 isn't supported...so I am asking here how you fix this error?
Still belong sinto Support ~ Alb
Also could use a cooling terraformer to chill the ice down, right? Might be cheaper than a huge array of compressors.
Display MoreAccording to the wiki:
Pump + Compressor + Compressor = 200 eU / 10 seconds + 625 eU / ~15.625 seconds + 625 eU / ~15.625 seconds
Thus cooling for 300 costs 1450 eU and close to 42 seconds.
Each pulse a uranium cell produces (at maximum eff) is 10 heat and 10 eU, therefore in order to come out ahead cooling wise ice must cost less than 300eU to produce. It does not.
Buckets however cost 0eU to produce (costing only redstone action and some unknown volume of RP2 power to suck out through one pipe, OR redstone action only to filter out), and still cool for 250. However it seems that buckets cool one at a time, in series; perhaps a limit of 10-20 placed buckets/sec? That would still yield over 2500 cooling though.
Evans : thanks for pointing this out. I didn't bother to actually compute the energy requirements, I just relied on another player's post on this. Apparently, unless you are using EE to get the ice or maybe snowmen and block breakers (when the 1.0 update comes) it's a no go.
The way reactors work, once per second the reactor code checks every single slot in the reactor. If it finds an invalid item, it ejects it. If it finds a bucket of water, it subtracts 250 heat from the reactor and empties the bucket if heat is over 3000. If it finds a uranium cell, it checks to see how many other uranium cells are adjacent by checking each of the 4 adjacent squares and adds a certain amount of EU to the reactor's production rate and a certain amount of heat to itself. And so on for each square.
So if you want to remove 250 heat/second, you must sacrifice a slot to a bucket. The rate that you insert buckets with transposers and filters does not matter so long as you replace all buckets within 1 second.
According to my testing, I do NOT believe that Transposers/Filters will be needed AT ALL for this system. Retrievers fill the role of moving things OUT of the various machines and Sorters fill the role of moving things INTO them.
Perhaps not, I just don't see what the sorters are for. Hmm..you could use them to make sure that the buckets are distributed evenly between the deployers.
The rough design I had in mind was real simple : you have 8 retrievers, and 8 filters on 8 deployers. Once per second, you yank all 8 empty buckets from the reactor and you yank all 8 full buckets from the deployers. You route your piping so that there is another destination besides the reactor available to the buckets coming from the deployers : perhaps a route back to the deployers that passes through a transposer one way valve. This "packet" of 8 buckets close to each other in the pipe you combine into one tube by using inline transposers (since they transport an item through instantly)
I wanted a design that minimzes unnecessary buckets in the tubes, because those increase CPU and GPU load unnecessarily (I play in SMP). I want there to be only as many buckets traveling as the reactor actually needs, with a small cooling surplus since the system won't be synchronized with the reactor so it might sometimes fall 1 second behind. The reason to use 8 filters on a 1 second timer rather than 4 on a 0.4 second timer is to make one unified "packet" in the pipe to make sure all 8 buckets are replaced before 1 second is over. You might have to have sent a couple of packets already to avoid getting behind. One other key note : I've read the reactor source code. Only once per second does the reactor update and iterate through the contents of the reactor. Any buckets it finds will be consumed all in the same tick. This is why we only need to activate things once per second, anything more is just spam.
Just so you know, you don't have to wait for (or use) retrievers to make a 8 bucket cooled full cell reactor.
See my explanation video i made for Quartz in another thread: http://www.youtube.com/watch?v=9SQCc3N71FM
That is a fully operational 1740 EU/t bucket cooled reactor. There are MANY ways you can design it but it does rely on Power Crystals power converter mod for BC 2.2.5 and IC² 1.23 (which works just fine for IC² 1.337 OFC) using those power links which will act on wooden transport pipes once per tick. (No other power conversion mod i know of allows that rate of bucket extraction using BC's pipes)
So in short, without RP2's retrievers the only way i know how is to use those energy links from that conversion mod but it does work just fine and now it's just a matter of making the design less CPU intensive. It is just a proof of concept in it's current state...
Sorry bout the horrible English, I am not that good at speaking it.
Yeah, I forgot about this. Those energy links are incredibly strong engines when acting on wooden pipes. Looking at your video, it was hard to tell why your wooden pipes don't pull out fuel rods from the reactor.
