Using version 8.2.0-beta.3 on Explorico 1.16.5 mod pack, experiencing extreme lag whenever i am entering the pattern terminal. about 10% of the time it's severe enough that i have to restart the game.

Can comfirm for 8.2.0 release version

Hi,

the Template for new issues is there for a reason! (we still need to know the AE2 version! Forge version! and if it was Singleplayer or Multiplayer!)

In addition a video demonstrating the issue might be helpful.

Also: What kind of lag? FPS lag, Network lag, ...?

Greetings

8.2.0-beta.3 is the AE2 version, forge-36.0.21

It's hard to pin down the lag since the info i need to see is covered up by JEI, but it appears to be both. my RX jumps from 750-800 up to 1200-1400 and my FPS drops down to 1.

I've tried several different configurations for the pattern terminal
-attached to my main computer accessing my drives
-attached to my main computer via quartz fiber (thinking it was slowed down by the amount of items in my drives)
-not attached to my main computer at all just powered by a energy acceptor
they all cause the same lag.

it's multiplayer

Pictures of the setup would help. Any kind of special storages attached or drives only? Enough energy cells present? (Input is limited by capacity/tick)

no special storages. i may be limited on energy cells but it's not item input lag, it's game lag. I tried just making a pattern terminal computer that consisted of a pattern terminal attached to an energy acceptor and nothing else and it still caused my game to lag.

network rebuild due to powerloss can pack quite a punch on tickload in large network, but from what you describe it isnt big. Thanks for clarifying

You mean just leave a sample pattern in the field? I do, it always has the last thing I craftet in it. Last time it was 1 iron ore to 4 iron ingots

Greetings,

the problem still exists in version 8.3.1. I also play in the modpack TNP Limitless 3 (version 1.10.3).The ME system is still pretty basic at the moment, but connected is 1 ME bus to a Quantum Storage Controller, a Diskdrive, a Crafting Terminal and just the Pettern Terminal.

After joining the server you can access the terminal without any problems, but the longer you are on the server the stronger the lags become, up to the point when you open the terminal after about 10 minutes, the game simply freezes, but the sound keeps playing, so to speak, it hangs in a not displayed GUI.

Edit:// Has anyone had experience with another modpack? Maybe the bug only occurs in the TNP modpack.

Getting this issue in ATM6, even with the terminal disconnected and it performed exactly as described by earlier replies. No fps lag with any recipe entered, but 4fps with no recipe. This happened on a server, and wasn't happening before today. I can't pin down exactly what made it happen. Since it's on a server, I asked two other people to try opening the terminal and they didn't get any lag at all. I got it with Java 8, then I switched to OpenJDK 11 and it was still prevalent.

Faced same issue on both 8.3.0-alpha1 and 8.3.0-alpha2 on TNP Limitless 3 modpack
UPD: Made few tests with different amount of placed ME storage cells, but crash is gone. But still here's huge FPS drop when pattern terminal is opened. FPS in wild: ~110, FPS when Terminal/Crafting Terminal is opened: ~70, FPS when Pattern Terminal is opened: at the begining there's a drop to 4 FPS, and then goes up to 20 FPS

Made few more tests and explored that when player inventory is empty lag almost unnoticeable. But once i'm fill full inventory and opened terminal client freezed for around 2 seconds. Also after 10+ minutes of playing Pattern Terminal openning may even freeze game for forever

Sorry for lots of comments, but i guess i finally figured out what happens here.

Looked up through code, used some profilers (VisualVM), and got an idea. I've placed basic recipe (wood to planks) and freezes is gone!

Seems like when we open Pattern Terminal and there's no active recipe it's trying to figure out which recipe currently setted up

In big modpacks there's lots of recipes and since crafting inventory is empty, it goes through every recipe in game just to check that emptiness isn't match any of recipe.

I'm not sure how it can be fixed, but my suggestion, as a hot-fix, to not looking up for matching recipe if crafting inventory is empty. It won't help when user put some item that doesn't match for any recipe, but at least it will prevent lags when inventory is empty, which is most common case (at least for me).

P.S. I'm not into minecraft modding, and there's a possibility that i missing something important

Yeah, that might be it. Thanks for looking at this in depth. On the crafting terminal we only do this check when the crafting grid changes. We're currently doing a larger pass over GUIs and will potentially look at doing sth similar here as well.

@yueh yeah, i also thought about single call, but not calling every frame, but after getting bunch of new information during my explorations i completely forget about it :(

I search throught different modpacks discord/github and found that ATM modpack reports that cause of similar behaviour was Performant mod. Will play without it and if crashes will gone - i'm going to post update here.

Thanks guys

@ProOrange If that is the problem, I would recommend reporting the problem to Forge. Fixing it at this level will benefit every mod out there with a similar problem. Further if an empty crafting inventory is a valid candidate for a recipe as minecraft/forge does search for it and not fast fail, then it is certainly not up to use to decide that a valid recipe is no longer a valid recipe by ignoring this case completely.

Another option could also be that some mod like crafttweaker or similar uses their own handler for crafting recipes for some cases and simply forgot to fast fail in this case. At least in the past CT did sometimes pop up in profiling with their custom handler. No idea if it is still possible and certainly not possible to make any definite statement about it without seeing a sampling snapshotbor similar.

Further we call this code only on an actual inventory change. Like once when the terminal is opened, but not continuously afterwards. So if this happens every frame, this sounds really more like some stupid mod decides to mixin into our code and break it. If so, that is something which further should be reported to the specific modpack for them to identify.

I see you're found opportunities to improve performance, but regarding original bug:

Looks like Performant was the root of crashes, they're gone after i disabled it

@yueh I did a cursory investigation, I think we're calling it as part of "getOutput", and as long as no output is cached, we might be calling it every frame. This might just end up being a problem of not properly caching the state "the recipe is not valid" and trying to recompute the cached output every frame.
Should actually be easy to fix if we already invalidate the cache when the crafting grid changes.

There is only getOutputs(), which is called when clicking the encode button. So as long as nothing is hammering a click on it every frame for whatever broken reason, it will not happen.

getAndUpdateOutput() is really only called on things like a slot is changed, some button presses like encode or clear, or similar. Never on a loop (outside some actively forced ones by constantly clicking buttons or someone else toggling the crafting mode serverside)

I'll take a closer look later, should be easy to trace. If there's something else messing with the slots there's nothing we can do

I also hooked up a breakpoint to getAndUpdateOutput() and it gets called 10 times when opening a terminal as each slot is initialised iteratively.

I guess we could eliminate one call for setting the slot for blank patterns itself and if really needed override net.minecraft.inventory.container.Container.setAll(List<ItemStack>), so we can only do it once all 9 slots are done.
But that is a fixed cost for opening the terminal. Otherwise it just waits for something to happen. So whatever really.

Performant does a bunch of broken things, so I'd guess it could cause it on top of other things like potential data loss.

And just in case it comes up. Yes the crafting terminal behaves in a similar way. It will only update the cached recipe on an inventory change or performing a craft operation for some cases like someone places the correct amount of items to craft boots, a helm and legs in one go.

This won't increase the performance. maybe open the terminal 2 msec faster. Have fun trying to prove that with an A/B test.

May be for small modpacks, but for me (300+ mods) both terminals opens for ~1-2 secs. I believe this can decrease open time to <1sec.

Still exists on 8.3.0-alpha3

Didn't this turn out to be a problem with performant?

PAttern terminal crashing my client in atm6 1.6.1 with ae2 8.3.0 beta1

I just tried this in the latest ATM6 with appliedenergistics2-8.3.0-beta.2.jar

At least in creative mode, superflat world, I don't notice any performance issues with the pattern terminal.

Closing this, unless someone can tell me how to reproduce it.

Why not testing with the reported versions?