http://maven.amadornes.com/MCMultiPart/MCMultiPart-experimental/2.0.0_88//MCMultiPart-experimental-2.0.0_88-universal.jar

Yeah, there aren't any versions after 1.3.0_87. I can't find a way to stop it attempting to replace the version I'm giving it.

Here's the original file, http://bit.ly/2iLIRZC

You can try to recreate the folder structure, but another fix is to remove the dependencies from the .jar then use MCMultiPart 1.3.0

use the version that mek is auto downloading till he can remove the dependancy. otherwise you will always have duplicates if you add the mcmultipart mod to your pack. Especially if this is a curse/ftb pack.

This is exactly what Mekanism is calling for on download. I've found a work around on ATL.

The 1.3.0 build of MCMultipart is a lot older than the 2.0.0 build. Using the old version causes a crash every single time you try to remove Mek cabling using a Pickaxe and some other tools. Sucks. What I did was just download the "All the Mods" Pack on curse and take the copy of MCMultipart 2.0.0 out of the mods folder there and throw it in my instance. Works like a charm. No messy deleteing dependencies that way and no overwriting from other mods since 2.0.0 is the "latest" version.

@ate0ate I was unable to reproduce that specific issue with 1.3.0.

I posted this earlier, but here is the link again to the 2.0 version (not in bitylink) so you don't have to go download a large pack just to get it.

I will continue to use 1.3.0 until my next pack update which then I will patch with the 2.0. We just needed a quick fix this morning and removal of dependency was the quickest option at that time.

http://www.infernoworldorder.com/uploads/2/7/2/3/27230849/mcmultipart-experimental-2.0.0_88-universal.jar

This issue has been fixed (it stops auto downloading the wrong file) in the 1.10 branch, sadly the 1.10 file found on the site is made of the master branch. There is an issue open with the request to merge the 1.10 in master (or build 1.10 from the 1.10 branch).

@thommy101 Are there any functionality differences in 1.3.0 and the experimental that is being called for by deploader?

On our pack, we just removed the dependency and installed 1.3.0.

Should we expect anything to break that you are aware of?

1.3 is fully supported, I don't even know where I have to look for any 2.x version.
My fix for it (I'm just a helpfull minecraft player/programmer) was to depend on mcmultipart and remove deploader. I'm running a server with mcmultipart 1.3.0 without problems.

Another way of solving it is building the latest version from the 1.10 branch.
1.10 branch contains a couple fixes, one of them the removal of deploader.

Here's a build of my own branch, build of 1.10 including all fixes of my which are still open pull requests.
MekanismAll-1.10.2-9.2.1.thommy101_dev.040117.zip

Thanks I'll check this out.

@ate0ate what you're describing is not a mcmultipart issue, but an old Mekanism issue that's fixed in the latest release. It would also crash with V2.0.0 of mcmp if I remember correctly

@oryfoxer7410 Mekanism delete it when i load the mod

@thommy101 Works perfect, thanks for making it :)

so how does this work around help a pack that is hosted on curse?

You can put your own jar file in a modpack, mekanism isn't hosted on curse.

Amadornes added the needed version back in that people can run Mekanism.