[0.8.1] Reversing conveyor belt causes the game to lock up

Clicking the hull-left conveyor belt on the GeoCorp harvester in the "conveyor bug" save causes the game to lock up indefinitely about a second later. If I disassemble the belt completely and then reinstall it, it seems to work fine unless I save and load the game, after which the error occurs again. Saving the harvester as a snapshot, sending it to inventory, and then respawning it causes the bug to happen as well. Happens every time except for when the belt is removed and replaced manually, and even then the error returns after saving and loading. The error was discovered in campaign mode, but occurs in R&D as well if the tech is loaded.

I do not know what exactly precipitated this bug while designing the tech; I was trying to find an optimal way to pipe resources from the front to the back to be dropped on a collector pad (please, please just let us directly push/pull from conveyors to collectors somehow!) when I noticed that the left belt had some conveyor blocks moving in the opposite direction as the rest. When I clicked the belt to try correcting this, the game locked up. Unfortunately I didn't think to save the game while the belt was in that mixed-up state before TerraTech froze, but the locking up part is easily reproduced by clicking the belt.


edits:

• Added snapshot

• Replaced picture indicating which belt with a picture showing the belt after clicking it, with the first conveyor block in the line (starting at the receiver) moving in the wrong direction relative to the rest of the belt. This picture was taken after loading the game, removing the belt, rebuilding it, saving the game, then reloading the game from the new save and clicking the belt to reverse the flow and produce a lockup.

 

I've just taken a look. The conveyor looks like it's all flowing the same way in "conveyor bug" save you've uploaded, and the snapshot (not as you've pictured in the .jpg above). Then right clicking the left side conveyor doesn't change the direction of that one block attached to the receiver, and the game locks up, as you say.

It doesn't generate a crash dump folder, but I've attached the log file.

Loading your auto-save the tech immediately disintegrates...

Is it possible that you used Undo while building that part of the conveyor? There have been undo conveyor bugs similar to this in the past.

@QuackDuck had a similar issue reported here, when conveyor hadn't properly registered it's contiguity.

 

I noticed that same strange disintegration with that autosave, I figured it was some weirdness with the autosave maybe occurring at the same time I sent the tech back to the inventory. The belt appearing "normal" at first is correct; the jpg was printscrn'd while the game was frozen. I'm also certain that I used the Undo command a lot while messing around with this thing; I'm kind of clumsy with placement when doing rough sketch techs so I frequently accidentally remove keystone blocks and have to quickly undo the damage .

I'm confused by the persistence of the behavior after rebuilding the belt and saving/reloading; I haven't yet tried building an exact copy of the tech from scratch, though, just that one section.
Specifically that the conditions for the error are:

• Load, click belt: lock up
  
• Load, remove and rebuild belt, click belt: no error
  
• Load, remove and rebuild belt, save, reload, click belt: lock up

 

Good to know. Thanks for the report and reply. And some neat looking techs there, incidentally.

This was the old bug that was very similar. But I can't recreate it now, messing about with Undo to get split direction conveyors causes no crashes... So perhaps something different going wrong with the game's internal model of block connection data (as with other recent bugs).

 

Today I went into R&D mode to have another stab at some things, and partially rebuilt the problem tech during that. Initial attempts to recreate the bug failed, but after some time it began happening again. I wasn't sure if I had used Undo this time, so I remade it a third time very simply and started messing about. Sure enough, once I used Undo a couple times, the bug began to appear. After some repeated attempts, I think I've narrowed it down a bit. In the included save are two bug-related techs, conveyor bug WIP2 and conveyor bug WIP3. WIP2 is already afflicted by the bug. In order to trigger it on WIP3, remove the forward left 4x4x2 large square block, this should cause the forward left wheel to detach and bring up an Undo prompt. Once you've done so, attempting to reverse the hull-left belt will lock the game up. The hull-right belt exhibits no issues, and nor does triggering an Undo off of any of the other 4x4x2 squares.

Another note: On WIP2, resources will not progress past the first conveyor on the hull-left belt starting from the collector, seems like an important point since that's the belt that doesn't reverse properly either.

 

Ahh, very good work, well done! @kae plx.

Just to check another thought of mine - you didn't reload the save too, did you? I'm a little suspicious of reloading (without exiting the game.)

Note link to this thread, where @QuackDuck saw his conveyor directions split unexpectedly. And this one, where I saw conveyor directions multiply fractured on a simple snapshot load.

 

Oh how irritating to be asked to do something you were already going to do...

Certainly that seems to have been the case with this other report, here.

But there were no Undo actions involved when I loaded up @JuanPinoy's base snapshot (here in this thread) and it had fragmented conveyors. Maybe he'd used Undos in the making of it and they secretly saved into the snapshot....?

 

Here's a very precise method to replicate split conveyors and hard crash the game:

(0) Save attached.
(1) Break of a section of conveyor.
(2) Place a new piece of conveyor in the spot of one of those broken off.
(3) Undo the break.
(4) Replaced block is glitched, breaking the continuity.
(5) Reversing it's direction to trigger a full log up without crash dump. (The conveyor sections either side may need to be flowing a certain way, too.)



I fiddled with this again in conjunction with this new report of it happening in 1.0, causing a crash on world load, possibly because a resource chunk is traversing the glitch at the time of saving...