Autocrafting AE2 closing itself when clicking on recipes

[Sphyix]

Which modpack version are you using?

2.1.0.0

#

If in multiplayer; On which server does this happen?

delta

#

What did you try to do, and what did you expect to happen?

I tried clicking on a recipe for autocrafting on an ME Crafting Terminal. I expected this window to open

#

What happened instead? (Attach screenshots if needed)

Instead this is happening https://user-images.githubusercontent.com/17811922/105609477-e3584080-5da9-11eb-9ab3-242072c56d6b.mp4

It's happening intermittenlty between 2 terminals, sometimes 1 is working, sometimes both are not working. I tried starting to autocraft on another player ae system and it worked. I tried with 2 different clients, one old and one freshly installed and they both do the same thing

Ae2 system is set up in a void world (quests portal) idk if that's relevant

[GTNH-Afx237v7]

See also #3807, #2432 and/or #1001

[Sphyix]

Found the slot causing the issue for me. I guess by reading the other issues, it can't be reproduced so can't be fixed.

[repo-alt]

It looks like some smart mod mishandles GuiOpenEvent in a weird way, but what mod is that I have no idea.

[GTNH-Afx237v7]

I first encountered this in 2.0.7.5, took me a while to find out that a random inventory slot caused this. If I remember correctly, upon updating to 2.0.8.3 the inventory slot changed causing this changed, and at some point this problem was simply gone...

[npo6ka]

I also faced this problem. I am playing on private server version 2.1.0.0. In the garden world, the crafting terminal is closed when clicking to crafting status. I ran a series of tests and found out: 1) Me network may not be powered and have only terminals, even without a wire. The bug is reproduced. 2) The problem is directly related to the coordinates of the installation in the world. So if the terminal is set to coordinate X: 0, then the interface is closed if the player's zero slot is busy with something (the same slot that is selected by pressing the "1" key). If the terminal is set to coordinate x: 8 and the eighth slot of the investor is busy, this problem also occurs. 3) If the inventory is completely empty, this bug will not be reproduced. 4) The problem does not depend on the coordinates y and z.

[repo-alt]

So, something is interpreting X coordinate as a slot index. Nice.

[repo-alt]

@npo6ka Что имелоcь в виду в пункте 1?

[npo6ka]

@repo-alt Можно просто ставить crafting terminal на любой блок и не запитывать его энергией. При нажатии crafting status он всё так же закрывается.

[npo6ka]

Можно в дискорде. Как найти вас?

[repo-alt]

я кажется понял что имеется в виду, но в новом garden dim не воспроизводится https://discord.gg/EXshrPV user: repolainen

[htol]

I also faced this issue since 2.0.7.5. Fixed it by updating wireless crafting terminal to this version: WirelessCraftingTerminal-1.7.10-rv3-1.8.7.9b.jar. I don't know why but it works for me. p.s. should be updated on server & client.

[repo-alt]

*rv3-1.8.7.9b.jar ? Built by who from what sources?

[htol]

i believe it was here

[Ethryan]

This commit maybe?

[repo-alt]

No, it is actually wrong and reverted later, in https://github.com/p455w0rd/WirelessCraftingTerminal/commit/98be7da515a344d5041beaf644f0eb0d48665531 The only meaningful change in this branch is IC2 energy compat, which is kinda hard to believe to have anything to do with this problem

[htol]

For me this relation looks also weird. But check this one

[repo-alt]

I wouldn't be surprised if this is WCT (another obvious candidate is EC2), but I looked over their event handlers and didn't find anything.

[repo-alt]

Actually, if someone can reproduce that on private server or single player, it would be nice to enable AE2 debug logging, it may catch something; Debug log is enabled in config\AppliedEnergistics2\AppliedEnergistics2.cfg, "misc" section

[GTNH-Afx237v7]

I would like to try however I don’t understand this:

Me network may not be powered and have only terminals, even without a wire. The bug is reproduced.

?

[repo-alt]

Lost in translation. Means: take a terminal and slap it face down on any block. It still should have a GUI

[npo6ka]

Just set ME crafting terminal on ground in 0 0 coordinate, open this, and click "Crafting Status". The first slot in the inventory must be busy with something. https://media.discordapp.net/attachments/803201229987119135/803293907386368050/unknown.png?width=973&height=446

[Skiftcha]

i think i found this strange place https://github.com/GTNewHorizons/Applied-Energistics-2-Unofficial/blob/rv3-1.7.10/src/main/java/appeng/core/sync/GuiBridge.java#L227

[repo-alt]

wow, ffs

[GTNH-Afx237v7]

What the?

[repo-alt]

This is apparently a "fix" for https://github.com/AppliedEnergistics/Applied-Energistics-2/issues/889 @Skiftcha how did you even find it?

[Skiftcha]

how did you even find it?

just debugging. i found out gui is closed by S2EPacketCloseWindow packet is sent because ForgeHooks.canInteractWith(this, this.openContainer) is false PlayerOpenContainerEvent had no listeners so canInteractWith is just false canInteractWith in AEBaseContainer is false because isContainerValid == false which is set in ContainerCraftingCPU because getNetwork() is null so i set breakpoint here and got to point where strange thing happen

[Skiftcha]

actually i don't get why terminal without any connections has any network when placed (and when x is negative)

[repo-alt]

Ah, you reproduced that in debug. I didn't get to it today yet. Earlier I could not reproduce that.

[repo-alt]

terminal probably just makes an adhoc network in itself

[repo-alt]

Ok, so will you dismantle that gross hack or should I look into it?

[Skiftcha]

this "fix" is fixing dupe, so maybe we need to go deeper and not just revert but make some different fix

[repo-alt]

yes, of course, but passing slot index in the X coordinate is just asking for trouble

[repo-alt]

apparently yueh was depending on 3-rd bit being properly set by default when opening usual GUIs

[repo-alt]

It was introduced to pass slot index so that one portable cell could not overwrite another if client in not in sync with the server The index ensures that server GUI element actually corresponds to the cell opened (as far as I understand)

[repo-alt]

Normally we should not get into if( ID.type.isItem() ) unless we are opening item GUI. I guess I'll have t launch a debugger after all.

[repo-alt]

Well, currently all I can suggest is fixing this hack with another hack: use the upper bit of the ordinal to signal that X is a slot index

[repo-alt]

ok, I don't see any reaction, so I'm assuming you are not working on it @Skiftcha