Describe the bug

Assuming we have two patterns in the network encoded with A->B and B->C, seperately. When C is requested and AE is calculating the bytes needed for crafting, it will always recursively calculate bytes used by A->B, even if B exists in the current AE network.

This is not a serious issue with pure minecraft, but with modpacks (like Omnifactory which I'm currently playing) that introduced super deep and complicate production line, this can cause rediculously large amount of total crafting bytes usage and huge performance decrease - For a simplest crafting which I have all materials prepared, I have to spend millions of bytes and wait for minutes (meanwhile tps is exactly zero and nothing can be done), only because it's at the end of my encoded pattern chain.

I'm not sure whether it's a bug or a feature, but this do cause unnecessary and rapid performance drop. Besides, logically the players shouldn't have spent tons of bytes on crafting processes they've never called. After all, nothing has been moved to CPU, so what are the extra bytes taken for?

To Reproduce

1. Set up an AE network with autocrafting equipments.
2. Encode two processing pattern: cobblestone->gravel, gravel->sand (can be subsituted by any items).
3. Add a gravel to the network.
4. Request for a sand.
5. Crafting plan says 43 bytes used.
6. Remove the first pattern: cobblestone -> gravel, then request for a sand.
7. Crafting plan says 27 bytes used.

Expected behavior

The crafting plan should use 27 bytes in both cases.

Environment

The experiment is carried out in pure minecraft 1.12.2 with latest AE2 I can find.

• Minecraft Version: 1.12.2
• AE2 Version: rv6-stable-7
• Forge Version:14.23.5.2847

FYI this should be fixed in 1.17 when #5596 is implemented. :)

Will be in the next 1.17 alpha, sorry for taking so long to get this done... ;)

Each crafting step requires 8 bytes to potentially store them. You could probably argue that unnecessary steps shouldn't add to the sum, but the amounts are pretty much negligible. Even with 100 steps it still fits perfectly fine into a 1k crafting storage and most likely still way less than the amount needed to store every itemstack.

As long as it does not require the majority of a 64k storage, which would mean way over 4000 crafting steps for a single request, I would not really see it as a issue. There are probably even some cases, were it might calculate less than actually needed. E.g. overflow.

Each crafting step requires 8 bytes to potentially store them. You could probably argue that unnecessary steps shouldn't add to the sum, but the amounts are pretty much negligible. Even with 100 steps it still fits perfectly fine into a 1k crafting storage and most likely still way less than the amount needed to store every itemstack.

As long as it does not require the majority of a 64k storage, which would mean way over 4000 crafting steps for a single request, I would not really see it as a issue. There are probably even some cases, were it might calculate less than actually needed. E.g. overflow.

@yueh No. It's not a linear increasement, it's an exponential explosion. Here's a screenshot of what I'm currently going through. It already takes a long time to iterate over the whole tree. Meanwhile everyone on the server is totally frozen and have to wait for this heavy calculation. Besides, I'm only on the half way of the modpack-designed workflow, so things could be worse. In my case it's everything but "negligible".

I used to believe AE2 is the only minecraft mod that could handle large scale automation of this complextiy, but this mistake is somehow disappointing. I'm not familiar with your tree generation implementation, but techinically speaking, the current implementation does introduce unnecessary crafting-tree exploration, which may also influenced the performance of crafting card. I really hope you guys could reconsider fixing this issue.

This behaviour was chosen by your modpack. There is simply no way we can fix something, which was broken by a 3rd party on purpose.

That's not really fair to assume that just because there are items that have longer crafting queue of items before it it can go mental like that.

I guess that this is hard-coded but it would be nice if this was a config thing going forward if it's possible.

Also if the system wouldn't have to count all the steps before it (whitch it does not do) the crafting calculation could be much faster I would assume.

Also it would be nice to hear how exactly this might have been broken that way, because obviously these 600k cannot come from 8 bytes per step.

This is not about some deeper crafting trees added by some modpack, but the mods they choose to break it. E.g. PackagedAuto is a massive issue in terms of bugs and performance. Would not rule out other options, but it is simply too much work to track every modpack and their issues.

This is not about some deeper crafting trees added by some modpack, but the mods they choose to break it. E.g. PackagedAuto is a massive issue in terms of bugs and performance. Would not rule out other options, but it is simply too much work to track every modpack and their issues.

@yueh What I'm arguing for is the unnecessary expansion of the crafting tree. The current AE crafting plan byte calculation implementation will expand every treenodes to the leaves, even if the production already exists and this sub-tree could have been cut off. This is definately an AE2 issue.

Modpack itself and packageauto has nothing to do with this issue, I can reproduce this with pure minecraft if you like.

pattern 1: diamond -> diamond block
pattern 2. white wool, orange wool, megenta wool ... light gray wool (9 different colors of wool) -> diamond

pattern 3. white carpet, orange carpet, ..., light gray carpet -> white wool
pattern 4. white carpet, orange carpet, ..., light gray carpet -> orange wool
pattern 5 to 11: have the same input of carpets, only different color of output wools.

pattern 12 to 20: repeat 3 to 11 with different colors of banners input and different colors of carpets output

pattern 21 to 29: repeat 12 to 20 with different colors of AE2 glass cables input and different colors of banners output

(By the way, metadata is not related to this issue according to my tests, it's only for convenience)

Now, put one diamond in the network and try to craft a diamond block, and 64K CPU is used up! If you stop the crafting plan generation process when you find there's already a diamond in the network, the whole crafting tree expansion could have been avoided.

That's what I mean by "exponential explosion": only about 30 patterns have already used up a 64K CPU. This is a somehow extreme example but that's roughly what I'm experiencing with my modpack. The modpack introduced multiple stages and you have to use a large amount of resources from the last stage to produce stuffs in the next stage. So the exponential explosion appears.

This could have been avoided by some kinds of over-production if you guys have the crafting tree cutting off optimization correctly implemented, as a normal player (like me) expected. I understand it's not a easy work to rewrite the related code. for example you have to carefully avoid recounting. But I really hope you could reconsider fixing this issue.

I am currently experiencing the same issue. I thought i could save some crafting storage by first requesting the intermediate products and then, when those are available I would request the end product. But it just doesn't work: It still uses almost the same amount of storage, even with only a single recipe that needs to be done.

EDIT: I am using the workaround of removing the patterns used for the intermediate parts (that are anyways available) to reduce the crafting storage required to an acceptable level.