Issue type:

• ➕ Feature request

Performance related

Short description:

If you make a recipe of, for example, foo + bar === foobar, when you ask for 64 foobars, it should not try to do one by one (I find this happens with the integrated terminal crafter too, if your result is >1 items, you can see growing the stack one by one, instead of (what seems to be) the usual method of minecraft to do it all at once.

Thanks for the suggestion!

A very useful way of being able to configure this, would be for example an extra toggle button when creating a recipe, that allows to turn on "bulk mode" or not (default off) for that particular recipe.

While this is not difficult to support (we in fact already have code available for that), it's not something I want to add by default for balancing reasons.
Crafting 64 of an items should IMO take 64 times longer than crafting a single item.
But if someone else would like to implement this as a configurable feature, I'm happy to accept PRs.

While this is not difficult to support (we in fact already have code available for that), it's not something I want to add by default for balancing reasons. Crafting 64 of an items should IMO take 64 times longer than crafting a single item. But if someone else would like to implement this as a configurable feature, I'm happy to accept PRs.

While balancing remains an important part of any mod, I'd argue that performance is more important than balacing. So maybe add a timer so that for the client it looks as if its taking longer, but then run the optimized code in the background only once? That way it can be on by default. Honestly, with pipes that can move stuff so fast as integrated dynamics, and they move EVERYTHING but some esoterical fluids like mekanism chemicals, it is already a very fast mod which can be very resource intensive, every bit helps

I'd argue that performance is more important than balacing

I agree with that. But are you actually experiencing performance issues due to this? Because that would be a completely different issue that needs to be looked into.

OOh yeah, sorry didn't specify, but to be fair I'm running a fairly large network and sending big craft orders, TPS drops quite a bit at about 3 different instant item queues (crafting table for example)

While in small orders this may be almost imperceptible, sending 2k of 3 different items to craft, gives you some time to experience the drop.

It does also affect the responsiveness of the integrated dynamics network in general, some notable lag mainly in the terminal, but also sometimes in other crafting queues that are not instantaneous (for example, a mekanism furnace which is configured to auto output to the same crafting input, the output of the recipe stays in the machine stuck)

Just to be sure this wasn't an issue with the the other parts of integrated dynamics, I tried running an experiment with the crafting happening in another chunk, force loaded. As soon as the chunk is not loaded anymore (and so the crafting completely stops) the tps returns to normal.

My specs are quite beefy too, and im assigning 12 gigs to java for running this instance. In comparison to another known mod, AE2, and as another experiment, I set-up kind of the same network (because I was doubting sophisticated storage for this behavior, due to past bad interactions both with Dynamics and AE2, both having issues when inputting a large amount of items into a storage controller from that mod or large interactions in general) but the result, with the same load, was far gentler on TPS.

I will test the system with just minecraft base chests though, just in case, Ill do so after work

I will test the system with just minecraft base chests though, just in case, Ill do so after work

Once you have some findings, feel free to open a performance issue, so we can get to the root cause of this.

No need for a large network to see significant lag. In Mystic Agriculture the core crafting recipe runs in powers of 4, so for 1 Supremium you need

• 256 Inferium
• 64 Prudentium
• 16 Tertium
• 4 Imperium

The minimal amount of usable Supremium is 4 (to make a new seed). With other recurring amounts being 6 (for Master Infusion Crystal) and 8 (for equips).
So lets take for example to make a Supremium Pickaxe:

• 8 Supremium
  • 32 Imperium
  • 128 Tertium
  • 512 Prudentium
  • 2064 Inferium
• 8 Imperium
  • 32 Tertium
  • 128 Prudentium
  • 512 Inferium
• 8 Tertium
  • 32 Prudentium
  • 128 Inferium
• 8 Prudentium
  • 32 Inferium
• 8 Inferium

Inferium is a base material, but all the rest must be crafted (skipping other crafts required for the pickaxe for brevity). Meaning 896 crafting jobs. Launching this task will choke the game for the entire duration. Blocks un-breaking, npc and mob stutter-walking, rubber-banding. I tried to add many crafting tables to ease the burden, but while the crafting time was shorter, the effects were still just as severe.

I understand the balancing problem, my intuition is that the slowdown comes from searching the network for the ingredients from scratch each craft. A quick solution could be to require a crafting storage. Similar to how storage is already required for any other operation. This is similar to how ME2 do it, sequestering all the required materials up-front.

That would also solve a different issue, where crafts might snatch the outputs of a different craft that is running concurrently and produces items that happen to be their materials

EDIT: This is with an M1 Max, 32gb ram assigned. Also with a 7th gen intel server processor with 32gb ram assigned.
Happening both locally and on a server. Running ATM10

@datner your suggestion is already described here: #112 (comment). Although a dedicated storage block for this is undesirable, but that's just implementation detail. Using some form of storage for crafting is essentially the same idea as that one.

I'm not sure how much closer we are to crafting storage by now, nor whether that will fully resolve the OP's issue here.

@Jack-McKalling I did not mean a new dedicated block, I mean like how I add new storage regularly with the item interface? Then I can mark and item interface as 'crafting storage' or have a new interface for that purpose.
But yeah, it matters-not how it's implemented.
I believe it'll solve the issue if my hunch that this is due to the constant re-calc and search through the network thats causing the slowdown is correct. (Which in all fairness is nothing more than a hunch)