Redpower Lags Client

[SReject]

Lathanael you aren't adding to this thread, Please don't turn this into a flame thread.
People come here for help

And neither are you, at this point.

Also, Lathanael is correct in stating that optifine has caused as many problems as it solves. On my dell laptop(roughtly 2yrs), The spawn's map doesn't even have a chance to render before minecraft crashes.

As for the BC pipes causing lag, I've noticed they lag(about as much as RP) when stuff is moving through them, but when empty, greatly reduce my lag verse RP tubes.

 

[Ilnor]

Well this thread has gone as far as it's going to go then,
Everyone on this page just go back to earlier pages if you're looking for help

 

[Roachy]

I've been hitting this problem lately as well. In my testing, I've narrowed it down to redstone tubes. I've got 2 sequencers, countless filters, lots of tubes, and lots of redstone tubes. Also lots of redstone engines. I systematically disabled each of these where possible and the only configuration where my chunk loading slows down significantly is when the timers are activating all of the redstone tubing. The timers them selves are fine. And the redstone tubes themselves are even fine, but when the redstone tubes are pulsing, that's when the chunk loading problems kick in. I even spammed torches along where the redstone tubes were in an effort to thwart any lighting updates the tubes might be causing, and that didn't help.

To clarify, the symptom is that chunks will not only load slowly, but chunks farther away will simply never load at all until I stop the redstone tubes from pulsing (at which time the unloaded chunks immediately begin loading when I look in their direction). Admittedly I pulse them quite often (~1 pulse every second, that is, twice on each sequencer rotation, when the quarter rotations are set at .5s).

Next I'll probably see how much trouble it would be to replace all the redstone tubing with insulated/jacketed red alloy wire and see of that helps. The one thing I can't be sure of yet is if it actually is the tubes, or the filters which currently can only be activated by the pulsing tubes. Also, all of my testing has been with a "dry" system, that is, with no items flowing through it.

Edit: Also, based on recommendations in this thread I installed Optifine and configured it as best I could to reduce this problem, and also am using the fast graphics, non-smooth lighting, etc. Although I am using a pretty far render distance. That's not something I'm willing to give up. But even with that everything loads fine without the pulsing.

 

[Roachy]

Follow up: I tried replacing all the redstone tube with regular tubes and running equivalent jacketed wire. No change, so I figured it must be the filters (of which I was using 38 + a sorting machine). So I swapped the redstone tube back in, removed the jacketed cable, and removed all of the filters (so the restone tube was pulsing, but not activating anything). No change. So I cut bluetricity power to my sorting machine (which had a lot of filtering configuration). No change. So I cut the redstone pulse to the sorting machine (leaving it pulsing the redstone tubes). No change.

Then I cut the redstone pulsing to the redstone tubes. Chunks load fine. This left me wondering if the jacketed wire has the same problem as the redstone tubes. So I cut the pulsing to the tubes, and lay down an equivalent amount of jacketed wire and connect it to the pulsing. Chunk loading problems again. Cut the pulsing again, chunks load fine.

So based on my testing, slow/problematic chunk loading is caused by:
1) pulsing redstone tubes, either alone or powering filters
AND
2) pulsing jacketed wire (and probably any wire in that case), either alone or powering filters

There's no simple way to know whether the filters themselves are contributing to the problem as pulsing any wire or tubes connected to them causes the problem anyway. I could hook up a sequencer to each filter I guess, but that's not going to be practical for anyone anyway.

So apparently I can't do any kind of pulsing across any kind of medium (or at least any kind of convenient medium) to run my sorting system. That blows. How the F*#$ am I supposed to get around this when filters and other RP2 machines require pulses to function? Seems like a bad design decision to me. Why can't we just have machines that are always on and pulse themselves?

 

[Abdiel]

Use gates to detect items in the input inventory, and only run the pulses if there is something to sort.

Alternatively, sorting machines have an auto-pull option which makes them pull items out of the attached inventory continuously without requiring a redstone signal.

 

[Roachy]

Use gates to detect items in the input inventory, and only run the pulses if there is something to sort.

Alternatively, sorting machines have an auto-pull option which makes them pull items out of the attached inventory continuously without requiring a redstone signal.

I originally REALLY wanted to use retrievers to do all of my sorting, but as many of you well know, they are totally gimped because items aren't guaranteed to go to the retriever that requested them. I've read that Eloraam has stated that this is intended behavior and isn't planning on changing it, but I think that makes retrievers nearly useless.

I was also avoiding using lots of sorters with that auto pulse option just due to the resource cost (to replace my ~40 filters), and the necessary bluetricity infrastructure, but I may give it a shot.

Gates are not something I've looked into and I'll have to do some research on that, but I forsee that it is going to make my setup much more complicated and/or ugly/space-inefficient.

I really wanted to avoid using Buildcraft pipes as I hate even the thought of them dropping items on the floor, but I may finally give in if these gates aren't worth bothering with.

 

[Abdiel]

You don't need to switch to BC pipes to use gates. Gates can emit a redstone signal without needing any pipes. You can use this signal to control your existing RP machinery.

 

[Roachy]

Interesting. I thought gates were exclusively a pipe modification.

 

[Greytusks]

The trick is to put them on a structure pipe attached to the machine you want to monitor

 

[Roachy]

I was actually able to keep my general layout and swap most of my filters for sorters, which in that auto-pulse mode are WAY less laggy. Not sure, gates may have helped, but I didn't really need them, just need a lot of sorters.

I'm still having to use a couple of short-wired pulse timers to run a couple of retrievers, but as soon as I have the resources to make about 18 more sorters, I can get rid of those and my entire sorting system will be virtually lag free. In fact, excepting the always-on redstone line to my redstone engines (for autocrafting tables), it will be entirely redstone free as well.

I'm not super comfortable with the extra bluetricity lines I need to run, but it's a worthy tradeoff.

 

[Larroke]

Are inline filters a source of some of this lag? Oh, god I hope not... I'm getting creative to eliminate the relays I have, only about a quarter gone though, if filters are laggy too.. that complicates things a bit.

 

[KirinDave]

I ahve almost totally removed inline filters and sorters and soon I will have all RP2 pipes gone. Those people with slower computers on my server have noticed a substantial improvement in their performance. It is crazy that routing turtles are actually less laggy given that they're a whole flipping lua interpreter instance, but whatever.

Now if only we could get around this runaway NEI memory bug...

 

[Roachy]

Are inline filters a source of some of this lag? Oh, god I hope not... I'm getting creative to eliminate the relays I have, only about a quarter gone though, if filters are laggy too.. that complicates things a bit.

I don't think the filters themselves are the source of lag (in my case), it's just the pulsing redstone lines that's required to run them.

 

[NightKev]

It is crazy that routing turtles are actually less laggy given that they're a whole flipping lua interpreter instance, but whatever.

Well, there's only a single server-wide Lua interpreter instance (cf this post) that every computer/turtle shares actually, so perhaps not as surprising.

 

[StreetKing]

Wow i am very sad/surprised about what I am reading here. I am new to FTB, and I am having a blast messing around with the different mods. RP2 has definitely proved to be my favourite mod but if it's the reason I am getting so much lag, then i guess i'll have to let it go because I am experiencing some pretty bad FPS lag spikes at my base. I'll start doing research on Buildcraft pipes, they're not as good as RP2 tubes but they'll do the job fine(I hope at least).

 

[KirinDave]

Well, there's only a single server-wide Lua interpreter instance (cf this post) that every computer/turtle shares actually, so perhaps not as surprising.

A* vs. a recursive descent parser. The former ought to be faster, because there is less state. Fun fact: the two operations are related.

 

[slay_mithos]

Well, Redpower is not the ultimate mod that solves every problems, even if some people want to believe it.

But even then, when I see some people blaming all the lag on one mod, it hurts a bit.

If you want to talk about potential lag, IC2 machines can become a big source, if they have many over-clockers but no storage upgrades, for example.

And the ComputerCraft sorting, while it seems all great, it has a particular problem of being a little hard to put in place with a big flow of items.
That means that it will have trouble with dealing with the faster mining operations.

Well, that being said, these mining operations are also a source of lag, doing a lot of block update, constantly (RP quarry, max speed BC quarry, array of mining turtles with specialized mining programs...).
And if you don't sort the cobble, sand, sandstone, snow, basalt and marble, it significantly reduces the input anyway, so I guess that's fine.

In my opinion, the worse part of RP where lag is concerned are the micro blocks, because they demand additional calculations to be rendered, so when there are a lot of them, the FPS will go down significantly.
That's sad, because they are such an awesome building material...

 

[Zjarek_S]

The best way would be to steal some focus from mining huge amounts of ores just to put them in storage. I really like TC3 balancing, it allows for awesome things, but when you get too much of it, wisps and lack of vis will be a good "punishment". The major culprits seem to be mass fabricator, compact solars or GT, because they encourage quarrying your world. Diamond blocks towers don't look good.

About RP wire lag, another things is that client knows about every change in RP2 wire for every piece of it, even when you use insulated or bundled wire. They can transfer a lot stronger signal then redstone, so it is easy to cause thousands of packets by flipping one lever, getting a lot worse with timers.

 

[Growle]

What about those wireless redstone transmitters / receivers? I messed with them earlier and was surprised that they can work over ridiculous distances, much like Tesseracts...Do you think switching out to wireless redstone signals / Tesseracts would help lower any of these issues?

Also, our server admin is convinced about certain things that cause massive lag but I can't find out any concrete proof anywhere. Things he's mentioned include: Wrath Lamps, long BC pipes, inverted / non-inverted lamps, timers, portal gun portals, open world pumps (water / lava), crystal chests, chunk loaders, and a few other things I can't currently recall. We experience server lag spikes every once in awhile, but it's hard to tell whether they're from world generation, or any of the above. It all leaves me wondering what the point to any of these mods are if they are going to taint our MC experience with these issues.
It's difficult to have a great system dangled in front of us only to find out it's causing major problems and we can no longer use said system...That being said, we don't hoard a ton of minerals, and therefore don't have a huge system of sorting / recycling / storing... We run 1 or 2 quarries in the twilight, powered by tesseracts and collecting with tesseracts, mixed with some random pick mining, and it provides enough for 3 of us in survival to create and expand without having to worry about using everything up. If we do decide to expand our system to accomodate some automatic systems, would it really be worth it? Or should we just stick with the more hands on approach like we have been...i.e. manually placing ore into hoppers --> processing ore --> smelting to ingot...

Redpower seems great and has a lot of awesome tools but if these redstone signals are the biggest cause of lag then it would be best to start accomodating now before we get too deep into those systems. Thoughts?

---sorry for all the text >.>

 

[NightKev]

Also, our server admin is convinced about certain things that cause massive lag but I can't find out any concrete proof anywhere. Things he's mentioned include: Wrath Lamps, long BC pipes, inverted / non-inverted lamps, timers, portal gun portals, open world pumps (water / lava), crystal chests, chunk loaders, and a few other things I can't currently recall.

- Wrath lamps shouldn't cause any lag except possibly a minor amount when you initially place them (since they generate a ton of invisible light blocks upon being placed), I'm pretty sure.
- I recall BC pipes being optimized at some point such that they only render a limited amount of items in them (thus reducing FPS drops), though I don't know if they're any better or worse than RP tubes in regards to lag.
- Lamps shouldn't cause any extra lag any more than a torch unless you are switching them on and off quickly/often.
- Timers, well, try to keep them over a second in interval, they can definitely cause lag.
- Portal gun portals should only cause client-side FPS drops... except not anymore because see-through portals feature was removed from the mod for now.
- Not sure what you mean by "open world" pumps.
- Crystal chests can cause FPS drops due to their item rendering, yeah.
- Chunk loaders, well: every ~441 or so chunks being force-loaded is basically like another player (using far render distance) being on the server. So really, on their own, not all that much lag, unless everyone is loading a ton of chunks.