We can have our cake and eat it too if only Al introduced roundrobin coding. It works like this, you have a list called "todo", and in this list are IC2 engines that currently need to do something. This list can actually be saved separate from the file, so engines that are in unloaded chunks could still be working (astounding right, wow...anyway). With this list is a variable called "currenttick"....and all it does is increment by 1 every update (1/20th of a second, or whatever future IC tick rates will be) -- if this value is a short, it can easily wrap around without problems. Each engine in the list also contains a "lasttick" value, and during its update, it will subtract the 'currenttick' from 'lasttick' to get how many 'ticks' it needs to work for (and set 'lasttick' to 'currenttick' for the next update).
Why all this? Instead of updating every engine every tick, you only update the 'todo' class. This class will go through the list of engines and update them individually, and the number of engines that are updated can be _throttled_ <-- very important word. The number of engines updated can be set to a minimum start value (say 10), and this value can be increased slowly (throttled) as long as the FPS rate does not decrease by more than 5%, and will decrease the value if the FPS is above 10% drop. To determine "normal" FPS in order to calculate drop rates, simply put the 'todo' class in a 'hold' state (where it continues to increase 'currenttick' but it doesn't update any machines), and calculate an average FPS over a few seconds.
This would allow the game to be played without ANY apparent lag whatsoever, but allow for all the machines to work as intended (a solar panel will still give off 12000 EU during the day whether you are on a crappy computer or not).
