Suggestion: Secondly Power Ticks

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).

Quote from Sabriath

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).

I dont know what you are talking about.
But you seem to know what you are saying.
I approve of this idea!

Quote from Alblaka

I see the point behind your idea and will not call it utterly useless. But there are two main arguments against it:

1. It won't even closely reduce the CPU-load by anything near 95%. I would guess it would cut it by at max 20%.
Transferring energy via the ENet (at least the IC2 one) is a minimal operation with near-perfect efficiency. The main CPU-load are running machines and/or UPDATING the enet (which happens upon placing/removing cables/machines).

2. This would cause most machines to run "slow", as the human brain will easyly spot the "1 fps / second" alteration as lagging. People are used to smooth stuff, this is why the Reactor was coded that special as well (the main calculation ticks ever 20 ticks, but the energy is still emitted every single tick, causing connected Storage blocks to "run smooth").

Unless there are much more severe arguments given to implement this, no.

Display More

Minecraft is about playing the game though....I would rather have the lag maintained within the machines and not the ENTIRE game. At the moment, I have 8 water mills surrounded by water in a stack feeding a batbox outside (which I planned on increasing later), along with a miner outside being fed by hand until I got the materials needed. Inside my house I have 2 generators (handfed charcoal) to a batbox wired to 2 macerators, an extractor, 2 efurnaces and another batbox which is wired to my recycler and compressor.....I get 10 FPS while within the same chunk as all of these machines, but the moment I step outside, I drop to 1 FPS....ONE (compared to about 30 FPS I get in turning off IC2 in the modloader config).

I don't sit there with the GUI open watching progress bars move, so I don't see a point in worrying about if there is a "noticed lag spike" on a bar that hardly gets seen...I play minecraft. IC2 isn't the only thing in minecraft to do, I would like to cave dive for enemies for my Tale of Kingdoms mod, or even set up a control station with RP2 but if I'm limited to a 16x16 block chunk, it doesn't get me anywhere. I don't know if anyone else is experiencing such problems, but if you are doing that many updates per tick, you are bound to lag a computer.

Again, the method I described would only be noticed if you have a GUI open....but even THAT could be resolved so that engines with open GUIs would be updated EVERY tick, while all others operate on the todo list. I suggest the following functions for the 'todo' class:

add_item - add an engine to the list, giving the x/y/z position of the engine and the callback function as parameters
remove_item - given an x/y/z position, find the engine in the list, update the engine 1 last time and then remove it from list
update_item - given an x/y/z position, find the engine in the list, update the engine now
foreground - find the engine in the list, update the engine, and then place this engine in an "always update" list (remove it from the other list)
background - find the engine in the "always update" list and remove it, place it back in the 'todo' list

The callback functions would have a "ticks" parameter which is how many ticks have passed since this engine was last updated. When a player opens a GUI of an engine, obviously you would use 'foreground' until the GUI is closed, then 'background' it.

An example of how this might work, let's take a solar panel. When the player places the panel in the world, it will call 'add_item' with it's location and a callback to a function that looks like this:

update_solar(ticks)
{
  for(i = y+1; i < maxheight; i++)
    if(!is_air(x,i,z))
      return;
  eunet_add(x,y,z,ticks);
}

A possibility of "cheating" can occur in the span of the lag by placing blocks above a solar panel (in this instance) and still receiving the full amount of energy if the block is removed before the update occurs....however there are 2 things to consider:

1. A block placed directly above the solar panel sends updates to surrounding blocks correct? In that case, "update_item" can be called to immediately update the engine and the player actually loses all the energy up to the last update.
2. A person who wants to spend their time placing and deleting blocks far above a solar panel to get "free energy from no light" has way too much time on their hands to actually not play the game, so a moot point.

If you don't want to code it with thread-like abilities, that's fine, I'll have to deal with no IC2 (not even BC2 with a 64x64 quarry and a 16 engine power house lags as much). I would create my own mod if I could, but I can't figure out for the life of me how to (even though I know every programming language, it doesn't tell me the inner workings of MC, modloader, forge, or any of the hooks....and all of the tutorials are about "how to make a block" which doesn't really help either).

Oh well, nice work on the mod though otherwise.

problem is not CPU, problem is network load, every update must be sent to every player nearby.

Quote from RawCode

problem is not CPU, problem is network load, every update must be sent to every player nearby.

Networks are actually my specialty, which is funny to me seeing that. The updates only need to be sent to players __on completion__. For example, when dust is sitting in an electric furnace, you don't need to tell everyone in the room "it just ate another 20 units of energy" every second...it only needs to tell everyone in the room "hey, I'm done with this piece" every 8 seconds that it takes to burn through it. Just as you don't need to tell everyone how much EU is in _every single machine in the 9x9 chunk range players are in_ <-- that makes no sense. You don't even need to tell anyone how much EU is ANYWHERE unless they CHECK it (with an EU-reader or the GUI of certain machines).

If SMP is actually sending these updates, then the code is worse than I thought.

Actually this list would allow for the whole set of machine states to be cached on the client/server sides and only /updated/ when a deviation from expected events occurs. That could dramatically reduce link use.

Quote from Alblaka

Feel free to code it, not gonna bother to mess with minecrafts basecode there ^^'

I didn't realize it would require a basecode overwrite....as I stated earlier, I do not know how to mod for minecraft. The only game I ever modded for was WoW, and the hooks for the game were laid out easily for everyone to see and use. I take one look at a minecraft mod tutorial about "blockthis extends blockthat" and I'm dumbfounded. I can code up something in C/C++ or pseudo-C for you if you want. By the way, FiniteLiquid uses this technique as well, so I know it's possible.