the ae doesnt put items into a slot if there is not space, because it has an inventory for that items. in order to prevent item bouncing. you need to think about overflow, and buffer when using rp
Which part of Redpower do people see as laggy?
- Thread starter connerity1
- Start date
-
The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord
Yes, I wasn't very organized when I set up my recycler, I didn't leave space for more so I had to build the second one some distance away. And I didn't know about Routers either. Do Machine Filters work with Routers and IC2 machines? I couldn't get them to recognize Iron Furnaces or Generators, but I never tried them on Recyclers or suchlike.
Well routers have an upgrade called "Machine Filter" if that's what you mean (you hold the upgrade and right click it onto the router). Yes the filter does allow you to specify things like generators or other routers and most machines (have not had luck with nuclear reactors, but just about everything else). I have an array of 30 generators. Each generator touches at least one other generator. A router sits at one end and has the machine filter and bandwidth upgrades and is in insert mode and you can select which side/slot you want to insert to. The filter is set to generators (in case I accidentally put another machine down next to a generator). The router has an ME exporter feeding it burnable items from my ME network.
My recycling array works similarly and I even use routers to automate carpenters and fermenters. For larger arrays, you might want more than one router to insert things at a faster rate, but remember that having two (or more) routers in the same array makes the machine filter a requirement because otherwise routers will try to insert into each other. And both routers will walk the whole array, so if it's not going fast enough, consider splitting the array to limit the search area. I'm really looking forward to a 1.5.x update because the fuzzy logic exporters should allow me to completely eliminate the need for apiarist pipe in my alveary automation.
When discussing lag, bear in mind there's several kinds and they effect people differently.
Graphical lag is the "nicest" - your client just can't draw stuff fast enough. This can be improved by shorter rendering distances, less fancy options, etc. Mods with fancy models can be but are not necessarily a prime suspect here. But the game simulation logic is unaffected.
CPU lag is the next most obvious. Though you can be CPU bound during render, I am going to use this to mean the game's simulation thread. This is where server tick rate comes into play. The game must be able to handle the entire loaded world(s) in under 50ms. If it can't, things start working oddly.
Then there's network lag. You can do whatever you want in your mod block, but odds are at some point you will need to tell players about it. This usually comes in the form of block updates, which cause the server to resend all data about a block to the client. If too many blocks in a chunk get queued for update, the entire chunk is resent (I do not recall the threshold offhand, but it's not that high). Players with poor network connections will teleport around and witness other weird behavior.
RP2 is primarily network lag. It sends an incredible amount of updates to clients and does it constantly. It may be CPU efficient algorithm-wise, but block updates are actually fairly bad for players.
Network lag can come from other sources, too: GUIs need to update data while open, some mods like MPS need to transmit state around, and sometimes there's things like that bugged version of a somewhat popular mod (that I won't name because it was fixed) that just sent 2mb/s for no real reason.
Finally, lighting updates are bad. Because in MC lighting has gameplay effects, it has to actually be calculated and synced. Flickering lights can be surprisingly bad for performance of a server.
Graphical lag is the "nicest" - your client just can't draw stuff fast enough. This can be improved by shorter rendering distances, less fancy options, etc. Mods with fancy models can be but are not necessarily a prime suspect here. But the game simulation logic is unaffected.
CPU lag is the next most obvious. Though you can be CPU bound during render, I am going to use this to mean the game's simulation thread. This is where server tick rate comes into play. The game must be able to handle the entire loaded world(s) in under 50ms. If it can't, things start working oddly.
Then there's network lag. You can do whatever you want in your mod block, but odds are at some point you will need to tell players about it. This usually comes in the form of block updates, which cause the server to resend all data about a block to the client. If too many blocks in a chunk get queued for update, the entire chunk is resent (I do not recall the threshold offhand, but it's not that high). Players with poor network connections will teleport around and witness other weird behavior.
RP2 is primarily network lag. It sends an incredible amount of updates to clients and does it constantly. It may be CPU efficient algorithm-wise, but block updates are actually fairly bad for players.
Network lag can come from other sources, too: GUIs need to update data while open, some mods like MPS need to transmit state around, and sometimes there's things like that bugged version of a somewhat popular mod (that I won't name because it was fixed) that just sent 2mb/s for no real reason.
Finally, lighting updates are bad. Because in MC lighting has gameplay effects, it has to actually be calculated and synced. Flickering lights can be surprisingly bad for performance of a server.
