While working on #442's fix; I discovered that when it tried to request the 71 solar panels it thought it could make, it broke down until it discovered that it couldn't pull enough cobblestone (although it should have used the provided furnaces); and therefore decided it couldn't craft any solar panels. Somehow, requests need to figure out how many they can craft, and make as many as possible.

I haven't opened an issue about it but after reading the previous related one I think these might be related.

I found a very similar situation in which the server would get stuck after making a crafting request under the following conditions.

-There ARE enough materials to perform the crafting and the network sees them.

-The materials are pulled in the quantities necessary BUT.

-On arrival, the inventory the crafting pipe is attached to...

• DOES have free space(so the materials get pulled).
• DOES NOT have ENOUGH free space.

At which point the CPU spikes , the server freezes and ,eventually, the client times out.

You can replicate it by requesting a crafting operation that tries to insert more than 64 items in an inventory with only one slot of free space(Barrels,DSUs and similar not included).

I suspect your 71 solar panels sent more materials than the receiving inv could accept, thus triggering the bug.

71 being the very familiar number that I used too, due to how easy is to do increments of ten with the GUI 😄

Yes, they are related. I have a build from my branch that works perfectly except that crafting does not work; due to this bug.

There is a fix that involves a huge rewrite of how pulling works.

Essentially, isDone returns true as long as there is at least some promised objects. Then those promised objects must be floored to the set size, and that is how many it provides. This means a request of 71 might only be provided 1 after all checks down the line. I'm working on implementing this, but it requires a lot of changes to method signatures and processing. This is probably best done by @MrTJP.

@kenzierocks You may be interested in to progress in porting to 1.7 tree/1.7-port
I suggest waiting for @MrTJP to finish committing the big changes, A lot of work and rewriting has been happening.

I'd rather stay with 1.6 right now as I'm working on fixes for my FTB server.

In that case @MrTJP most likely will not support you as he stated there will be no back-ports. (Unless MrTJP you would like to maintain 1.6 for a while)

I'm fine with the current state. If I want to I'll back port myself; it shouldn't be too much of a pain (except for the item id change).

Nope. Maintaining 1.6 means working with two very different versions of cb's libraries.

On Jun 6, 2014, at 12:51 PM, simon816 [email protected] wrote:

In that case @MrTJP most likely will not support you as he stated there will be no back-ports. (Unless MjTJP you would like to maintain 1.6 for a while)

—
Reply to this email directly or view it on GitHub.

Fix via 68da9c0

Yay! All I have to do is backport the fix for my server.