I believe this is caused by the scrollbar, since the body appears to be centered when including the width of the scrollbar (and space between scrollbar and body). This padding of 10 exists regardless of whether there is a scrollbar.
Even though this was triaged, this sounds intended... The using_item
trigger only works for items where you need to hold the use button (spyglass, crossbow, bow, brush, etc). It has never worked for single click items.
I did some analysis on this. The ResourceLocationPattern
class has a locationPredicate
method, which is a predicate for testing an entire resource location. This is what the filter
font/glyph provider uses for checking sprite resource locations, as intended.
However the ResourceFilterSection
class has isNamespaceFiltered
and isPathFiltered
methods which respectively check if any of the listed blocks match the namespacePredicate
or pathPredicate
predicates. This means essentially that every combination of namespace-path blocks will block resource locations, which is not expected.
The example given by tryashtar is equivalent to specifying the following, in the current implementation:
{
"namespace": "&NONEXISTENT$",
"path": "^recipes/"
},
{
"namespace": "&NONEXISTENT$",
"path": "&NONEXISTENT$"
},
{
"namespace": "^minecraft$",
"path": "&NONEXISTENT$"
},
{
"namespace": "^minecraft$",
"path": "^recipes/"
}
This affects the default
field of both the dye
and firework
tint sources
This is intended. NBT does not have a boolean type, instead numbers are converted to booleans automatically when parsing. This is the same reason why things like `Invulnerable:1b` work.
It makes sense that this would've been fixed in 1.20.5 when they introduced item components
Thank you for your report!
We're tracking this issue in MC-277067, so this ticket is being resolved and linked as a duplicate.
That ticket has already been resolved as Fixed. Please check the Fix Version/s field in that ticket to see in which version this behavior was or will be fixed.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
I believe player markers only show when player B also has a map cloned from the original map in their inventory, and that behavior is working as expected
[media]
This is a regression from 1.21.1 where these loot tables and recipes worked fine.
It should also be noted that using block tags in these components works fine when used in a /give
command or inline loot tables.
Please reopen.
How does this affect vanilla gameplay?
I'm pretty sure this is intended. In vanilla all data components are immutable which means they can be shallowly copied without problems. When modding it is your responsibility to keep the components immutable.
It also appears like the DecorItem
of trader llamas is lost and not upgraded to body_armor_item
The reason is that the ItemAttributeModifiers
component uses Codec.DOUBLE
for amount, while the SetAttributesFunction
uses NumberProviders.CODEC
and then uses amount.getFloat(context)
.
It appears this has been fixed, but because the attached data pack only had an overlay for 1.20.2 (pack format 18), people incorrectly assumed that overlays weren't getting applied. I attached a new data pack for 1.20.4, which can be used to verify the fix.
The registry is still called "minecraft:worldgen/biome", but since a few versions it is not exported from the data generators, but instead it is included in the version jar (just like all other registries that can be inside a data pack). If you extract the jar you can find the biomes in data/minecraft/worldgen/biome
.
It might be a good idea to split up the "command" and "end portal" cases, because they might have different resolutions
Seems like a duplicate of MC-297972