Jelato Foot

Yeah well thanks to said developer's confusing decision to obfuscate his plugin it is impossible to tell why it's causing problems for you, but also, I would be extremely cautions when it comes to any of the dupe "fixes" which come out of that plugin/team, from the developers own words on this forum and his own bukkit page he has shown he has not even the slightest comprehension of what causes the dupes he's trying to fix, and as a result most of them still work even with his "fixes", so just be careful :)

Collectors = 1000x worse than BC pipes 1 collector calls world.getTileEntity 12 times per tick 1 relay calls world.getTileEntity 12 times per receiveEnergy call, which is called by each collector 1 collector "flower" 18 collector / 5 relay setup calls getTileEntity 18*12 for the ticks, 25*12 for the receiveEnergy calls, and that's a best case scenario - some collectors send energy to more than one relay and so the receiveEnergy calls will be higher, then multiply that by the amount of flowers people make, and you have yourself a nice little lag hole... Not only that, redpower in certain situations is also waaaaaaaay worse than buildcraft when it comes to lag, the biggest one is when kids setup 30 recyclers in a row and then pump stacks of dirt or whatever through the pipes at .2s and overflow the shit out of it, then you get the stacks only dropping 1-5 items out of the stack into the recycler, and each time it pops back into the pipe it has to recalculate a route for it to go, which means iterating through the whole pipe network again multiple times per tick in bad cases, which is uber laggysauce. Looking at your visualvm image seeing how redpower TileTube is taking up 21%, I'd say you have some users abusing redpower, possibly look at limiting your timer delays to 1s instead of the default .2s.

Ban them or recode them, your choice.

Sorry but if you're going to shit on someone's post that's wrong you should probably make sure yours is correct, I do agree with you that graz's comment was extremely minecraft, but the problem has nothing to do with inventory tweaks. The issue is because of the same reason the issue exists in the RM furnace, mod makers not triple checking their inventory indexes, it's as simple as a 29 which should a 30 in the container click function which is causing the dupe.

I think the majority of these dupes come about because of copy+pasting container handling code and not double checking the indexes properly, when you are accessing a player inventory inside a container the indexes are offset by the amount of slots associated with the container and so the indexes are different for each container and I think some of the indexes are either overlooked or just mistakenly calculated.

Read my first reply to this topic, I told you why.

Scenarios such as that can't happen because of the order in which objects are ticked in the game, a block cannot be placed by a player in the middle of any of the entity ticks, only by a TileEntity, in which case if it had anything to do with redstone it would update the physics of the block which recursively updates its neighbours and an issue such as a lamp being on which shouldn't be just wouldn't happen. People often overestimate the complexity of the Minecraft server especially when it comes to areas such as this, multithreading of tick-based world servers is nothing new and nothing difficult, and anyone attempting multithreading would have to be selective about which specific parts of it to multithread and if chosen properly then threading the Multicraft server actually is nothing more than just making sure you've put locks around everything to avoid CMEs.

If you're looking for the item stacking feature of NoLagg, which most people regard as it's only useful feature, just use CB++ as it contains that feature plus a few other lag fixyfixies, I hear the 75 build works pretty good for tekkit.

It's not possible to just run a second thread to handle the mod stuff, the tile entity ticking is what causes 98.9% of "lag" in tekkit, which has to be run in the main thread or every time an entity changes/checks a block/entity you will run into concurrency issues due to the nonexistence of locking, and no one is going to spend the weeks required to add all that locking just to have it all wiped out and need to be redone when Mojang do an update... If you want to speed up your server, buy a new one >.> or turn off the overloaded report in the config and pretend it never happened ;o

Sorry but that's not actually a fix then is it? They work 100% fine if patched correctly via the instructions posted in the topic I linked.

I don't want to sound like a douche here but you're wrong, the only problem with the Ic2 api in 3.1.3 is the incorrect package names, which does not require an entire recode of the file it only requires correcting the package names, check the topic I linked.

Sorry, but that's wrong, in java the Boolean object and boolean primitive are interchangeable as are all primitive types with their object counterpart, the issue with that specific function is the wrong package name on the TileEntity, which is net.minecraft.src but SHOULD be net.minecraft.server Check this topic, later in the topic there is a patch download for Ic2 http://forums.technicpack.net/threads/3-1-3-reported-issues-and-possible-fixes.30863/

I'm not quite sure how you came about that error but so far the only IC2 errors from advancedmachines in 3.1.3 that I've come across or had reported to me is the one which is caused by the package names not being ported properly in some of the IC2 files, which is covered in this topic -> http://forums.technicpack.net/threads/3-1-3-reported-issues-and-possible-fixes.30863/ Also, the Ic2.api.NetworkHelper in the 3.1.3 server ic2 mod I'm looking at doesn't have any reference to WorldChunkManager at all, so I'm a bit confused...

Yeah it would be helpful to know what's actually going to happen with this update, if they are waiting on modders/porters to fix the problems with the updates then my guess is we won't be seeing 3.1.3 stable this side of new year if at all, I wish the technic guys would involve the community a bit more with what's going on :/

You could have answered this question with google, or one of the countless plugin recommendation topics on here, or the search button for that matter... There are countless ban plugins which can be used to do that, most people use NoItem I guess or something like tekkit restrict/customizer...

No... No... Just... No... Threading programs is NOT hard, anyone who tells you otherwise needs a slap upside the head, threading is one of the simplest programming concepts there is and java makes it stupid easy for noobs to do it without screwing up their entire program because they are too lazy to lock properly and EVERY professional programmer ALWAYS writes their programs with threading in mind. Minecraft could be quite easily multithreaded but it would have to come from Mojang for a few simple reasons, to multithread chunk and entity processing in the minecraft server you would have to make sure that all containers and objects which are accessed in multiple threads are done so in a way which does not cause concurrency issues, and with java - doesn't cause CME's (ConcurrentModificationExceptions) - which means correct locking on the objects and containers, to do so would require quite a bit of work which if done would need to be completely redone every time Mojang updates the Minecraft server, add on top the obfuscation of the server and the huge division with the various people who do the deobfuscation on what things are/should be named and it becomes an impossible job to do if you want to keep it up to date once done. That being said, I have come to the conclusion as of late that Mojang is inherently anti-mod based somewhat on their own staffs attitudes towards modding plus their lack of progress on their own mod API, but mostly on the lack of multithreading in their server and my basis for that is very simple. Vanilla Minecraft, as in with no mods no bukkit no plugins no thing, can host huge amounts of players without lag provided you have a server with enough ram and an epic cpu, the biggest issues with tekkit which causes lag is the sheer volume of tile entities and the time costly work associated with ticking them, plus the frequency of chunk loading/unloading due to everyone always flying - add in some badly coded plugins and bukkit's overhead to call them and you have yourself some lag, most of which would be inconsequential were the server properly multithreaded. There is no explanation for the lack of multithreading in the Minecraft server, all I can think is that they wont do it because Vanilla doesn't need it and they wont make code improvements which will specifically help people mod their game.

Read the first post of this topic, issue #2. Changing the EMC value of the items in EEMaps is a bad way to fix that issue, the correct way to fix it is to change the macerator output amount for the items in the IC2 macerator recipes (TileEntityMacerator.class) to reflect the EMC equivalent of the source item (Blaze Rod -> 2 Blaze Powder / Bone -> 3 Bonemeal). That way there's not the huge confusion that arises from having a mismatching server/client EMC value on items.

Crystal chests only cause client lag not server lag, and yes you can disable it showing the items in there by modifying its code but your players will probably complain more than if you just ban it, and diamond chest has the exact same inventory space. Travelling entities in buildcraft pipes cause minimal client lag, it's when they start dropping out on the floor at the other side when nubs make their factories overflow that it causes problems.

Project Table craft events can be caught with PrepareItemCraftEvent but that does nothing for automatic crafting tables, especially the MK2 as it caches the actual recipe container and processes it itself separate from any of the vanilla functions which contain the bukkit craft events, however a plugin which actually removes the recipe from the container on startup solves that issue (that's what I do with my plugin). I heard something about tekkit restrict having recipe banning but whether it implements it that way I don't know, but either way I would NEVER recommend tekkit restrict for anyone for any reason, the dev has decided to obfuscate his plugin in the later releases, despite there being nothing worth stealing out of his code, so goodbye any chance of proper profiling of it's impact on the server, plus he claims to have fixed many dupes which aren't actually fixed, namely the transmutation tablet dupe which mostly comes down to his lack of understanding of the actual reason why the dupes exist, but that's a little off-topic... Short answer - NoItem nohold should take care of most of the issues with items like the morning star, but if you are looking to outright ban an item and you don't want it in your server at all then your best bet is to find a plugin which actually removes the recipe, with NoItem as a backup just incase someone happens to get it some other way, such as the alchemical tome + trans tablet.

Not really a fix, the bug is caused by a slight code oversight in immibis core and can be recreated with more than just the block breaker, namely EE tools / destruction stuff, plus it works on any immibis BlockCombined block and so any block which contains an inventory and is part of immibis or part of a mod which uses immibis = dupe. I posted a fix in another topic a while ago; BlockCombined.java in getBlockDropped function after "var7.add(var13);" add "var10[var12] = null;" That will fix it completely for all immibis inventory blocks.

No, it doesn't make sense, which is why it boggles my mind every time I see a plugin with the exact behaviour I described. If plugins were coded correctly then this would never be an issue, but plugins frequently are not coded correctly and are filled with performance holes 9 times out of 10 related to doing work in the main thread which has no business being run in the main thread, most of the time I/O work.

Press the 'O' key and the interface should reappear.

I'm not sure an SSD is as useless as you say Djinnii, the 1.2.5 server is notorious for doing a lot of I/O operations synchronously in the tick thread and yes on it's own may not be a definitive reason to get an SSD, but the majority of plugins use flat file storage or at best sqlite, especially the popular block logging plugins, and I know from experience that they also do all their I/O work in the main thread and most definitely do not keep their storage files loaded in memory. If you are running a nice vanilla tekkit for some friends then sure a standard HDD will see you good, but the second you start putting plugins in there which most people will consider essential to the running of a medium/large server SSD becomes essential if you want to avoid block placement and break lag under heavy load.

Actually, after taking a closer look at the rock crusher class, the functions which would be broken by removing the newer buildcraft API from railcraft won't ever be called because railcraft will only try to use them if buildcraft 3 is installed, which it's not. Fixing that code however means the possibility of making the rock crusher require buildcraft power from buildcraft2.

For singleplayer sure, but for multiplayer that fix doesn't need to be in the client as it's tile entity tick code which the client doesn't run in multiplayer.