Skip to content

Better support for opening EMI screens from non-handled screens#946

Open
Abbie5 wants to merge 2 commits intoemilyploszaj:1.21from
Abbie5:non-handled-screens
Open

Better support for opening EMI screens from non-handled screens#946
Abbie5 wants to merge 2 commits intoemilyploszaj:1.21from
Abbie5:non-handled-screens

Conversation

@Abbie5
Copy link
Contributor

@Abbie5 Abbie5 commented May 12, 2025

This fixes the behaviour where, upon closing the recipe screen that was opened from the FTB Quests screen, the client is returned to the inventory screen instead of the original quest screen.

Copy link
Owner

@emilyploszaj emilyploszaj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This likely works to fix this issue, but does it cause other issues? for instance, if you open from another GUI, it'll show no recipes as craftable, even if they may be craftable via the currently open screen handler? maybe getHandledScreen should default to that so we can support both use cases.

This fixes the behaviour where, upon closing the recipe screen that was opened from the FTB Quests screen, the client is returned to the inventory screen instead of the original quest screen.
@Abbie5 Abbie5 force-pushed the non-handled-screens branch from a157a64 to 12e249c Compare February 19, 2026 17:13
@Abbie5
Copy link
Contributor Author

Abbie5 commented Feb 19, 2026

Hi, coming back to this PR after a while so I'm a bit rusty.

This likely works to fix this issue, but does it cause other issues? for instance, if you open from another GUI, it'll show no recipes as craftable, even if they may be craftable via the currently open screen handler? maybe getHandledScreen should default to that so we can support both use cases.

Is there a way to test this behaviour so I can make sure my implementation is correct? And, I don't see a way to get a HandledScreen from the currently open screen handler exposed in PlayerEntity#currentScreenHandler, so please clarify what you're referring to by "that".

return rs.old;
} else if (s instanceof BoMScreen bs) {
return bs.old;
} else if (s instanceof RecipeScreen rs && rs.old instanceof HandledScreen<?> hs) {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's what I mean in my previous comment, both RecipeScreen and BoMScreen can now have an old screen that is not a HandledScreen, such as a quest UI, and then no recipes would show up as craftable. Maybe this behavior should default to the player's inventory when nothing else is valid, since that is always accessible. WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

like this?

Index: xplat/src/main/java/dev/emi/emi/api/EmiApi.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/xplat/src/main/java/dev/emi/emi/api/EmiApi.java b/xplat/src/main/java/dev/emi/emi/api/EmiApi.java
--- a/xplat/src/main/java/dev/emi/emi/api/EmiApi.java	(revision 12e249c067862fd4233bfb86ca8c92865f52fc8e)
+++ b/xplat/src/main/java/dev/emi/emi/api/EmiApi.java	(date 1771852166073)
@@ -111,6 +111,8 @@
 			return hs;
 		} else if (s instanceof BoMScreen bs && bs.old instanceof HandledScreen<?> hs) {
 			return hs;
+		} else if (client.player != null) {
+			return new InventoryScreen(client.player);
 		}
 		return null;
 	}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants