Unlike on <1.19 resourcepacks, negative space/zero-width unicodes fail to load when the font-file has any issues. Be that a texture missing etc. This only seems to affect zero-width unicodes as others load just fine.
As in the image, where player.png is missing, the zero-width is the rectangle, whilst the logo unicodes load just fine. Caused alot of confusion seemingly as this never was the case before 1.19.
Attachments
Comments 20
This happens even with the official 1.19 feature which allows creating custom spaces characters, so this IS A BUG, there is no point into marking that as RESOLVED.
How to reproduce the bug:
This is an example `default.json` file.
`\uE000` has a non existing texture on purpose, to trigger the bug.
The only character which would load fine is `\uE001`, the space characters won't load and will show the placeholder "square character".
File download:
[media]
{
"providers": [
{
"type": "space",
"advances": {
"\uF822": 2,
"\uF823": 3,
"\uF824": 4,
"\uF825": 5,
"\uF826": 6,
"\uF827": 7,
"\uF828": 8,
"\uF829": 16,
"\uF82A": 32,
"\uF82B": 64,
"\uF82C": 128,
"\uF82D": 256,
"\uF82E": 512,
"\uF82F": 1024,
"\uF801": -1,
"\uF802": -2,
"\uF803": -3,
"\uF804": -4,
"\uF805": -5,
"\uF806": -6,
"\uF807": -7,
"\uF808": -8,
"\uF809": -16,
"\uF80A": -32,
"\uF80B": -64,
"\uF80C": -128,
"\uF80D": -256,
"\uF80E": -512,
"\uF80F": -1024
}
},
{"file":"minecraft:item/INVALID_TEXTURE_NAME.png","chars":["\uE000"],"height":9,"ascent":8,"type":"bitmap"},
{"file":"minecraft:item/acacia_door.png","chars":["\uE001"],"height":9,"ascent":8,"type":"bitmap"}
]
}
I totally agree with you, but as you noticed tons of creators don't even understand that a single broken character configuration can cause this mass loading issue, they will then waste others' time asking for a solution.
Does reverting back that code part causes any side effect? Is it why you prefer to keep that change in 1.19.1?
I want to better understand why the change was introduced in the first place.
Thanks for the patience!
Tbf isn't the old way the same as all items and blocks?
If the blockstate or item file has a misconfigured model or texture, only that entry fails?
It just shows the good ol' purle and black cube.
It lets you know exactly what is wrong, rather than needing to check a log as you know what you tried to use.
It was always the same case aswell, if a unicode failed to load you knew where the issue was.
Now you have to do roundabout ways to figure it out instead of just knowing right then and there
The 1.19 Font Bug
we are all a bit confused... because we are in the wild
The Bug Report
The bug report is talking about a problem that has been happening in 1.19 clients:
"Whenever a bitmap character fails to load it causes some other characters to fail to load even if they have a valid configuration."
A lot of modern servers use the texture pack future to make custom ESC screes and make their server look cool...
This is done by changing the default.json file in a texture pack by adding special characters
example:
{
"providers": [
{
"type":"bitmap",
"file": "minecraft:font/title.png",
"height": 192,
"acent": 48,
"chars": [
"\uE000"
]
},
{
"type":"bitmap",
"file": "minecraft:font/info.png",
"height": 192,
"acent": 48,
"chars": [
"\uE001"
]
}
]
}How to make the bug:
Why This Is A Bug?
This bug affects a lot of servers, it's at the top of the r/Mojira, More than 70+ people think that this should be fixed.
Making this "works as intended" is a mistake and should be examined again...
All other versions of the game don't have such a problem with bitmap characters.
*It's only in 1.19+⚠️ *
Most people can't even upgrade because this bug is such a critical part of the game and a huge problem for server owners
From Reddit:
{*}"Yeah, this feature being bugged cause a lot of problems with custom resources, especially a lot of thing being all over the place now.I wait for this bug to be fixed before upgrading to 1.19.x"{*}
{*}"this feature is widely used, even by big servers like OriginRealms.*"
{*}Links:{+}Reddit Post*{+}
So far I have not seen good explanation why do you want game to accept invalid font definition. And by "invalid font definition" I mean "any provider is invalid".
@boq, here is my two cents on a possibly valid use case:
What if my font references a texture that is either (A) from an optional lower pack, or (B) from my pack, but filter-ed out by a higher pack?
In both cases, I would of course expect that provider to stop working, but with this behavior, breaking the entire font seems unavoidable, since the provider was only made "invalid" by the presence or absence of other packs.
For example, I could make a font that assigns every vanilla item texture to a character. But then if someone else's pack filters out even a single one of those, they are all at risk of breaking.
I wonder what you think about this. The optional field for tags solves a similar problem. I guess for now support for cross-pack references of things that may or may not exist isn't well defined, and it's understandable as to why.
@tryashtar
As I said:
I totally agree with you, but as you noticed tons of creators don't even understand that a single broken character configuration can cause this mass loading issue, they will then waste others' time asking for a solution.
Does reverting back that code part causes any side effect? Is it why you prefer to keep that change in 1.19.1?
I want to better understand why the change was introduced in the first place.
Basically whenever a bitmap character fails to load it causes SOME OTHER characters (old tricky "negative spaces" and the new 1.19 "spaces" characters type) to fail to load even if they have a valid configuration. Not every of them, only some apparently random ones.
This is counterintuitive since the log only contains 1 error about them 1 of them and not it's clear why other perfectly configured characters are not loading.
I even provided a step by step instruction on how to reproduce the issue.
Another user even provided the exact line of code to be changed to revert this behavior.
Example
An example to make you better understand:
Imagine if the pack would completely stop loading if A SINGLE TEXTURE/MODEL for blocks is misconfigured.
The whole pack or some other random perfectly configured textures/models won't load at all.
Isn't it extremely annoying? Well yea, it's the same thing about custom textured characters.
I don't see any reason not to revert the change shown in Java by @fox2code some messages ago.
The class to change is net.minecraft.client.gui.font.FontManager a line 81
⚠️ Please do not mark Unreleased Versions as affected. You don't have access to them yet.
-- I am a bot. This action was performed automatically! If you think it was incorrect, please notify us on Discord or Reddit