Jelato Foot

I'm not sure if this is the right board to be posting this in but here goes I guess, in this thread I'm gonna post the solutions I have used for some of the reported issues with the 3.1.3 dev build, hopefully it will help some people out that are having these issues until the technic guys can get everything fixed up. This thread however will not contain drag and drop fixes for your server as I don't want to step on any toes by distributing modified versions of other people's code/mods without permission. Issue: java.lang.RuntimeException: java.lang.NoSuchMethodException (IC2) Cause: Issue in the port, some package references remain as net.minecraft.src Solution(s): Replace occurrences of "net.minecraft.src" with "net.minecraft.server" in ic2.api.ElectricItem ic2.api.NetworkHelper ic2.common.EnergyNet Issue: java.lang.NoSuchFieldError: energyStored / java.lang.NoSuchMethodError: buildcraft.api.PowerProvider.receiveEnergy(I)V Cause: Railcraft update contains a newer buildcraft API which is conflicting with the version of buildcraft running Solution(s): Remove the new buildcraft API from the updated railcraft jar and then change the TileEntityRockCrusher's 2 references to the new API so they conform to the old API (simply changing the args from floats back to ints) (second part not actually required for functional rock crusher, but is required if you want to port the rock crusher to buildcraft2 and require an energy input for it) Issue: java.lang.IllegalArgumentException (to do with ComputerCraft) after merging 3.1.3 with 3.1.2 files Cause: Server tries to load 2 versions of ComputerCraft, in 3.1.2 the CC mod is a directory called ComputerCraft in the mods folder, in 3.1.3 the CC mod is a zip file Solution(s): Delete "ComputerCraft" directory inside the mods directory Issue: java.lang.RuntimeException: java.lang.NoSuchMethodException: ic2.common.TileEntityNuclearReactor.tickRate() Cause: Mismatch between IC2 nuclear reactor API and old version of IC2 Nuclear Control mod Solution(s): Updating to the new version of the nuclear control mod SHOULD work, however it's been reported that it doesn't, in which case you need to change the ic2.api.IReactor interface function getTickRate() back to tickRate() and also do the same in ic2.common.TileEntityNuclearReactor Issue: [WARNING] Could not retrieve Forestry item identified by: ... Cause: Railcraft is trying to interface with forestry container items, which don't exist because tekkit doesn't run forestry Solution(s): Ignore it, it's not an error and won't cause any problems These are all I really know of atm, I'll try and keep the thread updated with any more that I come across in my testingz, for those of you who don't know how to do some of the code changes required for some of the fixes, google around for how to decompile java classes, it's incredibly simple stuff just make sure you backup your world ;)

Yeah that one is because of the update in railcraft, which contains a buildcraft API which is a later version than the buildcraft mod on the server and buildcraft's api is then overwritten by railcrafts implementation of it, in which the energy storage stuff has changed from integer to float in that version, it's trickier to solve but the easiest way to do it is remove the buildcraft API from the new railcraft jar, but if you do then you have to either update the TileEntityRockCrusher class to use the old api or just not use the rock crusher at all, or it will give the same error again.

This issue with IC2 isn't just limited to advanced machines, if you use uninsulated wires in a power network it will crash because of the same issue, plus I've not tested it but looking at the code if you use any of the batbox/mfe/mfsu carts in railcraft it should crash with the same thing too, all in all this port of IC2 is no bueno... It's a relatively simple fix though, hopefully it gets fixed up pretty quick.

I don't see why not, unless another mod depends on AM which I'm pretty sure none do, but you will have to make sure every single AM block is out of the world or it will probably crash when one of the chunks is loaded.

Removing your advanced machines before the upgrade won't help much unless you plan on preventing people from using them after the upgrade, I suggest just not upgrading until it's fixed by technic.

The latest version is the dev build, 99.98% of servers run the recommended build so you shouldn't be running the dev build unless the server you are playing on specifically tells you to.

There's a bug in the port of that specific IC2 version that I guess the technic guys or the guy who ported it missed, the API in several places is using the wrong package for some entity classes so it's not a compatibility issue and updating advanced machines wont help as its specifically a problem with IC2.

This topic made me giggle, let's ignore the fact that you are complaining about an unfinished dev build, I'm just surprised that you pick this dupe out of all the ones in tekkit to complain about, one that most server owners are very much aware of and some have even fixed. Considering the immibis core ported source is included in the jar it doesn't take a genius to find and fix that dupe. BlockCombined.java in getBlockDropped function after "var7.add(var13);" add "var10[var12] = null;" I also love how you included the changelog up to and past the part which cannot be applied to tekkit due to those updates being for 1.3.2, you seem quite clueless, but considering there are far more damaging and less obvious bugs in tekkit my mind is still boggled as to why you would complain about this one of all things...

That's actually not true, and a very common misconception. Items inside buildcraft pipes are an instance of a buildcraft class called EntityPassiveItem which is wrapped inside the EntityData class when moving throughout the pipe network, despite both classes names, neither class is a true entity as they do not exist in any entity container within the minecraft server other than buildcraft's own, and neither extend the vanilla Entity class. But that's not the point, the main issue with disconnect.overflow is why it actually arises, which is when there is 1048576 bytes (1MB) of data pending to be sent to the client's socket, this can happen for various reasons the top 2 are usually the server's connection is too slow to send the data or the client's connection is too slow to receive it at a rate high enough to clear the buffer. The best way to eliminate this issue is to examine what on your server is sending so much data, if it is buildcraft pipes then you can configure the network update rate in the buildcraft configuration, however if it is redpower tubes you are shit out of luck and will have to tell the owner of said pipes to slow down their timer or scale back their machine(s). Large amounts of drops on the ground is a possibility but the amount of drops would have to be extremely large as item entity updates are sent to the client periodically not every tick and so shouldn't actually cause that issue.

The client code for the tank cart is bugged just the same as the server is, so even with the fixed server code it will still look bugged as hell in the client and make people think they did dupe with it, until their inventory updates or they relog, at which point the "duped" items will no longer be there. (because they never existed in the server) That being said, if you are interested in fixing the dupe it's quite simple, it's yet another inventory index f**kup. ContainerTankCart class inside a(int) the dupe is the second call to Container.a(ItemStack, int, int, boolean) the first index (currently 29) should be 30. The issue by which the item fountain is created, which is only a client bug and doesn't actually dupe those items, is also a similar index screwup which when corrected in the server still appears in the client, so fixing it is pointless.

The only dupes tekkitrestrict actually fixes fully are the RM furnace one and black hole band one, every single other dupe still works. So no, that's not a solution.

Ban triangulators. Or alternatively you could remove the code which outputs that message, AddonPacketHandler.java line 94 of WR Addons if you are wondering...

Turn your firewall off.

One or more of the mcmmo chunklet data files appears to have been corrupted, finding which one and removing it is probably your best option

First of all, you need to change server hosts if an extra gb of ram costs you a hundred bucks, that is stupidiculously expensive given todays ram prices, you could buy the ram yourself and ship it to them for less than that. Secondly, the main issues which come out of all multi world plugins, not just multiverse, from my experience are a result of the mod makers assuming there is always going to be a max of 3 worlds loaded (world, nether, end), or in the case of EE and stuff like trans tables there's a bug with their tick math which stops it processing on certain worlds. I would suggest staying as far away from multi world plugins as you can unless absolutely necessary, any multi world plugin you use which creates and loads new worlds WILL break transmutation tablets. EE also has a lot of things coded in such a way which, as mentioned by Wendo, only work in the main world. Unless you want to/can fix the problems with those mods, or aren't particularly bothered about those mods breaking, multiworld plugins = big nono.

There is an error in your railcraft configuration file, replace it with the default one.

http://forums.technicpack.net/threads/could-not-reserve-enough-space-for-object-heap.2240/ Make sure you read the sticky topics in the bug board and tekkit general sections, most of problems you may encounter are posted there.

The majority of the flaws with core protect are down to lack of knowledge on the creators part, so unless they hire a new developer any time soon I don't see any of those issues being addressed. Hawkeye has none of those issues, it does have a few issues of it's own most if not all of which have fixes posted on their github, and none as monumental as an unusable mysql backend. So the fact it is not actively updated any more is a non-issue until tekkit upgrades to the next minecraft version, at which point the choice of logging plugins is increased anyway. And yes, hawkeye does rollback all tekkit blocks except microblocks and pipes, same as core protect.

I do not recommend this plugin, I suggest using hawkeye. The in-game log querying for this plugin is very limited compared to others available. The mysql database design is the worst I have ever seen and makes out of game querying and rollbacks take ages on large databases due to it's strange double storage of player names and non-existent indexing. The field length for sign text is too short to handle the creator's own anti-injection code which escapes quotes, which causes a string truncation exception and so doesn't log the sign. He should be using parameterized queries instead which then negates that entire issue. He also extremely overuses runnables to do the asynchronous logging which creates large overhead by creating new threads for each log instead of just queueing them to be processed by a single thread. All in all, Hawkeye is superior, it's much better coded, it has far better search functionality, both in-game and through the provided web interface, it's just a shame it's no longer actively developed.

EntityHuman.java:1345 -> player.netServerHandler.sendPacket(pkt.getPacket()); the fake players which mods create have a null NetServerHandler instance, and ee doesn't check if the player trying to open a gui is a real one (as most mods don't), so boomboom

Add this to your redpower/redpower.cfg file in the deployer.blacklist= "27562:0,27562:1,27562:2,27562:3,27562:4,27562:5,27562:6,27562:7,27562:8,27562:9,27562:10,27562:11,27562:12,27562:13,27562:14,27562:15" No more crashycrashy :)