Carter Johnson
- CarterJohnson374
- carterjohnson374
- Europe/Stockholm
- Yes
- No
MC-199090
MCL-17027
Normal
Note: While this issue does regard modified versions of the game, it is a bug with the vanilla launcher and not the modified profiles themselves, as it is present no matter which non-vanilla profile is used, from my testing (Tested on 3 different non-vanilla profiles, with confirmation of a 4th from another user experiencing the same issue). While usually bug reports for the game itself are disregarded/marked as invalid if mods are involved, this one has to do with the vanilla launcher not loading the correct graphics settings for non-vanilla profiles/installations and should be at least looked into because of this.
After the latest launcher update, Minecraft no longer accepts non-integrated graphics for profiles that aren't exclusively vanilla. This issue started happening the day of the update (Feb 16th) and prevents users from switching from integrated graphics to non-integrated graphics. Others I have talked to have also had this issue and are having the same problems.
This issue breaks profiles that rely on non-integrated graphics. This is not usually the case for the vanilla game, but for profiles such as Vivecraft (VR Minecraft for Java edition), certain types of integrated graphics cannot be used, and with the update locking users to integrated graphics, this prevents such installations and profiles from being used. For users such as myself who are running these profiles on a laptop, not being able to use non-integrated graphics prevents us from running these profiles at all, with no way to revert the launcher and use them again.
Steps to reproduce:
- Open the settings application and navigate to graphics settings (System -> Display -> Graphics Settings)
- Add the javaw.exe (usually located at C:\Program Files (x86)\Minecraft Launcher\runtime\jre-x64\bin) file to the performance list and change the setting from the integrated graphics to the non-integrated graphics (usually labelled as "high performance")
- Start the game on a profile that isn't vanilla (Forge, Fabric, Vivecraft, Optifine, etc)
- Notice how it refuses to use the graphics you specified, instead falling back to the integrated graphics (You can check the graphics on the f3 screen)
What Actually happens: The game uses the default graphics/integrated graphics
What happened prior to the update: The game would use the assigned graphics as expected
What Should happen: The game should use the assigned graphics settings across all profiles, and not just those that are exclusively vanilla.
Possible workaround for NVidia Card Users:
- Open the NVidia control panel > manage 3D settings > program settings
- Find java and force it to high performance
Included screenshots
- A screenshot of the settings screen where the graphics settings are applied
- A screenshot of the vanilla game (1.16.5) that uses the correct graphics
- A screenshot of a non-vanilla launcher profile that does not use the correct graphics (Optifine 1.16.5)
When using an item model that changes based off the holder_type property checking for a player, the result is very inconsistent between various GUIs and screens in the game that render or hold items. Below is a table documenting the different screens/GUIs, whether or not items within them are considered as held by a player, whether or not this seems intended or correct, and any additional notes on the behavior.
Screen/GUI Considered as held
by a player?Likely
to be correct?Additional notes Toasts No Yes Advancements No Yes Statistics No Yes World Creation No Yes Gamemode Switcher Yes No Seems likely to be incorrect based on the other non-block UI screen behaviors. Not a tangible item, cannot be held. Recipe Book Tabs No Yes Intangible item, cannot be held. Creative Menu tabs Yes No Inconsistent with the recipe book tabs and other intangible items. Recipe Book recipes Sometimes Mixed results
- Recipes with a single item displayed in the slot are considered player held.
- Recipe slots with 2 stacked items treat the top as player held and the bottom as not player held. This one is the weirdest case on this list.
- The crafting grids in the expanded recipe previews for items with many recipes are treated as player held. This is consistent with the behavior for the full size grids, but unknown if intended, as these items are intangible.
Crafting Table/Crafter input slots Yes Uncertain1 Crafting Table/Crafter output slots No Uncertain1 These are the only two cases where an output slot is not considered player held. Missing ingredient recipe displays No Yes Not a tangible item, seems likely to be correct. All Anvil slots Yes Uncertain1 All Brewing Stand slots Yes Uncertain1 Beacon payment slot Yes Uncertain1 Beacon payment example items Yes No Not a tangible item, so unable to be held. All Furnace, Blast Furnace, and Smoker slots Yes Uncertain1 All Loom slots Yes Uncertain1 All Smithing Table slots Yes Uncertain1 All Cartography Table slots Yes Uncertain1 All Grindstone slots Yes Uncertain1 Stonecutter Yes Mixed Results The selectable recipes are not tangible items, but the input and output slots should follow note 1. Currently all three are considered player held. Items in Container blocks, such as Chests, Barrels, and Shulker boxes Yes Uncertain2 Items in the equipment/storage slots of Horses, Mules, Donkeys, and Llamas Yes Uncertain2 Items in the Bundle tooltip/preview Yes Uncertain, likely No This one is a weird case because the item inside of the bundle isn't being held, the bundle is. Villager/Wandering Trader trades list No Yes These items are unaffected by checking if the holder type is a Villager/Wandering Trader, but this may be intended depending on how note 1 is treated. Villager/Wandering Trader input/output slots Yes Uncertain1 1 - Entirely depends on if items placed in GUI slots still being considered as player held is intended behavior. If it is, then only crafting output slots are incorrect.
2 - Depends on if storage/container slots are intended to be treated differently from workstation GUI slots, due to the ability to close the gui and store the item permanently in the slot, unlike the ones covered by note 1.
Attached are screenshots of the cases listed in the chart. The item model being an apple means that it is considered player held, and the item model being a potato means that it is not. The resource pack used to test this is also attached - various random items were used to test the different cases, so refer to the files at assets/minecraft/items to see which are changed.
When using an item model that changes based off the holder_type property checking for a player, the result is very inconsistent between various GUIs and screens in the game that render or hold items. Below is a table documenting the different screens/GUIs, whether or not items within them are considered as held by a player, whether or not this seems intended or correct, and any additional notes on the behavior.
Screen/GUI Considered as held
by a player?Likely to be correct? Additional notes Toasts No Yes Advancements No Yes Statistics No Yes World Creation No Yes Gamemode Switcher Yes No Seems likely to be incorrect based on the other non-block UI screen behaviors. Not a tangible item, cannot be held. Recipe Book Tabs No Yes Intangible item, cannot be held. Creative Menu tabs Yes No Inconsistent with the recipe book tabs and other intangible items. Recipe Book recipes Sometimes Mixed results
- Recipes with a single item displayed in the slot are considered player held.
- Recipe slots with 2 stacked items treat the top as player held and the bottom as not player held. This one is the weirdest case on this list.
- The crafting grids in the expanded recipe previews for items with many recipes are treated as player held. This is consistent with the behavior for the full size grids, but unknown if intended, as these items are intangible.
Crafting Table/Crafter input slots Yes Uncertain1 Crafting Table/Crafter output slots No Uncertain1 These are the only two cases where an output slot is not considered player held. Missing ingredient recipe displays No Yes Not a tangible item, seems likely to be correct. All Anvil slots Yes Uncertain1 All Brewing Stand slots Yes Uncertain1 Beacon payment slot Yes Uncertain1 Beacon payment example items Yes No Not a tangible item, so unable to be held. All Furnace, Blast Furnace, and Smoker slots Yes Uncertain1 All Loom slots Yes Uncertain1 All Smithing Table slots Yes Uncertain1 All Cartography Table slots Yes Uncertain1 All Grindstone slots Yes Uncertain1 Stonecutter Yes Mixed Results The selectable recipes are not tangible items, but the input and output slots should follow note 1. Currently all three are considered player held. Items in Container blocks, such as Chests, Barrels, and Shulker boxes Yes Uncertain2 Items in the equipment/storage slots of Horses, Mules, Donkeys, and Llamas Yes Uncertain2 Items in the Bundle tooltip/preview Yes Uncertain, likely No This one is a weird case because the item inside of the bundle isn't being held, the bundle is. Villager/Wandering Trader trades list No Yes These items are unaffected by checking if the holder type is a Villager/Wandering Trader, but this may be intended depending on how note 1 is treated. Villager/Wandering Trader input/output slots Yes Uncertain1 1 - Entirely depends on if items placed in GUI slots still being considered as player held is intended behavior. If it is, then only crafting output slots are incorrect.
2 - Depends on if storage/container slots are intended to be treated differently from workstation GUI slots, due to the ability to close the gui and store the item permanently in the slot, unlike the ones covered by note 1.
Attached are screenshots of the cases listed in the chart. The item model being an apple means that it is considered player held, and the item model being a potato means that it is not. The resource pack used to test this is also attached - various random items were used to test the different cases, so refer to the files at assets/minecraft/items to see which are changed.
When using an item model that changes based off the holder_type property checking for a player, the result is very inconsistent between various GUIs and screens in the game that render or hold items. Below is a table documenting the different screens/GUIs, whether or not items within them are considered as held by a player, whether or not this seems intended or correct, and any additional notes on the behavior.
Screen/GUI Considered as held
by a player?Likely to be correct? Additional notes Toasts No Yes Advancements No Yes Statistics No Yes World Creation No Yes Gamemode Switcher Yes No Seems likely to be incorrect based on the other non-block UI screen behaviors. Not a tangible item, cannot be held. Recipe Book Tabs No Yes Intangible item, cannot be held. Creative Menu tabs Yes No Inconsistent with the recipe book tabs and other intangible items. Recipe Book recipes Sometimes Mixed results
- Recipes with a single item displayed in the slot are considered player held.
- Recipe slots with 2 stacked items treat the top as player held and the bottom as
notplayer held. This one is the weirdest case on this list.- The crafting grids in the expanded recipe previews for items with many recipes are treated as player held. This is consistent with the behavior for the full size grids, but unknown if intended, as these items are intangible.
Crafting Table/Crafter input slots Yes Uncertain1 Crafting Table/Crafter output slots No Uncertain1 These are the only two cases where an output slot is not considered player held. Missing ingredient recipe displays No Yes Not a tangible item, seems likely to be correct. All Anvil slots Yes Uncertain1 All Brewing Stand slots Yes Uncertain1 Beacon payment slot Yes Uncertain1 Beacon payment example items Yes No Not a tangible item, so unable to be held. All Furnace, Blast Furnace, and Smoker slots Yes Uncertain1 All Loom slots Yes Uncertain1 All Smithing Table slots Yes Uncertain1 All Cartography Table slots Yes Uncertain1 All Grindstone slots Yes Uncertain1 Stonecutter Yes Mixed Results The selectable recipes are not tangible items, but the input and output slots should follow note 1. Currently all three are considered player held. Items in Container blocks, such as Chests, Barrels, and Shulker boxes Yes Uncertain2 Items in the equipment/storage slots of Horses, Mules, Donkeys, and Llamas Yes Uncertain2 Items in the Bundle tooltip/preview Yes Uncertain, likely No This one is a weird case because the item inside of the bundle isn't being held, the bundle is. Villager/Wandering Trader trades list No Yes These items are unaffected by checking if the holder type is a Villager/Wandering Trader, but this may be intended depending on how note 1 is treated. Villager/Wandering Trader input/output slots Yes Uncertain1 1 - Entirely depends on if items placed in GUI slots still being considered as player held is intended behavior. If it is, then only crafting output slots are incorrect.
2 - Depends on if storage/container slots are intended to be treated differently from workstation GUI slots, due to the ability to close the gui and store the item permanently in the slot, unlike the ones covered by note 1.
Attached are screenshots of the cases listed in the chart. The item model being an apple means that it is considered player held, and the item model being a potato means that it is not. The resource pack used to test this is also attached - various random items were used to test the different cases, so refer to the files at assets/minecraft/items to see which are changed.
When using an item model that changes based off the holder_type property checking for a player, the result is very inconsistent between various GUIs and screens in the game that render or hold items. Below is a table documenting the different screens/GUIs, whether or not items within them are considered as held by a player, whether or not this seems intended or correct, and any additional notes on the behavior.
Screen/GUI Considered as held
by a player?Likely to be correct? Additional notes Toasts No Yes Advancements No Yes Statistics No Yes World Creation No Yes Gamemode Switcher Yes No Seems likely to be incorrect based on the other non-block UI screen behaviors. Not a tangible item, cannot be held. Recipe Book Tabs No Yes Intangible item, cannot be held. Creative Menu tabs Yes No Inconsistent with the recipe book tabs and other intangible items. Recipe Book recipes Sometimes Mixed results
- Recipes with a single item displayed in the slot are considered player held.
- Recipe slots with 2 stacked items treat the top as not player held and the bottom as player held. This one is the weirdest case on this list.
- The crafting grids in the expanded recipe previews for items with many recipes are treated as player held. This is consistent with the behavior for the full size grids, but unknown if intended, as these items are intangible.
Crafting Table/Crafter input slots Yes Uncertain1 Crafting Table/Crafter output slots No Uncertain1 These are the only two cases where an output slot is not considered player held. Missing ingredient recipe displays No Yes Not a tangible item, seems likely to be correct. All Anvil slots Yes Uncertain1 All Brewing Stand slots Yes Uncertain1 Beacon payment slot Yes Uncertain1 Beacon payment example items Yes No Not a tangible item, so unable to be held. All Furnace, Blast Furnace, and Smoker slots Yes Uncertain1 All Loom slots Yes Uncertain1 All Smithing Table slots Yes Uncertain1 All Cartography Table slots Yes Uncertain1 All Grindstone slots Yes Uncertain1 Stonecutter Yes Mixed Results The selectable recipes are not tangible items, but the input and output slots should follow note 1. Currently all three are considered player held. Items in Container blocks, such as Chests, Barrels, and Shulker boxes Yes Uncertain2 Items in the equipment/storage slots of Horses, Mules, Donkeys, and Llamas Yes Uncertain2 Items in the Bundle tooltip/preview Yes Uncertain, likely No This one is a weird case because the item inside of the bundle isn't being held, the bundle is. Villager/Wandering Trader trades list No Yes These items are unaffected by checking if the holder type is a Villager/Wandering Trader, but this may be intended depending on how note 1 is treated. Villager/Wandering Trader input/output slots Yes Uncertain1 1 - Entirely depends on if items placed in GUI slots still being considered as player held is intended behavior. If it is, then only crafting output slots are incorrect.
2 - Depends on if storage/container slots are intended to be treated differently from workstation GUI slots, due to the ability to close the gui and store the item permanently in the slot, unlike the ones covered by note 1.
Attached are screenshots of the cases listed in the chart. The item model being an apple means that it is considered player held, and the item model being a potato means that it is not. The resource pack used to test this is also attached - various random items were used to test the different cases, so refer to the files at assets/minecraft/items to see which are changed.
When using an item model that changes based off the holder_type property checking for a player, the result is very inconsistent between various GUIs and screens in the game that render or hold items. Below is a table documenting the different screens/GUIs, whether or not items within them are considered as held by a player, whether or not this seems intended or correct, and any additional notes on the behavior.
Screen/GUI Considered as held
by a player?Likely to be correct? Additional notes Toasts No Yes Advancements No Yes Statistics No Yes World Creation No Yes Gamemode Switcher Yes No Seems likely to be incorrect based on the other non-block UI screen behaviors. Not a tangible item, cannot be held. Recipe Book Tabs No Yes Intangible item, cannot be held. Creative Menu tabs Yes No Inconsistent with the recipe book tabs and other intangible items. Recipe Book recipes Sometimes Mixed results
- Recipes with a single item displayed in the slot are not considered player held.
- Recipe slots with 2 stacked items treat the top as not player held and the bottom as player held. This one is the weirdest case on this list.
- The crafting grids in the expanded recipe previews for items with many recipes are treated as player held. This is consistent with the behavior for the full size grids, but unknown if intended, as these items are intangible.
Crafting Table/Crafter input slots Yes Uncertain1 Crafting Table/Crafter output slots No Uncertain1 These are the only two cases where an output slot is not considered player held. Missing ingredient recipe displays No Yes Not a tangible item, seems likely to be correct. All Anvil slots Yes Uncertain1 All Brewing Stand slots Yes Uncertain1 Beacon payment slot Yes Uncertain1 Beacon payment example items Yes No Not a tangible item, so unable to be held. All Furnace, Blast Furnace, and Smoker slots Yes Uncertain1 All Loom slots Yes Uncertain1 All Smithing Table slots Yes Uncertain1 All Cartography Table slots Yes Uncertain1 All Grindstone slots Yes Uncertain1 Stonecutter Yes Mixed Results The selectable recipes are not tangible items, but the input and output slots should follow note 1. Currently all three are considered player held. Items in Container blocks, such as Chests, Barrels, and Shulker boxes Yes Uncertain2 Items in the equipment/storage slots of Horses, Mules, Donkeys, and Llamas Yes Uncertain2 Items in the Bundle tooltip/preview Yes Uncertain, likely No This one is a weird case because the item inside of the bundle isn't being held, the bundle is. Villager/Wandering Trader trades list No Yes These items are unaffected by checking if the holder type is a Villager/Wandering Trader, but this may be intended depending on how note 1 is treated. Villager/Wandering Trader input/output slots Yes Uncertain1 1 - Entirely depends on if items placed in GUI slots still being considered as player held is intended behavior. If it is, then only crafting output slots are incorrect.
2 - Depends on if storage/container slots are intended to be treated differently from workstation GUI slots, due to the ability to close the gui and store the item permanently in the slot, unlike the ones covered by note 1.
Attached are screenshots of the cases listed in the chart. The item model being an apple means that it is considered player held, and the item model being a potato means that it is not. The resource pack used to test this is also attached - various random items were used to test the different cases, so refer to the files at assets/minecraft/items to see which are changed.
When using an item model that changes based off the holder_type property checking for a player, the result is very inconsistent between various GUIs and screens in the game that render or hold items. Below is a table documenting the different screens/GUIs, whether or not items within them are considered as held by a player, whether or not this seems intended or correct, and any additional notes on the behavior.
Screen/GUI Considered as held
by a player?Likely to be correct? Additional notes Toasts No Yes Advancements No Yes Statistics No Yes World Creation No Yes Gamemode Switcher Yes No Seems likely to be incorrect based on the other non-block UI screen behaviors. Not a tangible item, cannot be held. Recipe Book Tabs No Yes Intangible item, cannot be held. Creative Menu tabs Yes No Inconsistent with the recipe book tabs and other intangible items. Recipe Book recipes Sometimes Mixed results
- Recipes with a single item displayed in the slot are not considered player held.
- Recipe slots with 2 stacked items treat the top as not player held and the bottom as player held. This one is the weirdest case on this list.
- The crafting grids in the expanded recipe previews for items with many recipes are treated as player held. This is consistent with the behavior for the full size grids, but unknown if intended, as these items are intangible.
Crafting Table/Crafter input slots Yes Uncertain1 Crafting Table/Crafter output slots No Uncertain1 These are the only two cases where an output slot is not considered player held. Missing ingredient recipe displays No Yes Not a tangible item, seems likely to be correct. All Anvil slots Yes Uncertain1 All Brewing Stand slots Yes Uncertain1 Beacon payment slot Yes Uncertain1 Beacon payment example items Yes No Not a tangible item, so unable to be held. All Furnace, Blast Furnace, and Smoker slots Yes Uncertain1 All Loom slots Yes Uncertain1 All Smithing Table slots Yes Uncertain1 All Cartography Table slots Yes Uncertain1 All Grindstone slots Yes Uncertain1 Stonecutter Yes Mixed Results The selectable recipes are not tangible items, but the input and output slots should follow note 1. Currently all three are considered player held. Items in Container blocks, such as Chests, Barrels, and Shulker boxes Yes Uncertain2 Items in the equipment/storage slots of Horses, Mules, Donkeys, and Llamas Yes Uncertain2 Items in the Bundle tooltip/preview Yes Uncertain, likely No This one is a weird case because the item inside of the bundle isn't being held, the bundle is. Villager/Wandering Trader trades list No Yes These items are unaffected by checking if the holder type is a Villager/Wandering Trader, but this may be intended depending on how note 1 is treated. Villager/Wandering Trader input/output slots Yes Uncertain1 1 - Entirely depends on if items placed in GUI slots still being considered as player held is intended behavior. If it is, then only crafting output slots are incorrect.
2 - Depends on if storage/container slots are intended to be treated differently from workstation GUI slots, due to the ability to close the gui and store the item permanently in the slot, unlike the ones covered by note 1.
Attached are screenshots of the cases listed in the chart. The item model being an apple means that it is considered player held, and the item model being a potato means that it is not. The resource pack used to test this is also attached - various random items were used to test the different cases, so refer to the files at assets/minecraft/items to see which are changed.
When using an item model that changes based off the holder_type property checking for a player, the result is very inconsistent between various GUIs and screens in the game that render or hold items. Below is a table documenting the different screens/GUIs, whether or not items within them are considered as held by a player, whether or not this seems intended or correct, and any additional notes on the behavior.
Screen/GUI Considered as held
by a player?Likely to be correct? Additional notes Toasts No Yes Advancements No Yes Statistics No Yes World Creation No Yes Gamemode Switcher Yes No Seems likely to be incorrect based on the other non-block UI screen behaviors. Not a tangible item, cannot be held. Recipe Book Tabs No Yes Intangible item, cannot be held. Creative Menu tabs Yes No Inconsistent with the recipe book tabs and other intangible items. Recipe Book recipes Sometimes Mixed results
- Recipes with a single item displayed in the slot are not considered player held.
- Recipe slots with 2 stacked items treat the top as not player held and the bottom as player held. This one is the weirdest case on this list.
- The crafting grids in the expanded recipe previews for items with many recipes are treated as player held. This is consistent with the behavior for the full size grids, but unknown if intended, as these items are intangible.
Crafting Table/Crafter input slots Yes Uncertain1 Crafting Table/Crafter output slots No Yes MC-186797Missing ingredient recipe displays No Yes Not a tangible item, seems likely to be correct. All Anvil slots Yes Uncertain1 All Brewing Stand slots Yes Uncertain1 Beacon payment slot Yes Uncertain1 Beacon payment example items Yes No Not a tangible item, so unable to be held. All Furnace, Blast Furnace, and Smoker slots Yes Uncertain1 All Loom slots Yes Uncertain1 All Smithing Table slots Yes Uncertain1 All Cartography Table slots Yes Uncertain1 All Grindstone slots Yes Uncertain1 Stonecutter Yes Mixed Results The selectable recipes are not tangible items, but the input and output slots should follow note 1. Currently all three are considered player held. Items in Container blocks, such as Chests, Barrels, and Shulker boxes Yes Uncertain2 Items in the equipment/storage slots of Horses, Mules, Donkeys, and Llamas Yes Uncertain2 Items in the Bundle tooltip/preview Yes Uncertain, likely No This one is a weird case because the item inside of the bundle isn't being held, the bundle is. Villager/Wandering Trader trades list No Yes These items are unaffected by checking if the holder type is a Villager/Wandering Trader, but this may be intended depending on how note 1 is treated. Villager/Wandering Trader input/output slots Yes Uncertain1 1 - Entirely depends on if items placed in GUI slots still being considered as player held is intended behavior. If it is, then only crafting output slots are incorrect.
2 - Depends on if storage/container slots are intended to be treated differently from workstation GUI slots, due to the ability to close the gui and store the item permanently in the slot, unlike the ones covered by note 1.
Attached are screenshots of the cases listed in the chart. The item model being an apple means that it is considered player held, and the item model being a potato means that it is not. The resource pack used to test this is also attached - various random items were used to test the different cases, so refer to the files at assets/minecraft/items to see which are changed.
When using an item model that changes based off the holder_type property checking for a player, the result is very inconsistent between various GUIs and screens in the game that render or hold items. Below is a table documenting the different screens/GUIs, whether or not items within them are considered as held by a player, whether or not this seems intended or correct, and any additional notes on the behavior.
Screen/GUI Considered as held
by a player?Likely to be correct? Additional notes Toasts No Yes Advancements No Yes Statistics No Yes World Creation No Yes Gamemode Switcher Yes No Seems likely to be incorrect based on the other non-block UI screen behaviors. Not a tangible item, cannot be held. Recipe Book Tabs No Yes Intangible item, cannot be held. Creative Menu tabs Yes No Inconsistent with the recipe book tabs and other intangible items. Recipe Book recipes Sometimes Mixed results
- Recipes with a single item displayed in the slot are not considered player held.
- Recipe slots with 2 stacked items treat the top as not player held and the bottom as player held. This one is the weirdest case on this list.
- The crafting grids in the expanded recipe previews for items with many recipes are treated as player held. This is consistent with the behavior for the full size grids, but unknown if intended, as these items are intangible.
Crafting Table/Crafter input slots YesUncertain1 Crafting Table/Crafter output slots No Yes MC-186797Missing ingredient recipe displays No Yes Not a tangible item, seems likely to be correct. All Anvil slots Yes Uncertain1 All Brewing Stand slots Yes Uncertain 1Beacon payment slot Yes Uncertain1 Beacon payment example items Yes No Not a tangible item, so unable to be held. All Furnace, Blast Furnace, and Smoker slots Yes Uncertain 1All Loom slots Yes Uncertain1 All Smithing Table slots Yes Uncertain1 All Cartography Table slots Yes Uncertain1 All Grindstone slots Yes Uncertain1 Stonecutter Yes Mixed Results The selectable recipes are not tangible items, but the input and output slots should follow note 1. Currently all three are considered player held. Items in Container blocks, such as Chests, Barrels, and Shulker boxes Yes Uncertain2 Items in the equipment/storage slots of Horses, Mules, Donkeys, and Llamas Yes Uncertain2 Items in the Bundle tooltip/preview Yes Uncertain, likely No This one is a weird case because the item inside of the bundle isn't being held, the bundle is. Villager/Wandering Trader trades list No Yes These items are unaffected by checking if the holder type is a Villager/Wandering Trader, but this may be intended depending on how note 1 is treated. Villager/Wandering Trader input/output slots Yes Uncertain1 1 - Entirely depends on if items placed in GUI slots still being considered as player held is intended behavior. If it is, then only crafting output slots are incorrect.
2 - Depends on if storage/container slots are intended to be treated differently from workstation GUI slots, due to the ability to close the gui and store the item permanently in the slot, unlike the ones covered by note 1.
Attached are screenshots of the cases listed in the chart. The item model being an apple means that it is considered player held, and the item model being a potato means that it is not. The resource pack used to test this is also attached - various random items were used to test the different cases, so refer to the files at assets/minecraft/items to see which are changed.
When using an item model that changes based off the holder_type property checking for a player, the result is very inconsistent between various GUIs and screens in the game that render or hold items. Below is a table documenting the different screens/GUIs, whether or not items within them are considered as held by a player, whether or not this seems intended or correct, and any additional notes on the behavior.
Screen/GUI Considered as held
by a player?Likely to be correct? Additional notes Toasts No Yes Advancements No Yes Statistics No Yes Seems to be intended as the resolution to MC-8550World Creation No Yes Gamemode Switcher Yes No Seems likely to be incorrect based on the other non-block UI screen behaviors. Not a tangible item, cannot be held. Recipe Book Tabs No Yes Intangible item, cannot be held. Also seems to be intended as the resolution to MC-116293Creative Menu tabs Yes No Inconsistent with the recipe book tabs and other intangible items. Recipe Book recipes Sometimes Mixed results
- Recipes with a single item displayed in the slot are not considered player held.
- Recipe slots with 2 stacked items treat the top as not player held and the bottom as player held. This one is the weirdest case on this list.
- The crafting grids in the expanded recipe previews for items with many recipes are treated as player held. This is consistent with the behavior for the full size grids, but unknown if intended, as these items are intangible.
Recipes seem to be intended to not be player held as the resolution to
MC-116293|
Crafting Table/Crafter input slots Yes Uncertain1 Crafting Table/Crafter output slots No Yes Seems to be intended as the resolution to MC-186797Missing ingredient recipe displays No Yes Not a tangible item, seems likely to be correct. All Anvil slots Yes Uncertain1 All Brewing Stand slots Yes Uncertain2 Beacon payment slot Yes Uncertain1 Beacon payment example items Yes No Not a tangible item, so unable to be held. All Furnace, Blast Furnace, and Smoker slots Yes Uncertain2 All Loom slots Yes Uncertain1 All Smithing Table slots Yes Uncertain1 All Cartography Table slots Yes Uncertain1 All Grindstone slots Yes Uncertain1 Stonecutter Yes Mixed Results The selectable recipes are not tangible items, but the input and output slots should follow note 1. Currently all three are considered player held. Items in Container blocks, such as Chests, Barrels, and Shulker boxes Yes Uncertain2 Items in the equipment/storage slots of Horses, Mules, Donkeys, and Llamas Yes Uncertain2 Items in the Bundle tooltip/preview Yes Uncertain, likely No This one is a weird case because the item inside of the bundle isn't being held, the bundle is. Villager/Wandering Trader trades list No Yes Seems to be intended as the resolution to MC-182888Villager/Wandering Trader input/output slots Yes No Seems to be unintended, MC-186849 is unresolved but confirmed, and relates to MC-1828881 - Entirely depends on if items placed in GUI slots still being considered as player held is intended behavior. If it is, then only crafting output slots are incorrect.
2 - Depends on if storage/container slots are intended to be treated differently from workstation GUI slots, due to the ability to close the gui and store the item permanently in the slot, unlike the ones covered by note 1.
Attached are screenshots of the cases listed in the chart. The item model being an apple means that it is considered player held, and the item model being a potato means that it is not. The resource pack used to test this is also attached - various random items were used to test the different cases, so refer to the files at assets/minecraft/items to see which are changed.
Inconsistent results when an item that checks for a playerholder_typeis in a GUI or menu screenInconsistent results when an item that checks for a player context_entity is in a GUI or menu screen
Inconsistent results when an item that checks for a player context_entity_type is in a GUI or menu screen
When using an item model that changes based off the holder_type property checking for a player, the result is very inconsistent between various GUIs and screens in the game that render or hold items. Below is a table documenting the different screens/GUIs, whether or not items within them are considered as held by a player, whether or not this seems intended or correct, and any additional notes on the behavior.
Screen/GUI Considered as held
by a player?Likely to be correct? Additional notes Toasts No Yes Advancements No Yes Statistics No Yes Seems to be intended as the resolution to MC-8550World Creation No Yes Gamemode Switcher Yes No Seems likely to be incorrect based on the other non-block UI screen behaviors. Not a tangible item, cannot be held. Recipe Book Tabs No Yes Intangible item, cannot be held. Also seems to be intended as the resolution to MC-116293Creative Menu tabs Yes No Inconsistent with the recipe book tabs and other intangible items. Recipe Book recipes Sometimes Mixed results
- Recipes with a single item displayed in the slot are not considered player held.
- Recipe slots with 2 stacked items treat the top as not player held and the bottom as player held. This one is the weirdest case on this list.
- The crafting grids in the expanded recipe previews for items with many recipes are treated as player held. This is consistent with the behavior for the full size grids, but unknown if intended, as these items are intangible.
Recipes seem to be intended to not be player held as the resolution to
MC-116293|
Crafting Table/Crafter input slotsYes Uncertain1 Crafting Table/Crafter output slots No Yes Seems to be intended as the resolution to MC-186797Missing ingredient recipe displays No Yes Not a tangible item, seems likely to be correct. All Anvil slots Yes Uncertain1 All Brewing Stand slots Yes Uncertain2 Beacon payment slot Yes Uncertain1 Beacon payment example items Yes No Not a tangible item, so unable to be held. All Furnace, Blast Furnace, and Smoker slots Yes Uncertain2 All Loom slots Yes Uncertain1 All Smithing Table slots Yes Uncertain1 All Cartography Table slots Yes Uncertain1 All Grindstone slots Yes Uncertain1 Stonecutter Yes Mixed Results The selectable recipes are not tangible items, but the input and output slots should follow note 1. Currently all three are considered player held. Items in Container blocks, such as Chests, Barrels, and Shulker boxesYes Uncertain2 Items in the equipment/storage slots of Horses, Mules, Donkeys, and Llamas Yes Uncertain2 Items in the Bundle tooltip/preview Yes Uncertain, likely No This one is a weird case because the item inside of the bundle isn't being held, the bundle is. Villager/Wandering Trader trades list No Yes Seems to be intended as the resolution to MC-182888Villager/Wandering Trader input/output slots Yes No Seems to be unintended, MC-186849 is unresolved but confirmed, and relates to MC-1828881 - Entirely depends on if items placed in GUI slots still being considered as player held is intended behavior. If it is, then only crafting output slots are incorrect.
2 - Depends on if storage/container slots are intended to be treated differently from
workstation GUI slots, due to the ability to close the gui and store the item permanently in the slot, unlike the ones covered by note 1.
Attached are screenshots of the cases listed in the chart. The item model being an apple means that it is considered player held, and the item model being a potato means that it is not. The resource pack used to test this is also attached - various random items were used to test the different cases, so refer to the files at assets/minecraft/items to see which are changed.
When using an item model that changes based off the holder_type property checking for a player, the result is very inconsistent between various GUIs and screens in the game that render or hold items. Below is a table documenting the different screens/GUIs, whether or not items within them are considered as held by a player, whether or not this seems intended or correct, and any additional notes on the behavior.
Screen/GUI Considered as held
by a player?Likely to be correct? Additional notes Toasts No Yes Advancements No Yes Statistics No Yes Seems to be intended as the resolution to MC-8550World Creation No Yes Gamemode Switcher Yes No Seems likely to be incorrect based on the other non-block UI screen behaviors. Not a tangible item, cannot be held. Recipe Book Tabs No Yes Intangible item, cannot be held. Also seems to be intended as the resolution to MC-116293Creative Menu tabs Yes No Inconsistent with the recipe book tabs and other intangible items. Recipe Book recipes Sometimes Mixed results
- Recipes with a single item displayed in the slot are not considered player held. Seems intended as the resolution to
MC-116293- Recipe slots with 2 stacked items treat the top as not player held and the bottom as player held. This one is the weirdest case on this list.
- The crafting grids in the expanded recipe previews for items with many recipes are treated as player held. This is consistent with the behavior for the full size grids, but unknown if intended, as these items are intangible.
Crafting Table/Crafter input slots Yes Uncertain1 Crafting Table/Crafter output slots No Yes Seems to be intended as the resolution to MC-186797Missing ingredient recipe displays No Yes Not a tangible item, seems likely to be correct. All Anvil slots Yes Uncertain1 All Brewing Stand slots Yes Uncertain2 Beacon payment slot Yes Uncertain1 Beacon payment example items Yes No Not a tangible item, so unable to be held. All Furnace, Blast Furnace, and Smoker slots Yes Uncertain2 All Loom slots Yes Uncertain1 All Smithing Table slots Yes Uncertain1 All Cartography Table slots Yes Uncertain1 All Grindstone slots Yes Uncertain1 Stonecutter Yes Mixed Results The selectable recipes are not tangible items, but the input and output slots should follow note 1. Currently all three are considered player held. Items in container blocks, such as Chests, Barrels, and Shulker boxes Yes Uncertain2 Items in the equipment/storage slots of Horses, Mules, Donkeys, and Llamas Yes Uncertain2 Items in the Bundle tooltip/preview Yes Uncertain, likely No This one is a weird case because the item inside of the bundle isn't being held, the bundle is. Villager/Wandering Trader trades list No Yes Seems to be intended as the resolution to MC-182888Villager/Wandering Trader input/output slots Yes No Seems to be unintended, MC-186849 is unresolved but confirmed, and relates to MC-182888
1 - Entirely depends on if items placed in GUI slots still considering the player as their context entity is intended behavior.2 - Depends on if storage/container slots are intended to be treated differently from slots in GUIs that don't hold items when closed, unlike the ones covered by note 1.
Attached are screenshots of the cases listed in the chart. The item model being an apple means that it is considered player held, and the item model being a potato means that it is not. The resource pack used to test this is also attached - various random items were used to test the different cases, so refer to the files at assets/minecraft/items to see which are changed.
When using an item model that changes based off the holder_type property checking for a player, the result is very inconsistent between various GUIs and screens in the game that render or hold items. Below is a table documenting the different screens/GUIs, whether or not items within them are considered as held by a player, whether or not this seems intended or correct, and any additional notes on the behavior.
Screen/GUI Considered as held
by a player?Likely to be correct? Additional notes Toasts No Yes Advancements No Yes Statistics No Yes Seems to be intended as the resolution to MC-8550World Creation No Yes Gamemode Switcher Yes No Seems likely to be incorrect based on the other non-block UI screen behaviors. Not a tangible item, cannot be held. Recipe Book Tabs No Yes Intangible item, cannot be held. Also seems to be intended as the resolution to MC-116293Creative Menu tabs Yes No Inconsistent with the recipe book tabs and other intangible items. Recipe Book recipes Sometimes Mixed results
- Recipes with a single item displayed in the slot are not considered player held. Seems intended as the resolution to
MC-116293- Recipe slots with 2 stacked items treat the top as not player held and the bottom as player held. This one is the weirdest case on this list.
- The crafting grids in the expanded recipe previews for items with many recipes are treated as player held. This is consistent with the behavior for the full size grids, but unknown if intended, as these items are intangible.
Crafting Table/Crafter input slots Yes Uncertain1 Crafting Table/Crafter output slots No Yes Seems to be intended as the resolution to MC-186797Missing ingredient recipe displays No Yes Not a tangible item, seems likely to be correct. All Anvil slots Yes Uncertain1 All Brewing Stand slots Yes Uncertain2 Beacon payment slot Yes Uncertain1 Beacon payment example items Yes No Not a tangible item, so unable to be held. All Furnace, Blast Furnace, and Smoker slots Yes Uncertain2 All Loom slots Yes Uncertain1 All Smithing Table slots Yes Uncertain1 All Cartography Table slots Yes Uncertain1 All Grindstone slots Yes Uncertain1 Stonecutter Yes Mixed Results The selectable recipes are not tangible items, but the input and output slots should follow note 1. Currently all three are considered player held. Items in container blocks, such as Chests, Barrels, and Shulker boxes Yes Uncertain2 Items in the equipment/storage slots of Horses, Mules, Donkeys, and Llamas Yes Uncertain2 Items in the Bundle tooltip/preview Yes Uncertain, likely No This one is a weird case because the item inside of the bundle isn't being held, the bundle is. Villager/Wandering Trader trades list No Yes Seems to be intended as the resolution to MC-182888Villager/Wandering Trader input/output slots Yes No Seems to be unintended, MC-186849 is unresolved but confirmed, and relates to MC-182888
1 - Entirely depends on if items placed in GUI slots still considering the player as their context entity is intended behavior.2 - Depends on if storage/container slots are intended to be treated differently from slots in GUIs that don't hold items when closed, unlike the ones covered by note 1.
Attached are screenshots of the cases listed in the chart. The item model being an apple means that it is considered player held, and the item model being a potato means that it is not. The resource pack used to test this is also attached - various random items were used to test the different cases, so refer to the files at assets/minecraft/items to see which are changed.
When using an item model that changes based off the holder_type property checking for a player, the result is very inconsistent between various GUIs and screens in the game that render or hold items. Below is a table documenting the different screens/GUIs, whether or not items within them are considered as held by a player, whether or not this seems intended or correct, and any additional notes on the behavior.
Screen/GUI Considered as held
by a player?Likely to be correct? Additional notes Toasts No Yes Advancements No Yes Statistics No Yes Seems to be intended as the resolution to MC-8550World Creation No Yes Gamemode Switcher Yes No Seems likely to be incorrect based on the other non-block UI screen behaviors. Not a tangible item, cannot be held. Recipe Book Tabs No Yes Intangible item, cannot be held. Also seems to be intended as the resolution to MC-116293Creative Menu tabs Yes No Inconsistent with the recipe book tabs and other intangible items. Also seems to be unintended, as MC-182892 is confirmed but unresolved. Recipe Book recipes Sometimes Mixed results
- Recipes with a single item displayed in the slot are not considered player held. Seems intended as the resolution to
MC-116293- Recipe slots with 2 stacked items treat the top as not player held and the bottom as player held. This one is the weirdest case on this list.
- The crafting grids in the expanded recipe previews for items with many recipes are treated as player held. This is consistent with the behavior for the full size grids, but unknown if intended, as these items are intangible.
Crafting Table/Crafter input slots Yes Uncertain1 Crafting Table/Crafter output slots No Yes Seems to be intended as the resolution to MC-186797Missing ingredient recipe displays No Yes Not a tangible item, seems likely to be correct. All Anvil slots Yes Uncertain1 All Brewing Stand slots Yes Uncertain2 Beacon payment slot Yes Uncertain1 Beacon payment example items Yes No Not a tangible item, so unable to be held. All Furnace, Blast Furnace, and Smoker slots Yes Uncertain2 All Loom slots Yes Uncertain1 All Smithing Table slots Yes Uncertain1 All Cartography Table slots Yes Uncertain1 All Grindstone slots Yes Uncertain1 Stonecutter Yes Mixed Results The selectable recipes are not tangible items, but the input and output slots should follow note 1. Currently all three are considered player held. Items in container blocks, such as Chests, Barrels, and Shulker boxes Yes Uncertain2 Items in the equipment/storage slots of Horses, Mules, Donkeys, and Llamas Yes Uncertain2 Items in the Bundle tooltip/preview Yes Uncertain, likely No This one is a weird case because the item inside of the bundle isn't being held, the bundle is. Villager/Wandering Trader trades list No Yes Seems to be intended as the resolution to MC-182888Villager/Wandering Trader input/output slots Yes No Seems to be unintended, MC-186849 is unresolved but confirmed, and relates to MC-182888
1 - Entirely depends on if items placed in GUI slots still considering the player as their context entity is intended behavior.2 - Depends on if storage/container slots are intended to be treated differently from slots in GUIs that don't hold items when closed, unlike the ones covered by note 1.
Attached are screenshots of the cases listed in the chart. The item model being an apple means that it is considered player held, and the item model being a potato means that it is not. The resource pack used to test this is also attached - various random items were used to test the different cases, so refer to the files at assets/minecraft/items to see which are changed.
When using an item model that changes based off theholder_type property checking for a player, the result is very inconsistent between various GUIs and screens in the game that render or hold items. Below is a table documenting the different screens/GUIs, whether or not items within themareconsideredas held by a player, whether or not this seems intended or correct, and any additional notes on the behavior.
Screen/GUI Considered as held
by a player?Likely to be correct? Additional notes Toasts No Yes Advancements No Yes Statistics No Yes Seems to be intended as the resolution to MC-8550World Creation No Yes Gamemode Switcher Yes No Seems likely to be incorrect based on the other non-block UI screen behaviors. Not a tangible item , cannot be held.Recipe Book Tabs No Yes Intangible item, cannot be held. Also seems to be intended as the resolution toMC-116293Creative Menu tabs Yes No Inconsistent with the recipe book tabs and other intangible items. Also seems to be unintended, as MC-182892 is confirmed but unresolved.Recipe Book recipes Sometimes Mixed results
- Recipes with a single item displayed in the slot are not considered player
held. Seems intended as the resolution toMC-116293- Recipe slots with 2 stacked items treat the top as not player
heldand the bottom as playerheld. This one is the weirdest case on this list.- The crafting grids in the expanded recipe previews for items with many recipes are treated as player
held. This is consistent with the behavior for the full size grids, but unknown if intended, as these items are intangible.Crafting Table/Crafter input slots Yes Uncertain1 Crafting Table/Crafter output slots No Yes Seems to be intended as the resolution to MC-186797Missing ingredient recipe displays No Yes Not a tangible item, seems likely to be correct. All Anvil slots Yes Uncertain1 All Brewing Stand slots Yes Uncertain2 Beacon payment slot Yes Uncertain1 Beacon payment example items Yes No Not a tangible item , so unable to be held.All Furnace, Blast Furnace, and Smoker slots Yes Uncertain2 All Loom slots Yes Uncertain1 All Smithing Table slots Yes Uncertain1 All Cartography Table slots Yes Uncertain1 All Grindstone slots Yes Uncertain1 Stonecutter Yes Mixed Results The selectable recipes are not tangible items, but the input and output slots should follow note 1. Currently all three areconsidered playerheld.Items in container blocks, such as Chests, Barrels, and Shulker boxes Yes Uncertain2 Items in the equipment/storage slots of Horses, Mules, Donkeys, and Llamas Yes Uncertain2 Items in the Bundle tooltip/preview Yes Uncertain, likely NoThis one is a weird case because the item inside of the bundle isn't being held, the bundle is. Villager/Wandering Trader trades list No Yes Seems to be intended as the resolution to MC-182888Villager/Wandering Trader input/output slots Yes No Seems to be unintended, MC-186849 is unresolved but confirmed, and relates to MC-182888
1 - Entirely depends on if items placed in GUI slots still considering the player as their context entity is intended behavior.2 - Depends on if storage/container slots are intended to be treated differently from slots in GUIs that don't hold items when closed, unlike the ones covered by note 1.
Attached are screenshots of the cases listed in the chart. The item model being an apple means that it is considered player held, and the item model being a potato means that it is not. The resource pack used to test this is also attached - various random items were used to test the different cases, so refer to the files at assets/minecraft/items to see which are changed.
When using an item model that changes based off the context_entity_type property checking for a player, the result is very inconsistent between various GUIs and screens in the game that render or hold items. Below is a table documenting the different screens/GUIs, whether or not items within them consider the player as the context entity, whether or not this seems intended or correct, and any additional notes on the behavior.
Screen/GUI Considered as held
by a player?Likely to be correct? Additional notes Toasts No Yes Advancements No Yes Statistics No Yes Seems to be intended as the resolution to MC-8550World Creation No Yes Gamemode Switcher Yes No Seems likely to be incorrect based on the other non-block UI screen behaviors. Not a tangible item. Recipe Book Tabs No Yes Seems to be intended as the resolution to MC-116293Creative Menu tabs Yes No Inconsistent with the recipe book tabs. Seems to be unintended, as MC-182892 is confirmed but unresolved. Recipe Book recipes Sometimes Mixed results
- Recipes with a single item displayed in the slot are not considered as player context. Seems intended as the resolution to
MC-116293- Recipe slots with 2 stacked items treat the top as not player context and the bottom as player context. This one is the weirdest case on this list.
- The crafting grids in the expanded recipe previews for items with many recipes are treated as player context. This is consistent with the behavior for the full size grids, but inconsistent with the other recipe book items and unknown if intended, as these items are intangible.
Crafting Table/Crafter input slots Yes Uncertain1 Crafting Table/Crafter output slots No Yes Seems to be intended as the resolution to MC-186797Missing ingredient recipe displays No Yes Not a tangible item, seems likely to be correct. All Anvil slots Yes Uncertain1 All Brewing Stand slots Yes Uncertain2 Beacon payment slot Yes Uncertain1 Beacon payment example items Yes No Not a tangible item. All Furnace, Blast Furnace, and Smoker slots Yes Uncertain2 All Loom slots Yes Uncertain1 All Smithing Table slots Yes Uncertain1 All Cartography Table slots Yes Uncertain1 All Grindstone slots Yes Uncertain1 Stonecutter Yes Mixed Results The selectable recipes are not tangible items, but the input and output slots should follow note 1. Currently all three considered the player as the context entity type. Items in container blocks, such as Chests, Barrels, and Shulker boxes Yes Uncertain2 Items in the equipment/storage slots of Horses, Mules, Donkeys, and Llamas Yes Uncertain2 Items in the Bundle tooltip/preview Yes Uncertain, likely yes Villager/Wandering Trader trades list No Yes Seems to be intended as the resolution to MC-182888Villager/Wandering Trader input/output slots Yes No Seems to be unintended, MC-186849 is unresolved but confirmed, and relates to MC-182888
1 - Entirely depends on if items placed in GUI slots still considering the player as their context entity is intended behavior.2 - Depends on if storage/container slots are intended to be treated differently from slots in GUIs that don't hold items when closed, unlike the ones covered by note 1.
Attached are screenshots of the cases listed in the chart. The item model being an apple means that it is considered player held, and the item model being a potato means that it is not. The resource pack used to test this is also attached - various random items were used to test the different cases, so refer to the files at assets/minecraft/items to see which are changed.
When using an item model that changes based off the context_entity_type property checking for a player, the result is very inconsistent between various GUIs and screens in the game that render or hold items. Below is a table documenting the different screens/GUIs, whether or not items within them consider the player as the context entity, whether or not this seems intended or correct, and any additional notes on the behavior.
Screen/GUI Considered as held
by a player?Likely to be correct? Additional notes Toasts No Yes Advancements No Yes Statistics No Yes Seems to be intended as the resolution to MC-8550World Creation No Yes Gamemode Switcher Yes No Seems likely to be incorrect based on the other non-block UI screen behaviors. Not a tangible item. Recipe Book Tabs No Yes Seems to be intended as the resolution to MC-116293Creative Menu tabs Yes No Inconsistent with the recipe book tabs. Seems to be unintended, as MC-182892 is confirmed but unresolved. Recipe Book recipes Sometimes Mixed results
- Recipes with a single item displayed in the slot are not considered as player context. Seems intended as the resolution to
MC-116293- Recipe slots with 2 stacked items treat the top as not player context and the bottom as player context. This one is the weirdest case on this list.
- The crafting grids in the expanded recipe previews for items with many recipes are treated as player context. This is consistent with the behavior for the full size grids, but inconsistent with the other recipe book items and unknown if intended, as these items are intangible.
Crafting Table/Crafter input slots Yes Uncertain1 Crafting Table/Crafter output slots No Yes Seems to be intended as the resolution to MC-186797Missing ingredient recipe displays No Yes Not a tangible item, seems likely to be correct. All Anvil slots Yes Uncertain1 All Brewing Stand slots Yes Uncertain2 Beacon payment slot Yes Uncertain1 Beacon payment example items Yes No Not a tangible item. All Furnace, Blast Furnace, and Smoker slots Yes Uncertain2 All Loom slots Yes Uncertain1 All Smithing Table slots Yes Uncertain1 All Cartography Table slots Yes Uncertain1 All Grindstone slots Yes Uncertain1 Stonecutter Yes Mixed Results The selectable recipes are not tangible items, but the input and output slots should follow note 1. Currently all three considered the player as the context entity type. Items in container blocks, such as Chests, Barrels, and Shulker boxes Yes Uncertain2 Items in the equipment/storage slots of Horses, Mules, Donkeys, and Llamas Yes Uncertain2 Items in the Bundle tooltip/preview Yes Uncertain, likely yes Villager/Wandering Trader trades list No Yes Seems to be intended as the resolution to MC-182888Villager/Wandering Trader input/output slots Yes No Seems to be unintended, MC-186849 is unresolved but confirmed, and relates to MC-182888
1 - Entirely depends on if items placed in GUI slots still considering the player as their context entity is intended behavior.2 - Depends on if storage/container slots are intended to be treated differently from slots in GUIs that don't hold items when closed, unlike the ones covered by note 1.
Attached are screenshots of the cases listed in the chart. The item model being an apple means that it is considered player
held, and the item model being a potato means that it is not. The resource pack used to test this is also attached - various random items were used to test the different cases, so refer to the files at assets/minecraft/items to see which are changed.
When using an item model that changes based off the context_entity_type property checking for a player, the result is very inconsistent between various GUIs and screens in the game that render or hold items. Below is a table documenting the different screens/GUIs, whether or not items within them consider the player as the context entity, whether or not this seems intended or correct, and any additional notes on the behavior.
Screen/GUI Considered as held
by a player?Likely to be correct? Additional notes Toasts No Yes Advancements No Yes Statistics No Yes Seems to be intended as the resolution to MC-8550World Creation No Yes Gamemode Switcher Yes No Seems likely to be incorrect based on the other non-block UI screen behaviors. Not a tangible item. Recipe Book Tabs No Yes Seems to be intended as the resolution to MC-116293Creative Menu tabs Yes No Inconsistent with the recipe book tabs. Seems to be unintended, as MC-182892 is confirmed but unresolved. Recipe Book recipes Sometimes Mixed results
- Recipes with a single item displayed in the slot are not considered as player context. Seems intended as the resolution to
MC-116293- Recipe slots with 2 stacked items treat the top as not player context and the bottom as player context. This one is the weirdest case on this list.
- The crafting grids in the expanded recipe previews for items with many recipes are treated as player context. This is consistent with the behavior for the full size grids, but inconsistent with the other recipe book items and unknown if intended, as these items are intangible.
Crafting Table/Crafter input slots Yes Uncertain1 Crafting Table/Crafter output slots No Yes Seems to be intended as the resolution to MC-186797Missing ingredient recipe displays No Yes Not a tangible item, seems likely to be correct. All Anvil slots Yes Uncertain1 All Brewing Stand slots Yes Uncertain2 Beacon payment slot Yes Uncertain1 Beacon payment example items Yes No Not a tangible item. All Furnace, Blast Furnace, and Smoker slots Yes Uncertain2 All Loom slots Yes Uncertain1 All Smithing Table slots Yes Uncertain1 All Cartography Table slots Yes Uncertain1 All Grindstone slots Yes Uncertain1 Stonecutter Yes Mixed Results The selectable recipes are not tangible items, but the input and output slots should follow note 1. Currently all three considered the player as the context entity type. Items in container blocks, such as Chests, Barrels, and Shulker boxes Yes Uncertain2 Items in the equipment/storage slots of Horses, Mules, Donkeys, and Llamas Yes Uncertain2 Items in the Bundle tooltip/preview Yes Uncertain, likely yes Villager/Wandering Trader trades list No Yes Seems to be intended as the resolution to MC-182888Villager/Wandering Trader input/output slots Yes No Seems to be unintended, MC-186849 is unresolved but confirmed, and relates to MC-182888
1 - Entirely depends on if items placed in GUI slots still considering the player as their context entity is intended behavior.2 - Depends on if storage/container slots are intended to be treated differently from slots in GUIs that don't hold items when closed, unlike the ones covered by note 1.
Attached are screenshots of the cases listed in the chart. The item model being an apple means that it is considered as player context, and the item model being a potato means that it is not. The resource pack used to test this is also attached - various random items were used to test the different cases, so refer to the files at assets/minecraft/items to see which are changed.
I stated the issue was present in Vanilla. It still happens under the same circumstances while using a Vanilla 1.16.2 game profile.
Yes, adding the javaw.exe in the jre-legacy directory does fix this issue. Weird that the directory change isn't mentioned in the launcher patch notes, as it seems like a big enough change that it should be mentioned, seeing as it causes some profiles to break until addressed by the user.
Thanks!
Updated to match the changes in pre1, including a new version of the resource pack. None of the cases listed in the table changed behavior, however the changelog gave clarification on a few of them, so I've linked any relevant reports in the additional notes for the case.