LoneDev
Assigned
Reported
Comments
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!
> why can't you just fix broken texture?
Yes I too agree that people must fix the broken character configuration, but the issue is that they are confused about why other characters fail to load if a single character fails to load.
That's what caused confusion among some resourcepack artists.
For example other blockstates won't fail to load if a single blockstate is misconfigured.
I think there is a lot of confusion here because too many people contributed to the discussion.
The reported problem is the following:
Whenever a bitmap character fails to load it causes some other characters to fail to load even if they have a valid configuration.
I highly doubt this is an intuitive behaviour.
Only the misconfigured character should not load, do you agree?
I provided an example which can be easily reproducible hoping that this would help you understanding why this behaviour should be considered a bug not a feature:
https://bugs.mojang.com/browse/MC-253169?focusedCommentId=1176073&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-1176073
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"}
]
}
This bug has nothing to do with amount of recipes.
32994 recipes is a non-realistic value.
Although you can trigger this issue by creating recipes which use items with a lot of NBT data (lore, displayname etc).
Even 500 recipes can trigger this issue if the items satisfy my previous statement.
This is totally still an issue and I find no reason to close this as "resolved".
Please allow us to change the GUI size, this game gives me headache while playing because of the too big GUI.
A solution would be to split the packet sending in parts or just increse the max allowed packet size
Same issue on 1.15.2
I'm sure the reason why they don't want us to decide if a block or a single model can have the isOpaque = false flag is:
They don't want to get hundred of support requests about how Minecraft is laggy because 100% of the times will be caused by a resourcepack changing too many blocks to isOpaque = false.
This property is resource intensive if too many blocks are on screen. Imagine if grass, stone and others are changed to isOpaque = false. All their faces must be rendered.
Maybe I'm wrong, but that's the only reason I can think of, other than they're lazy.
Seems to be a bug of LWJGL and TrueType fonts.
Sadly game will crash with any loaded TrueType font.
I hope you'll address this issue as it should be fixable on your end
@miwob
Are you sure it's a duplicate?
Game is working fine until characters in the default.json file of my resourcepack are loaded on screen (chat/actionbar).
Still in 1.15.1 Release
Seems to work fine on 1.15.1
you surely are using a custom resourcepack as the normal smithing table has no 3D depth.. it's a normal block.
@tryashtar
As I said:
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.