Issue type:

• 🐛 Bug

Short description:

I'm playing ATM10, which has a very large number of recipes for the crafting table. When I place an Attuned Crafting Interface on a Crafting Table, the game very quickly becomes laggy; I was never able to see the interface get rendered, and when I opened my storage terminal, none of the items or recipes displayed and the game became unresponsive. I assume this is because of the large number of recipes, because the interface handles machines like Mekanism's Metallurgic Infuser without issue.

Because I've updated the Integrated mods beyond what the pack offers, I thought it'd be more prudent to report the bug here, instead of to the ATM devs. I'll make my report there if it is the right procedure in this case.

Steps to reproduce the problem:

1. Boot up All The Mods 10-4.10 with the specified versions of the Integrated Mods.
2. Place a crafting table next to an Integrated Dynamics network.
3. Connect the crafting table to the network with an Attuned Crafting Interface.
4. (Optional) Open a storage terminal on that network.

Expected behaviour:

The recipes are exposed to the network, viewable in the storage terminal without framerate or tickrate issues, like they are for machines with fewer recipes.

Versions:

• This mod: 1.3.1
• Minecraft: 1.21.1
• Mod loader version: Neoforge 21.1.203

Log file:

Thanks for reporting!

Could you profile your instance, as explain here?

Your server logs could also help, to identify if something silently crashed.

I'm not familiar with using Spark; I used the command to start profiling, got the link with /spark profiler open, and then this is the link that was generated. I wasn't able to close the profiler normally, because once I open the storage terminal, the game freezes and I have to terminate the instance through other means. So if this doesn't include the data you need, I apologize.

Similarly, I don't know if this will contain the logs that you need, but this is the message generated from the ATM10 crash assistant, which I assume will have the relevant server logs.

Some further clarification for the issue; after testing a second time, placing the attuned interface on the crafting table takes some time to render, but it eventually renders, and the game continues to run; I did not profile the TPS, but it seemed stable. The game becoming unresponsive occurs once I try to open my storage terminal on the network with the interface.

If you need anything else, I'm happy to try to provide it.

Scraped from the externally linked latest.log:

commoncapabilities-1.21.1-neoforge-2.10.0
cyclopscore-1.21.1-neoforge-1.27.0
evilcraft-1.21.1-neoforge-1.2.78
integratedcrafting-1.21.1-neoforge-1.3.1-370
integrateddynamics-1.21.1-neoforge-1.28.1
integratedmekanism-1.21.1-neoforge-1.0.2
integratedscripting-1.21.1-neoforge-1.0.19
integratedterminals-1.21.1-neoforge-1.6.16
integratedtunnels-1.21.1-neoforge-1.9.0

Thanks for the additional info @Puxta-lab, this definitely helps!

Could possibly be fixed using CyclopsMC/IntegratedTerminals#169
Additionally, we may have to spread sending crafting options and instances across multiple ticks.

Note to self:

[13Oct2025 17:04:40.624] [ModernFix integrated server watchdog/ERROR] [org.embeddedt.modernfix.world.IntegratedWatchdog/]: A single server tick has taken 41543, more than 40000 milliseconds
[13Oct2025 17:04:43.495] [ModernFix integrated server watchdog/ERROR] [org.embeddedt.modernfix.world.IntegratedWatchdog/]: Thread Dump:
"Render thread" prio=10 Id=1 RUNNABLE
	at java.util.HashMap$EntrySpliterator.tryAdvance:L1875
	at java.util.stream.ReferencePipeline.forEachWithCancel:L129
	at java.util.stream.AbstractPipeline.copyIntoWithCancel:L527
	at java.util.stream.AbstractPipeline.copyInto:L513
	at java.util.stream.AbstractPipeline.wrapAndCopyInto:L499
	at java.util.stream.FindOps$FindOp.evaluateSequential:L150
	at java.util.stream.AbstractPipeline.evaluate:L234
	at java.util.stream.ReferencePipeline.findAny:L652
	at net.minecraft.util.ExtraCodecs$7.isEmptyMap:L622
	at net.minecraft.util.ExtraCodecs$7.decode:L614
	at com.mojang.serialization.Decoder$2.decode:L63
	at com.mojang.serialization.Codec$2.decode:L75
	at com.mojang.serialization.Decoder.parse:L18
	at org.cyclops.commoncapabilities.ingredient.IngredientSerializerItemStack.deserializeInstance:L34
	at org.cyclops.commoncapabilities.ingredient.IngredientSerializerItemStack.deserializeInstance:L16
	at org.cyclops.commoncapabilities.api.capability.recipehandler.PrototypedIngredientAlternativesList$Serializer.deserialize:L98
	at org.cyclops.commoncapabilities.api.capability.recipehandler.PrototypedIngredientAlternativesList$Serializer.deserialize:L61
	at org.cyclops.commoncapabilities.api.capability.recipehandler.IRecipeDefinition.deserialize:L142
	at org.cyclops.integratedterminals.modcompat.integratedcrafting.TerminalStorageTabIngredientCraftingHandlerCraftingNetwork.deserializeCraftingOption:L102
	at org.cyclops.integratedterminals.modcompat.integratedcrafting.TerminalStorageTabIngredientCraftingHandlerCraftingNetwork.deserializeCraftingOption:L56
	at org.cyclops.integratedterminals.core.terminalstorage.crafting.HandlerWrappedTerminalCraftingOption.deserialize:L49
	at org.cyclops.integratedterminals.network.packet.TerminalStorageIngredientCraftingOptionsPacket.actionClient:L92
	at org.cyclops.cyclopscore.network.PacketHandler.handlePacketClient:L84
	at org.cyclops.cyclopscore.network.PacketHandler.lambda$registerActual$0:L70
	at org.cyclops.cyclopscore.network.PacketHandler$$Lambda/0x000000080aefd730.run:unknown
	at net.neoforged.neoforge.network.handling.ClientPayloadContext.enqueueWork:L31
	at org.cyclops.cyclopscore.network.PacketHandler.lambda$registerActual$2:L70
	at org.cyclops.cyclopscore.network.PacketHandler$$Lambda/0x00000008096f0ec0.handle:unknown

I applied some small tweaks in CommonCapabilities, Integrated Terminals, and Integrated Crafting.
Things perform a lot better now based on my testing in ATM.

Just popping in to confirm that performance is a lot better after updating. It's not 'flawless'; the game doesn't freeze when opening the terminal, but it still does take a few seconds for the terminal to become responsive upon opening. Once open though, you can navigate through it seamlessly.

Performance also in general feels a lot better on a larger Integrated network (though I haven't done any extensive testing)

but it still does take a few seconds for the terminal to become responsive upon opening

Could you share a new profile output?
In my own testing, it felt pretty instant.

In any case, #158 will help in the future.

This is my new profile; it involves me placing the interface on a crafting table, then connecting it to my main network, and then opening my portable storage terminal about 6 times. Then I open a storage terminal placed directly on the network configured to only show storage contents, and then another configured to only show crafting recipes. Then I go and break the interface and stop the profiling.

Thinking it might have been due to a difference in testing environments, I decided to test it on a clean network, which only contains a storage terminal and the interface on a table. These are the results; this simply involves me opening and closing the terminal on this otherwise empty network.

It's entirely possible it's a hardware/memory concern on my end. On the second test, I got an alert about 90%+ memory usage; if you're testing with 12 or 16GB available, it might be able to handle the operation smoothly and quickly compared to my 8GB.

Thanks for the new profiles, but it looks like those are server profiles, while the lag is occurring on your client.
Could you try recording a client profile instead?
(I've never done that myself though. I suspect it can be done using /sparkc or something similar)

I got an alert about 90%+ memory usage

This is an important clue. It may very well be an issue related to high memory consumption, which leads to garbage collection delays.

I tried running the same tests, leading the profiler with /sparkclient instead of simply /spark. Again, this is simply me setting up the interface on a network and then simply opening and closing the terminal. I didn't exactly count how many tests I did on each network but I started testing on the main network and then on an empty one. Here is the profile that was generated.

Aha, that profile clarifies a lot, thanks @Puxta-lab. (crafting option deserialization was running on the render thread instead of the network thread, thereby causing FPS issues)

I just pushed new beta versions of Integrated Terminals and CyclopsCore to CurseForge (they may take a bit to land there).
Could you try those (both Integrated Terminals and CyclopsCore) to see if they fix the problems for you?
And if not, could you share a new client profile?

This certainly is better on the client side, with the client not freezing, and performance in the terminal being fairly smooth. The recipes don't all load in at once, but that's to be expected.

The new problem is that this now kills the tickrate of the server. These profiles start with the interface already on the network, and I take a moment to get comfortable and then open the terminal twice. After running around my machines a bit to confirm there are tickrate problems, I then take the attuned interface off of the network and run around my base a bit observing how that changes performance, and then I stop the profile.

Here are the server and client profiles.

It has brought to my attention that, I think, my server is having tickrate problems for other reasons, related to the fact that I have about 20 crafting writers that are all performing an operation to check if their ingredients are currently being crafted, in a bid to avoid an IntegratedCrafting bug related to race conditions (a recipe will indefinitely stall if its output is taken out of the system on the same tick it's added to it) and I probably didn't choose a good way to compare them (list intersection).

So you may notice that, in those profiles, the tickrate doesn't return to 20 after the interface is disconnected. I don't think that is related to this issue or update. I notice the same tickrate issues hanging around 17-18 when I downgrade back to the version I was on, and on both versions I notice a return to 20 ticks if I disconnect my variable stores and crafting writers from the network.

Could you check and compare a new profile with those writers (still) disconnected, making the assumption that is indeed unrelated?

Here's new server and client profiles, on the most recent beta versions of CyclopsCore and IntegratedTerminals. I start the profile with everything connected, and I spend the time making sure the parts I cut will only cut the crafting writers and the variable stores. I then cut them, and observe a tickrate spike back up to 20, occasionally dropping to ~19.8. I let the server sit for about a minute while I idle, and then I stop the profiling.

It's still not perfect; there's something causing ticks occasionally that are ~120ms long, according to spark health. I don't know where that's coming from so I can't even confirm if it's related to the Integrated mod suite at all. But its down from occasional ~500ms long ticks when the stores and crafters are connected. These longer ticks were also observed on the previous versions when I tested them before with about the same length for both. If you want a set of profiles from the previous release versions, I can provide those as well.

Thanks for checking @Puxta-lab.

The good news is that all the profiles you sent do not indicate any significant performance impact of the attuned crafting interfaces anymore. So in that respect, this issue is resolved.

For the first profile, the crafting writers are having a big performance impact.
I'm not sure what these are doing exactly, but if you think it's worth it to look into, it might be best if you could create a dedicated issue for this, with some more details of your setup (+ a link to this (server) profile).
If I understand correctly, this is to work around #112, for which a solution is planned. So I suspect your workaround will not be necessary anymore once I implement #112.

For the second profile you sent, this seems to be the same problem as CyclopsMC/IntegratedDynamics#1460, which is followed up in P3pp3rF1y/SophisticatedStorage#584.

Thank you for all the work you've done on this issue, and trying to diagnosing other performance issues in the process. It's far more than I would have expected considering it's a big ask to consider integration with other mods as well as maintaining your own. I also appreciate how quickly you're putting the work in.

I've made a separate report at #160 as you suggested.