Occurred while placing a chiseled stonebrick panel on some Mekanism Pressurized Pipes. First panel went down without issue, second one crashed the game. The first placed has nothing around where the panel is, the second has one pressurized pipe that goes 90 degrees towards where the panel is.

Modpack is ATM 3, v4.1.

For any bug reports please provide the following,

• MC Version: 1.12.2
• C&B Version: 14.8
• Do You have Optifine: No

Logs attached includes the fml-client-3.log for the log set that happened with the first crash. fml-client-latest.log for the last attempted join. latest.log and fml-junk-earlystartup.log attached for good measure.
logs_1.tar.gz

And both Crash Reports.

crash-2017-10-05_16.14.26-client.txt
crash-2017-10-05_16.23.34-client.txt

I've requested logs from Goshen, just in case.

I have what seems to be the same issue: #322

All I did was place a bit over a Mekanism cable. I’m basically unable to use this mod.

@PapiDimmi, You can try to use the alternate build of MCMP above but it seems to expose issues with other mods.

There basically nothing I can do, this is a MCMP issue, and @amadornes hasn't released that build, or made any progress in almost a month.

If this continues much longer I might have to add a setting to disable/enable MCMP support so people can disable it.

Can confirm this still happens with Mekanism.
#325

@RacerDelux It’s spelt “Mekanism.” Just saying.

Anyway, I think it happens with every mod.

I knew that... it is late. I saw a build 2.3.4 up above, does that fix it? Not released on curse yet.

@RacerDelux Not really. The clients still crashes, just slower. At least with Mekanism

So, what is the deal here? Is a fix being worked on?

@AlgorithmX2 I hope this will be a config option, right?

It is an option, but from what I can tell right now even if you enable it C&B outright crashes when used with MCMP.

I just don't know what else to do at this point, with so many people reporting this issue and crashes pouring in left and right like this.

@AlgorithmX2 The thing is, a "fixed" version is available, I might look into the issue myself in the near future and I definitely wouldn't want to stick with a downgraded C&B. (Even if the functional version of MCMP is limited to non-Curse mod sources for some time. Not all of us depend on Curse having the build!)

You mean the build above? Tests using that build have only resulted in different crashes, ones that crash in other mods.

As I said, it is an option, if a build of MCMP is available that works there would be no issue re-enabling it.

Anyone experiencing crashes can try https://dvs1.progwml6.com/jenkins/job/Chisels-and-Bits/93/artifact/build/libs/chiselsandbits-14.0.93.jar which disables MCMP Support.

What’s the point of MCMultiPart if Chisels & Bits doesn’t require it?

I don't understand your question, C&B has never required MCMP, MCMP is a multi-part mod for cross compatibility and multi-parts.

Without support for MCMP C&B cannot be used in other mod blocks. However in MCMP's current state its just crashing, so i have little choice except to disable support until it can be fixed.

So, without MCMultiPart support, will Chisels & Bits not work with other mods at all? Can I not place bits in the spaces of modded blocks, such as Mekanism cables?

That is correct, since that is the cause of all the crashes.

Oh. Well, that’s unfortunate, since some mods, such as Refined Storage and Mekanism, don’t have any facades.

Can someone try https://dvs1.progwml6.com/jenkins/job/Chisels-and-Bits/95/artifact/build/libs/chiselsandbits-14.0.95.jar

I've temporarily removed the setting mentioned before and tried something else, the issue it self seems to be tied to the world wrapper related code in MCMP, C&B might be the only mod that disables it.

Hopefully this will work as a sort of patch to fix the crash.

Addendum to above, important that if your trying this new C&B Build use the public release of MCMP, the idea is the work work around the issue that was fixed by that build, thus circumvent the issues that build seems to be causing.

@AlgorithmX2 Trying it now for you now. If it fixes the multipart issues of crashing will you push a build to CurseForge? I've had a lot of reports of this with the Direwolf20 mod pack and it would be nice to have some work around for it, even if it disables multipart compat.

The newest build doesn't disable MCMP Support, its a potential work around. Its something I came up with, because I don't want to disable MCMP support. So make sure to test it in blocks with other mods. I tested it with Mek in Dev and it seemed to be working fine.

If that doesn't work however I'll have to go back to my original plan.

Depending on the result, I'll push one or the other to curse forge.

Okay I'll test now :-)

@AlgorithmX2 It appears once again your genius has triumphed. No crash :D

Alright, I've re-added the option, but the default will now be true, if anyone i using the version where it was false you'll want to try re-enabling it.

I'm not sure if anyone will ever use the option, but since @amadornes is MIA having it seems prudent anyway.

So without further ado, I've uploaded the C&B v14.10 to curse forge.

Hopefully this will effectively solve the issue at least as much as It can without MCMP being patched for the real issue.

❤️

@AlgorithmX2 So, you are thinking that your new C&B build works better with the release version of MCMP than the exp build of MCMP was working with the previous C&B build? (If that makes sense :D).

Would there be any point in using both this release of C&B and the exp MCMP?

Thanks :)

It should work with the release version of MCMP, the patched MCMP seems to cause another issue which causes other crashes, at least that seems to be the consensus above.

So I dowloaded the new C&B and tested in test world with Refined Storage without the crash that was happening previously and was very pleased with that. Went in to my normal game and chiseled up my RS cables with plates made from the saw and it seemed to work prefectly. Now upon relog I log in and all the plates and cables have now converted into ghost blocks. So it seems the new version fixes the crash, but not the ghost block problem with Refined Storage cables.

@Neb2566 did you try the MCMP Build that @amadornes linked above? I'm curious if that fixes it. If the whole block is disappearing it sounds like yet another MCMP issue.

I wasn't experiencing anything like that with mechanism, so I can only assume its something to do with how Refined Storage and MCMP interact, I think they use a different approach.

@AlgorithmX2 Are you referring to the exp build? That I have not, will try now. Didn't even realise there was one until you mentioned it. Derp.

And yes, both the cover and RS cable was invisible and I could not interract with the bloc in any way shape or form. But atleast the new C&B fixed the instant crash, so thats something :P

Update: So I tried the exp build of mcm but no luck, still ghost blocks after relog,

@raoulvdberge Can you check this out?

Caused by: java.lang.NullPointerException
at com.raoulvdberge.refinedstorage.tile.TileNode.getNode(TileNode.java:85) ~[TileNode.class:?]
at com.raoulvdberge.refinedstorage.tile.TileNode.readUpdate(TileNode.java:72) ~[TileNode.class:?]
at com.raoulvdberge.refinedstorage.tile.TileBase.handleUpdateTag(TileBase.java:90) ~[TileBase.class:?]
at mcmultipart.api.multipart.IMultipartTile.handlePartUpdateTag(IMultipartTile.java:121) ~[IMultipartTile.class:?]
at mcmultipart.block.TileMultipartContainer.readParts(TileMultipartContainer.java:372) ~[TileMultipartContainer.class:?]
at mcmultipart.block.TileMultipartContainer.handleUpdateTag(TileMultipartContainer.java:300) ~[TileMultipartContainer.class:?]
at net.minecraft.client.network.NetHandlerPlayClient.handleChunkData(NetHandlerPlayClient.java:834) ~[NetHandlerPlayClient.class:?]
at net.minecraft.network.play.server.SPacketChunkData.processPacket(SPacketChunkData.java:110) ~[SPacketChunkData.class:?]
at net.minecraft.network.play.server.SPacketChunkData.processPacket(SPacketChunkData.java:20) ~[SPacketChunkData.class:?]
at net.minecraft.network.PacketThreadUtil$1.run(PacketThreadUtil.java:21) ~[PacketThreadUtil$1.class:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) ~[?:1.8.0_144]
at java.util.concurrent.FutureTask.run(Unknown Source) ~[?:1.8.0_144]
at net.minecraft.util.Util.runTask(Util.java:53) ~[Util.class:?]

I get this in my log when I load a world with mixed Refined Storage blocks, I tested with C&B and with the MCMP test mod that amadornes gave me for integration testing.

@AlgorithmX2 Here is TileNode:85 for ya:

    @Override
    @Nonnull
    @SuppressWarnings("unchecked")
    public N getNode() {
        if (world.isRemote) { // :85
            if (clientNode == null) {
                clientNode = createNode(world, pos);
            }

            return clientNode;
        }

        INetworkNodeManager manager = API.instance().getNetworkNodeManager(world);

        NetworkNode node = (NetworkNode) manager.getNode(pos);

        if (node == null || !node.getId().equals(getNodeId())) {
            manager.setNode(pos, node = createNode(world, pos));
            manager.markForSaving();
        }

        return (N) node;
    }

Easy: it's crashing because world is null (and that method absolutely needs a world to provide a correct network node).

Problem is that a world is not set before calling methods on a TE (which I believe was the same problem you had).

That method is called from the handleChunkData packet... ( I provided the rest of that stack trace above ) and there is no world. So I guess this was another change to MCMP? I assume this used to work?

Also, its not crashing, the Tile Entities are just corrupting in on the client. So they appear as ghost Blocks.

My issues were that the world was getting set to null when MCMP updated its states, this happened because I was telling it to not give me a world wrapper, by accepting and unwrapping the world wrapper myself I worked around that crash. Of course the patched MCMP Above fixed my issue, but it doesn't fix this issue.

Not sure there is a fix for this beyond a MCMP patch. Not sure if there is anything you can do?

This used to work indeed (it works when the TE is not a multipart TE...).

And not sure if I can do anything, the node is needed for the chunk update...

Is it possible to delay those calls if the world is missing until Part.onLoad? Or something like that?

No.

I don't control that call stack, it crashes while sending a chunk update. This really has to be handled mcmp side..

@asiekierka At this point I've worked around the C&B crash by using the world wrapper, which just leaves the stack trace for Refined Storage a few posts up, its missing its world in handlePartUpdateTag, which means that Refined Storage is throwing an NPE in the part packet method resulting in missing tiles on client side.

Of course that was already fixed in exp build for MCMP above, though for some reason it causes other issues, I don't know why. So at this point that fix is really more a liability then a solution? Unless we find out why its causing other issues.

I've already messaged raoulvdberge as you see above with regards to the issue, but he sees no means of fixing it on his end.

That's really all I know at this point, and the only issue reported since I released the work around.

@AlgorithmX2 What is the issue without the workaround? I want to get to the gist of it to see if there's some common reason behind it all.

@asiekierka Its what amadornes/MCMultiPart@fad7549 was supposed to fix, null worlds for mods not using the world wrapper. The fix seems straight forward enough, if the world is null send the actual world, other wise send the wrapped world.

I imagine that I'm the only one that was doing that, and honestly my work around wasn't all that terrible once I tracked down a reasonable solution.

I honestly don't know why this would cause a crash with mechanism, maybe it didn't, but it was reported to cause issues above.

The common theme is certainly null worlds, I'm not sure changed but the is certainly the focal point. I had high hopes that the issue's were limited to only world wrapper opt-out mods like C&B, but the exception trace above proves that there does appear to be a more wide spread issue with some changes specific to 1.12.

@Neb2566 I guess that's it then. I've done what I can.

I suppose if you don't use C&B with any other mods you can turn off comparability so that you don't accidentally place any C&B bits inside a Refined Storage block. If you do use it with other mods, well I guess try and be careful?

sigh so much for MCMP....

@AlgorithmX2 I'll look into these problems when I find some time, alright? I'll have a bit starting tomorrow...

If you could summarize what has to be looked into so I can get right to work, I'll be very grateful.

@AlgorithmX2 Well thanks for trying :) RS was the only mod that I need C&B for to hide my cables. So I guess just wait and see if a fix is ever made. Much appreciated tho taking your time to try and figure it out!

Just linking to MCMP Related Issue, amadornes/MCMultiPart#106

So far, this seems to have fixed the issue #106. Hopefully, I will be able to test more extensively later on this evening.

Found the issue, fixed the issue, here's a build which fixes the issue.

Does this build have any more issues?

Can confirm, seems to be working now, been testing covers made with the saw and have relogged several times without any issues so far. :D

Same here. It also fixed some odd behaviours with Immersive Engineering metal press glitching out and RFTools wireless redstone transmitters block rotation. cc @BluSunrize @McJty

It fixed the issue for me as well, however it still ghosts, and I need to logout/login for it to appear. It's working fine after the logging. I'm attempting to place it on Refined Stored cables.

MCMultiPart 2.4.0 is released!

Its been a long road, but we have finally arrived. Cheers for everyone who helped out, especially to @asiekierka who did the PR and some how got a hold of amadornes to get a release.

I'l leave this open for a while so people can see it.

Sorry for not looking into this earlier.

@bubblesayoyo Anything in the log? Latest versions of everything?

MCMultiPart-exp-2.3.4_52 ; chiselsandbits-14.9 ; refinedstorage-1.5.27

I don't see anything in the logs, it's a server, if you point me to which I can upload it.

https://media.giphy.com/media/xUNda515E8XoRH0K2Y/giphy.gif

Try updating to Chisels & Bits 14.11, as that version includes important MCMP fixes added in 14.10.

I'm sorry after going through all this, I thought I had everything up to do date. Confirmed working perfectly with the CB 14.11. Thanks again.

Btw forgot to mention I am using chiselsandbits-14.11 together with the mcmp fix.

Don't worry about it @asiekierka, it's not your responsibility in the first place.

Sorry to report that this is an issue again when placing chisel and bits covers on refined storage cables.
It breaks data in the chunk where cables are placed. StorageDrawers inside the chunk get the wrong orientation, Thermal Expansion cables get disconnected into single nodes, tanks and Dynamos get the magenta missing texture and the block space where cables had chisel and bits become unmovable ghost blocks. The only way to solve it is to rollback or remove the blocks using MCEdit. It appears to mess up NBT data for all blocks in the chunk. Depending on the mod it becomes visual bugs and ghost blocks, worst case it causes server crashes when the broken chunks are loaded.

I'm sorry but I have not to tested the latest versions yet.

Running latest Direwolf20 modpack which has mods version:

• chiselsandbits-14.11.jar
• MCMultiPart-2.3.3.jar
• refinedstorage-1.5.25.jar

This occasionally happened back when I was hosting a server on 1.11.2 as well and my only workaround unfortunately was to eventually completely remove chisel and bits.

Best regards

@cragrim Your using an old version of MCMP you should update to 2.4.1

This is definitely interactions between C&B and MCMultipart, hard to say what the bug is in either case, both crashes appear to be unrelated at first glance, but upon closer inspection both seem to be related to missing world / position / tile data.

That data is more or less supplied by MCMultipart since Parts live inside of it, but i'll have to do some digging to know anything for certain.

@amadornes anything change recently I should know about?

I did confirm with Goshen that the issue has no effect on the server itself. Unknown if it does on the items and pipes related to it as I can't check at the moment. I'll test on a second PC this evening, though I fully expect the same result.
Thanks for looking into it and all you do,
John

Oddly enough... a freshly set up ATM 3 v4.1 on my normal Win 10 gaming system, works fine at first. Unfortunately, the moment I interact with the tube, crashes out again. And then it appears to kill the server as I get a server closed when that interaction happens. After it came up, I rejoined, attempted to interact with the panel instead, no joy, kills the client entirely as soon as the cursor comes to where the panels hitbox would be. Restarting the client now to see if it comes back and lets me in or now.

Outside of the Windows 10 and fresh setup, this system does have a bit more horsepower than my T430s running Manjaro. I attempted to keep moving the cursor right as the game was logging in, all the way until it came in. I tried the same on my laptop while testing earlier to no avail. I noted one error tied it to TOP in the logs of the previous crash, something tying to reporting of the block being looked at. That was also why I tested the looking away stuff.

After the server came up, looking away works again. I guess I need to avoid looking at that one specific panel.

I can attempt to procure more logs if necessary but I can confirm from past experience this same crash can happen with chisel'n'bits ins the same blockspace as a Refined Storage cable/part as well.

Another on the ATM discord mentioned this

amadornes/MCMultiPart@c36f9f1
For
amadornes/MCMultiPart#92

It could potentially be caused by this, but it shouldn't be. I didn't change anything related to occlusion testing, so it may be on Mek's end.

I'm pushing out a new build in a bit. There have indeed been a few changes, but they're all internal and should require no changes in anyone's mods. It was just a minor derp :P

Appreciate it @amadornes. I'll make mention to @OrdinatorStouff in hopes of getting it pushed into ATM 4.2. Question to go with it... noted the panel didn't block a connection from one Mek Pressurized to another. Is that the expected result or is it caused by this?

Thanks again for the help :)

Can anyone else confirm that this issue is fixed or still an issue? I have tried with the newest MCMP and I'm not seeing any crashes, however I cannot be sure that the issue is fixed since I'm not 100% sure on how to reproduce.

Still an issue, at least here.
C&B: 14.8
MCMP: 2.3.3
Mek: 9.4.1.326

Was placed on a Mek Logistics Pipe
Crashlog when I placed the bit: https://pastebin.com/34VpVqJs
Crashlog when I logged in again: https://pastebin.com/G8Vtpk4s

@amadornes
https://github.com/amadornes/MCMultiPart/blob/7020e58adac39fcc0158bd0374072588b4c007be/src/main/java/mcmultipart/multipart/PartInfo.java#L147

So.. basically unless your using a world wrapper you get your world nullified? At least that is what I'm seeing here, it seems to be where my worlds are getting cleared.

The derp Algo found may have actually been what was causing it. If someone could test it with this new build of MCMP, that'd be greatly appreciated :)

https://maven.amadorn.es/MCMultiPart2/MCMultiPart-exp/2.3.4_49/MCMultiPart-exp-2.3.4_49.jar

Tests with the Exp-2.3.4_49:
Crash after some 5 seconds in my previous world, which I did the first crash test in (at least not instant)
https://pastebin.com/f56ADiMc

Crash in a new world, after applying some bits to a Mek Logistics Pipe.
https://pastebin.com/eyMZs0xn
Bits were placable without a crash, but eventually (after around a minute?), it did crash.
Bits that were placed at the bottom, didn't show until I placed more.

(just noticed the crashlogs are pretty much similar)

Seems like it fixed my issue at least...

New crash site: https://github.com/aidancbrady/Mekanism/blob/master/src/main/java/mekanism/common/block/BlockTransmitter.java#L178

Seems like something equally sketchy... *throws a walrus plushy at @amadornes*

@amadornes Looks like your update to multipart fixes the crashing for me. I still have a problem in that the game client (when on a server) doesn't seem to know the multipart is placed down on mekanisms items. Loggout out causes the item to render correctly. Alternatively, If I attempt to place a second one on top of the first it will display correctly (But then I have to log out to recover the item).

I am not sure if this is an issue with Mekanism, C&B, or MCMultiPart... so figured I'd reply to this issue.

This is still a issue for me: mekanism/Mekanism#4771

#### Issue description:

Attempting to place a Chisels & Bits (MCMultiPart) cover onto a Mekanism gas pipe instantly crashes the game. Mousing over the pipe while holding a cover will also crash.

Interestingly, it does still place the cover; once you load up the game the cover will be in place and working normally.

In some cases, a crash while looking at a pipe will lock you out of a world, as when you load in you'll still be looking at the pipe and you will instantly crash again.

#### Steps to reproduce:
Tested only in singleplayer.
1. Place Mekanism gas pipe (untested with other pipes)
2. Craft a Chisel & Bits cover using a Diamond Saw (tested only with thinnest panel made of obsidian)
3. Place onto or look at gas pipe while holding the cover.

#### Version (make sure you are on the latest version before reporting):
**Forge:** 14.23.0.2512
**Mekanism:** 9.4.1.326
**Other relevant version:** Chisel & Bits 0.0.14.18, MCMultiPart 2.3.3

#### If a (crash)log is relevant for this issue, link it here: (_It's almost always relevant_)
Placement crash log: https://pastebin.com/gaJh8eQa
Mouseover crash log: https://pastebin.com/ThbcuvZC

edit: This is with the latest public build of C&B/MCMultiPart, I'll test it with the updated version you posted.

edit2: it still crashes in some cases, but takes a bit longer: https://pastebin.com/GdaRC0Bj. In other cases the covers are simply invisible as other people have mentioned, not sure what triggers the crash.