So servos are banned because they all have the same id. This limits the conduits to attach to machines with auto output. I had signallum servos installed and everything was fine with them. They were banned because they did crash the server. Fine nothing to argue about. But.. Did anybody report the crash on there github issue list? (CoFH/Feedback · GitHub With version 1.3.4 they updated Thermal Dynamics from 1.0.0RC2-77 to 1.0.0RC2-98. 21 Update cycles. Would be save to assue they did some work. I really like to use those servos. they are way more versatile then enderio conduits. Also to move big chunks of items they create way less lag, then enderio with a lot of updates. Even the most expensive server only ticks 2 times per second.
There is a servo counterpart called a retriever. Instead of extracting, it will insert. It can be used instead of the servo, but would require one for each connection where you want items. There is another alternative. @Deltachi and I got a setup, where a CC computer forces a chest to output into a tesseract connected to warp itemducts. However, you need to connect the itemducts to more than 6 sides of the same tesseract channel (we use 2 tesseracts) as without the servo, the itemducts do not extract at the intended speed, and needs to have multiple connections. Feel free to check out our setup if you visit INF-1 and we are on.
This does not overcomplicate a simple problem.... Not in any way performant. :-D Why give examples of replacements? I dont need them I can do everything right now. Thats not the point of that post. Look at the code of those servos. I think they are really good performance wise. These only tick twice per second. Also NTB/Meta search is disabled by default. 90% of users dont need it anyways. Also like I said. More versatile = more fun to use. ;-) You cant say that that for conduits which are used in almost every setup on the server right now I guess.
The initial ban of them was due to major performance issues (again with the ore dict, although it was rewritten and is extremely faster than in 1.6). Since then we haven't fully tested them. The issue is that we can't unban them on the server and let the players test it as, if we need to undo it, all the conduits would need to be removed. Why do you think they are better in terms of performance? They still tick over all and therefor are far from the performance of non ticking cables/conduits/pipes.
infinity got updated to 1.2 and they were not banned for 2 days. then they got banned for causing a crash at least this was told me... So again performance issues? zZzZz I tested them and oredict, metadata and everything fancy is disabled by default. Rather from being activated all the time like in 1.6. I had a quick look and compared the code to a 1.6 version and it looks a lot faster. You did not ban the duct that is "ticking" although they update they less then before. they only update their position every so often. You can see that if the server is below 20 tps. The item in the duct is beeing moved back every few seconds. then client animation takes place with their normal movementspeed and then they are updated again Back to servos. Why are servos banned but the retriever isnt? If the servo is bad for performance.... The retriever checks every inventory available with I guess is the exact same code? They have the excat same GUI. Its like a Servo for every inventory on that connection... If servos are bad. Retriever should be: Code: BAD * INVENTORIES_CONNECTED = EVIL eAndPi tells me to use Retriever. Where is the logic? ^^ But did anybody report those performance issues that there is a progress of getting them back?
they froze the server with ore dict lookup meant in general, else ender io, extra utils... all would need to go 2 of those servos caused the issue from extreme lag spikes to complete server freeze, I don't know the details, but I guess @SirWill can tell more. (the retriever's never did) This issue was reported to ftb many times, so I guess they took care of it, by forwarding it. As cofh is pretty nasty about double reports, I don't bother reporting big issues to them. I still don't seen any benchmarks between ender io and thermal dynamics, judging from the bare feeling of how the code looks and is structure isn't by far any accurate.[DOUBLEPOST=1428449888,1428447237][/DOUBLEPOST]A small background info. On 1.6 with the issue being around I tried to report it to the mod authors showing them profiling snapshots... all I got was being ignored and told I don't know shit. During the whole 1.6 time I spent probably around +100 hours only on this issue, until we finally patched in some caching and reporting. With 1.7 we had no problem giving it another chance, but as soon as the it started to fail the server by instantly causing major performance issues and soon later freezing the entire server the answer was simple to remove the servos as there are plenty of alternatives. To this day I don't feel like supporting a project which decided that I'm not worth being given a reply or proper respond. All you gave here were assumptions based on a gut feeling, so please understand that I'm by far not in your favor here. Show up some real benchmarks and we can discuss further.
Well, bad habits die hard. Although this sounds a little bit promising. My guess for 1.6: a lot of people told him his coding was bad and he knew he would have to redo the hole mod to get it fixed. Maybevwe have more luck with 1.8...
I have no problem giving it another chance, but I don't want to end up clearing out all the conduits in order to get rid of the servos. So some deep testing needs to happen first. At least we have the advantage of not being alone, so we can wait for others server to do the first step and if they are still up 1-2 weeks later, we can guess they are at least manageable.
Uhm, not all servos are banned, only the ones with ore dict function. Also, there seems to be no changelog for any CoFH mod which makes it impossible to know if X got fixed.
You should ban retriever aswell then. Like I said they function as servo for all inventories connected. oredict included.
well oredict is disabled by default. I guess nobody is filtering for it. It only was one case someone used oredict on the servos aswell. You didnt remove them. I guess there are still some servos at work also ;-) Or it is fixed by now
no, i'm only using them for coal coke blocks and wither skulls, i'm using just about every other function though
It should be possible to make a simple test. E.g. put up an ender quarry on full speed to get some mixed items. Maybe add a few heavy nbt items into the storage, too. Now build a heavy looping setup with thermal dynamics and ore dic lookup. Let it run, restart the game, let it crash.. if it works fine over time, we could see about re-enabling them to give them another chance on the server.
give me an hour and i'll have this and more setup for your testing needs (edit) after running on an SP world, the SP world did not crash after 10 minutes of using the servos with NBT search and oredictionary on while using warp itemducts
