Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Issue] Textures reset to default naming when loading a model #261

Closed
Luke18033 opened this Issue Mar 9, 2019 · 1 comment

Comments

Projects
None yet
2 participants
@Luke18033
Copy link

Luke18033 commented Mar 9, 2019

While editing my resource pack recently I discovered that I was using a very old version of Blockbench (1.11.x if not earlier). After updating to the latest version, textures will no longer load properly when opening most models. Specifically...

  • All textures on the model will be replaced by the default multicolored missing texture
  • The textures will still appear on the left panel, but all of the variables will be reset to the default numbering instead of what is set in the model file
  • Upon saving the model, the textures block will be removed entirely and all of the texture variables on the model will be set to #missing

This affects all models which don't use the default texture naming scheme (a.k.a pretty much every model). This seems to affect both the desktop app and the web app, though I wasn't able to fully test the latter. Operating system is Windows 10. Nothing unusual appeared in the console.

Aslo, changing the names of missing textures to #missing just seems like bad design. There are so many cases when a texture might be "missing" as far as Blockbench is concerned but appear fine in-game. What if the model is used as a parent? What if the texture is from another resource pack? The older version of Blockbench I was using prior to installing the update didn't do this, and I cannot figure out why you would decide to implement this "feature".

For reference, here is a model before opening it in Blockbench and here is the same model after. The fact that such a major bug hasn't been reported yet makes me think that either something's wrong on my end, or it has been reported and I just didn't see the issue.

@JannisX11 JannisX11 added this to Fixed/Added in Upcoming Version in Blockbench Mar 11, 2019

@JannisX11

This comment has been minimized.

Copy link
Owner

JannisX11 commented Mar 11, 2019

Fixed in 2.5.1.

@JannisX11 JannisX11 closed this Mar 11, 2019

@JannisX11 JannisX11 removed this from Fixed/Added in Upcoming Version in Blockbench Mar 11, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.