eleazzaar
- eleazzaar
- eleazzaar
- America/Chicago
- Yes
- No
MC-1105
![[Mojang] Jeb (Jens Bergensten)](../../../data/assets/gravatar/jeb.jpeg){kind=small}
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
MCPE-82111![[Mojang] Ulraf](../../../data/avatars/users/43122.png){kind=small}
![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
I've accumulated a couple stacks of coal, raw chicken and wheat at different times to trade with the villagers. Each time the villagers will accept the resource for a while, and then suddenly stop. It still offers the trade in the GUI.
When this first happens, i can shift click on the emeralds, and for a fraction of a second the amount of emeralds in my inventory goes up, then reverts to the earlier value. This situation lasts as long as i am in that screen.
If i leave the villager, (or even quit and restart minecraft), the villager will still list that trade but won't offer emeralds when i provide the requested resource.
I've seen this happen with at least three villagers in the same village.
How to replicate
For me this has happened every time i traded more than a stack or two. I generally shift-click to collect the emeralds if that matters.
I've accumulated a couple stacks of coal, raw chicken and wheat at different times to trade with the villagers. Each time the villagers will accept the resource for a while, and then suddenly stop. It still offers the trade in the GUI.When t
his first happens, i can shiftclickon the emeralds, and for a fraction of a second the amount of emeralds in my inventory goes up, then reverts to the earlier value. This situation lasts as long as i am in that screen.
If i leave the villager, (or even quit and restart minecraft), the villager will still list that trade but won't offer emeralds when i provide the requested resource.I've seen this happen with at least three villagers in the same village.
How to replicate
For me this has happened every time i traded more than a stack or two. I generally shift-click to collect the emeralds if that matters.
EDIT: Due to a texture pack issue i mis-understood the problem. There's still a bug, described in the not-crossed out part below.
When trading large quantities (i've observed this with raw chicken, wheat, and coal), eventually the villager refuses to trade more. If you keep trying to trade, the "rejected X" remains on the trade permanently, and new trading options are not added. This situation persists, even after quitting minecraft and restarting. I have one villager with only one trade offer that permanently is "X"ed.
How to replicate
For me this has happened every time i traded up to the "X" point, and tried to keep trading at least once.
I've accumulated a couple stacks of coal, raw chicken and wheat at different times to trade with the villagers. Each time the villagers will accept the resource for a while, and then suddenly stop. It still offers the trade in the GUI.
When this first happens, i can shift click on the emeralds, and for a fraction of a second the amount of emeralds in my inventory goes up, then reverts to the earlier value. This situation lasts as long as i am in that screen.
If i leave the villager, (or even quit and restart minecraft), the villager will still list that trade but won't offer emeralds when i provide the requested resource.
I've seen this happen with at least three villagers in the same village.
Villagers stop accepting items in the middle of trading. The "dead" trade remains listed but won't work.Disabled Trades options Remain in the Trade GUI, and are not Replaced.
wont trade.png
EDIT: Due to a texture pack issue i mis-understood the problem. There's still a bug, described in the not-crossed out part below.
When trading large quantities (i've observed this with raw chicken, wheat, and coal), eventually the villager refuses to trade more. If you keep trying to trade, the "rejected X" remains on the trade permanently, and new trading options are not added. This situation persists, even after quitting minecraft and restarting. I have one villager with only one trade offer that permanently is "X"ed.
How to replicate
For me this has happened every time i traded up to the "X" point, and tried to keep trading at least once.
I've accumulated a couple stacks of coal, raw chicken and wheat at different times to trade with the villagers. Each time the villagers will accept the resource for a while, and then suddenly stop. It still offers the trade in the GUI.
When this first happens, i can shift click on the emeralds, and for a fraction of a second the amount of emeralds in my inventory goes up, then reverts to the earlier value. This situation lasts as long as i am in that screen.
If i leave the villager, (or even quit and restart minecraft), the villager will still list that trade but won't offer emeralds when i provide the requested resource.
I've seen this happen with at least three villagers in the same village.EDIT: Due to a texture pack issue i mis-understood the problem. There's still a bug, described in the not-crossed out part below.
When trading large quantities (i've observed this with raw chicken, wheat, and coal), eventually the villager refuses to trade more. If you keep trying to trade, the "rejected X" remains on the trade permanently, and new trading options are not added. This situation persists, even after quitting minecraft and restarting. I have one villager with only one trade offer that permanently is "X"ed.
How to replicate
For me this has happened every time i traded up to the "X" point, and tried to keep trading at least once.
I've accumulated a couple stacks of coal, raw chicken and wheat at different times to trade with the villagers. Each time the villagers will accept the resource for a while, and then suddenly stop. It still offers the trade in the GUI.
When this first happens, i can shift click on the emeralds, and for a fraction of a second the amount of emeralds in my inventory goes up, then reverts to the earlier value. This situation lasts as long as i am in that screen.
If i leave the villager, (or even quit and restart minecraft), the villager will still list that trade but won't offer emeralds when i provide the requested resource.
I've seen this happen with at least three villagers in the same village.
Disabled Trades options Remain in the Trade GUI, and are not Replaced-- Even when there are No other Trade Offers.
As the title says. I Don't expect villagers to take shelter from an overcast sky, when they are in the desert, and therefore it isn't actually raining.
Not a huge issue, but worth noting.
Mining smoothstoneOR stonebricks gives you a block that looks like stone bricks, but is labeled "Cobblestone". Silktouchpicks give smoothstoneas expected.Cobblestone and Stone Brick use vanilla Stonebrick texture even when resource pack is selected. My newly converted texture pack seems to work as expected otherwise.
Survival and Creative
Mining smoothstoneOR stonebricks gives you a block that looks like stone bricks, but is labeled "Cobblestone"Cobblestone and Stone Brick use vanilla Stonebrick texture even when resource pack is chosen
Cobblestone and Stone Brick use vanillaStonebrick textureevenwhen resource pack is selected. My newly converted texture pack seems to work as expected otherwise.Survival and Creative
Resource Pack Conversion Bug: Stone Brick texture given to cobble. Stone bricks don't get a texture. My newly converted texture pack seems to work as expected otherwise.
Survival and Creative
Cobblestone and Stone Brick use vanillaStonebrick textureevenwhen resource pack is chosenResource Pack Conversion Bug: Stone Brick texture given to cobble. Stone bricks don't get a texture
"grass.png" and "foliage.png" are powerful tools for texture artists to make the biomes into unique environments. However, the Swamp biome totally ignores these files and uses hardcoded colors, no matter what.
Swamp biome coloring should instead be controlled by the colormaps, like all the other biomes. A fix would be much appreciated."grass.png" and "foliage.png" are powerful tools for texture artists to make the biomes into unique environments. However, the Swamp biome totally ignores these files and uses hardcoded colors, no matter what.
The easiest way to test this is to take those two file (in any texture pack, in: assets/minecraft/textures/colormap/), and make them a solid color like red. You'll see all grass and all oak leaves effected except in swamps.
Swamp biome coloring should instead be controlled by the colormaps, like all the other biomes. A fix would be much appreciated.
Swamp & Mesa Biome Grass Ignores both Colormaps
"grass.png" and "foliage.png" are powerful tools for texture artists to make the biomes into unique environments. However, the Swamp & Mesa biomes totally ignores these files and uses hardcoded colors, no matter what.
The easiest way to test this is to take those two file (in any texture pack, in: assets/minecraft/textures/colormap/), and make them a solid color like red. You'll see all grass and all oak leaves effected except in swamps and mesas. Unless some other of the new biomes have hardcoded values-- haven't checked them all yet.
Swamp biome coloring should instead be controlled by the colormaps, like all the other biomes. A fix would be much appreciated.
"grass.png" and "foliage.png" are powerful tools for texture artists to make the biomes into unique environments. However, the Swamp & Mesa biomes totally ignores these files and uses hardcoded colors, no matter what.
The easiest way to test this is to take those two file (in any texture pack, in: assets/minecraft/textures/colormap/), and make them a solid color like red. You'll see all grass and all oak leaves effected except in swamps and mesas. Unless some other of the new biomes have hardcoded values-- haven't checked them all yet.
Swampbiome coloring should instead be controlled by the colormaps,like all the other biomes. A fix would be much appreciated."grass.png" and "foliage.png" are powerful tools for texture artists to make the biomes into unique environments. However, the Swamp & Mesa biomes totally ignores these files and uses hardcoded colors, no matter what.
The easiest way to test this is to take those two file (in any texture pack, in: assets/minecraft/textures/colormap/), and make them a solid color like red. You'll see all grass and all oak leaves effected except in swamps and mesas. Unless some other of the new biomes have hardcoded values-- haven't checked them all yet.
All biome coloring should instead be controlled by the colormaps, as expected. A fix would be much appreciated.
"grass.png" and "foliage.png" are powerful tools for texture artists to make the biomes into unique environments. However, the Swamp & Mesa biomes totally ignores these files and uses hardcoded colors, no matter what.
The easiest way to test this is to take those two file (in any texture pack, in: assets/minecraft/textures/colormap/), and make them a solid color like red. You'll see all grass and all oak leaves effected except in swamps and mesas. Unless some other of the new biomes have hardcoded values-- haven't checked them all yet.All biome coloring should instead be controlled by the colormaps, as expected. A fix would be much appreciated.
"grass.png" and "foliage.png" are powerful tools for texture artists to make the biomes into unique environments. However, the Swamp & Mesa biomes totally ignores these files and uses hardcoded colors, no matter what.
Additionally the "Roofed Forest" uses the colormaps, but multiples the color by a light green-grey, needlessly providing results that are off from the colormap.
The easiest way to test this is to take those two file (in any texture pack, in: assets/minecraft/textures/colormap/), and make them a solid color like red. You'll see all grass and all oak leaves effected except in swamps and mesas. Unless some other of the new biomes have hardcoded values-- haven't checked them all yet.
All biome coloring should instead be controlled entirely by the colormaps, as expected. A fix would be much appreciated.
3D Mushrooms are rendered very strangely when on Mooshrooms, It looks like the wrong faces are being culled, but i didn't set any faces to be culled on the red mushroom model.
I suspect this reveals some obscure issue with the block model rendering code.
Direct download to my texture pack, if you want to see the scripting:
http://www.jwbjerk.com/lithos/Lithos%20Core.zipEDIT:
Sorry this is a duplicate. I did search first but missed:
https://bugs.mojang.com/browse/MC-50769
I can confirm that in Minecraft 1.4.1pre eggs thrown at a wall will often get a chick stuck in the wall and it quickly suffocates. I didn't count but i'd but it more at 25% to 33% of the time. Doesn't seem to be a unique property of the dirt block.
Under minecraft's video settings, what do you have particles set to?
It has been that way a very long time. I don't consider it a problem
How do you know the babies are doing the killing? Non-hostile mobs don't have the ability to "bash".
Are the drops all near the walls? If so, perhaps overcrowding is forcing some of them into the walls where they suffocate.
Sounds like a zombie villager.
"This is a GUI issue."
Why? Doesn't seem like a GUI issue to me-- or at least not only a GUI issue.
My apologies. I was using an altered texture pack, i though i had everything updated to 1.4.x, but apparently i missed the X.
My understanding was that you could trade as much of an item as you wanted as long as you don't leave the trading screen. I.E. that a trade was only removed once you leave the trading GUI. This is apparently no longer the case.
But there is still the issue that "removed" trades stay in the GUI – even sometimes if there are no other trade options.
I will update my bug report.
"Trades remain because they can come back."
How is that supposed to happen? And what's the point of showing me only some of the possible items that villager X currently won't trade with me.
I have one villager who is only offering me one X-ed out trade. What am i supposed to do get him to update his one invalid offer?
If i trade with villager A, eventually that will unlock a trade with villager B? I've never observed that. As i mentioned, some of my villagers have only a single, locked trade offer.
These kind of minor oddities make exploration more fun and don't hurt anything.
Sounds like you are using a texture pack not updated for 1.4.x
Try explaining that again. This is not at all clear.
I've seen map scaling behave very oddly, though i think it was a few snapshot prior to 1.4.2. I can't/couldn't reproduce.
Can we extend this to all baby creatures?
It looks like all baby animals also used adult sized hitboxes.
Thanks for updating/improving your bug request.
So?
Doesn't the whole piston break?
What do you think should happen?
In my experience villages normally spawn with more population that they have the number of doors to for.
You need approximately three doors for every villagers, when you exceed that number more villagers will breed. With most spawned buildings that's three buildings per villager, a mechanic on some level they didn't think made sense because villagers spawn in larger numbers than that.
Note that you can add multiple doors per building.
It works that way for all blocks. For instance, being next to a sticky piston doesn't prevent a second piston from pushing the block away.
It has happened to me in 1.4.2. I don't remember if the "saving" dialog was shown, but when i reloaded the world, about 30min of building was gone. I have no mods.
You are using Optifine, right? It has a feature that randomly rotates textures.
Glass panes have a similar Z-problem.
Neither would it make sense for some oak-colored boats to drop pale birch planks, and other oak-colored boats to drop red-ish jungle wood, etc.
I don't know why the disappear, but my walled-in golem-guarded village looses villagers from time to time. Most of them are still there when i leave and come back, but sometimes i come back and one is gone. I wonder if they are getting stuck in a wall and suffocating or something.
The same size hit-boxes make it hard to avoid hitting the babies when you are trying to harvest the adults when they are crowded together.
I had a small pen of chickens at my SP snapshot base. Today i went from 13w03a to 13w06a. At the start there were several dozen chickens in the pen. I spent a while mining directly underneath the base and came back to only a few chickens left alive. The remaining ones would walk into the dirt wall and quickly die. This continued until all the chickens were dead. There was nothing else to push them into the walls.
In my case it did not seem to have anything to do with logging or chunk loading. I haven't noticed dramatic fatalities in similarly constructed pig and sheep pens nearby.
Tails: Do you have information indicating that this is how it is supposed to work? There doesn't seem to be anything gained by letting transparent blocks such as torches, levers, pressure plates block the "magic". It confounded me for quite a while, not doubt many players have unwittingly run into this problem.
I can confirm that this issue still exists in 13w06a SSP. For instance i enter an overworld portal facing South, and arrive in the nether facing West. Some journeys leave my character not facing out, but facing the frame of the portal.
The problem is that there is no difference between standing in a portal, which will soon teleport you, and standing in a portal that will not. The effect is the same. The effect going from low levels to high levels of waviness strongly implies that something is powering up and about to happen.
If you come through a portal, and realize you want to go back (due to monsters, wrong destination, forgot something, etc.) and you move away and immediately back there's no way to tell if the portal is actually ramping up to teleport you or not.
Similarly if you don't want to go through a portal, but are sticking close to it for some reason (maybe hiding behind the obsidian from a ghast) you cant' easily tell if you've briefly moved too far away and the portal is actually going to send you somewhere.
To make this clear when arriving through a portal, when it isn't going to send you anywhere, the waving effect could reverse it self (from maximum to minimum) or it could wave at a constant moderate level.
This happens in 13w07a SSP. In previous snapshots i've seen the animal suffocate and die, though several minutes of watching the animal pens in the latest showed the animal popping back out of the blocks after a while. Don't know if the suffocation has been fixed, or if my pens are just not as crowded.
Kumasasa: The minecraft wiki describes the game as it is. That the wiki describes something doesn't seem to me to be great evidence that it was intended, or that all of the implications have been considered by Mojang.
Still exists in 13w09a. Pretty annoying. I tend to shift-click by default since normally it doesn't hurt.
MC 1.5.1:
I've observed Golems ignoring nearer zombies, apparently because they are locked onto a hostile mob outside the village and through an impassable wall.
The "lock" doesn't seem to be permanent, i'm not sure what updates the object of the golem's attention, but the way they ignore zombies in the same room can make them pretty ineffective.
Boat movement is very jerky, and uneven for me with 13w16a. It's like the acceleration is getting nullified after a few tenths to a couple seconds of attempted movement.
Also the boat twitches from side to side.
Nearly unusable.
I'm experiencing this in survival 13w16a.
EDIT: also the boat left behind is non-interactive and can't be bumped.
Works fine for me on my recently upgraded OS X 10.8.3
It's not the level bar. It is the horse's jump power bar. Hold the jump button and see it change.
You realize that different horses have different health?
You realize that they presumably won't appear in territory you've been over before?
Granted searched for a quite a while and didn't find any in a new world – but for a time much less than 3 hours. The wiki says they appear near villages.
Launcher 0.2 still works for me in OS X 10.8.3.
>The wiki ("horse" article) doesn't say anything about their spawning conditions at all.
It did. The article is in flux so soon after release, but i make no claims that it was right.
That horses don't spawn yet is the kind of info I'd like to see in Mojang's change log.
I'm speaking of the texture pack format. Pre 1.5 texture packs won't load-- just like they won't load in 1.5.x. You can convert any old pack to the 1.5+ format. How old the art is in the pack is irrelevant.
Glowstone is a "transparent" block. That means the brighter light of the sun is supposed to be able to pass through it.
Your description is confusing, i don't know if this info makes what you observe make sense.
Leashes snap only when you move too far or too fast. They do pull mobs. It is useful sometimes to pull them up. I don't see why it is unbelievable that such was intended
Sounds like an improvement to me, not a bug.
Tobias: I think Cube is agreeing with you, not Nobel.
I've read comments that other textures are mixed up, but specifics weren't given.
Dylan: You can manually add or rename missing/messed up files if you don't want to wait for Mojang to fix the conversion tool:
They are now sensibly named: "cobblestone.png" and "stonebrick.png"
OK, my comment at the top is wrong, at least in the latest snapshot, sunlight cannot travel through glowstone.
I still don't understand what the problem is that you are trying to describe.
My bad. You used to be able to eat even when you weren't hungry-- at least food items. I hadn't realized it changed, and assumed it applied to cake too.
I can eat cake when hungry.
I haven't seen this happen in a long time.
Do you guys realize that (at least in my testing) HD fonts work perfectly well, as long as the game doesn't try to start up with them?
It seems that the interface only goes berserk if the Resource Pack that the game loads up with (i.e the last Pack you used before you quite MC) has an HD font. It seems to work find if you select a pack with an HD font after you launch MC-- and will work fine next time as long as you switch to a non-HD font pack before you quit.
Perhaps the quick fix would be to use the default font when MC launches no matter what pack is selected.
HD fonts still are broken for me, but they are broken differently. Now they are always broken, and the spacing is different.
Is there some sort of .mcmeta file needed to make this work?
EDIT: this is in reference to the 1.6.2 snapshot
Grum:
certainly, here it is:
http://www.mediafire.com/download/wuy1z6ub3yibh1f/lithos_font_issues.zip
and thanks...
OK, i guess i'm going to risk a dev glare.
I've tried multiple methods, any one of which should have removed non-zero transparency values. The font still goes glitchy in the same way. To the best of my knowledge it mets the other requirements.
http://www.mediafire.com/download/e7o0l39skqf3uxx/ascii.png
Grum: Gotcha, thanks, that works.
OK, it's nice to have a fix, but making a fix that only works when your nether hasn't been loaded into 1.6.1 still torpedoes a lot of player's big nether builds, like for instance mine.
So what are these changes to the fortress bounding boxes, and where are they saved? With access to some backed up worlds and moderate skill in MC edit, how can i get the nether bounding boxes back where they used to be, without simply reverting to a map state from months ago? Nether Chests and thus broken fortress mobs were added in the middle of April.
What about nether fortress mobs? Are wither skeleton grinders broken again?
"Roofed forest."
You'll notice that in savannas the trees are built of jungle logs and birch leaves (IIRC). They seem to be mixing and matching on purpose.
The names should probably be made less specific if that's what they are going to do: "Dark Wood", instead of "Spruce Wood".
Different flowers spawn in different biomes i believe.
This is arguably desirable in the foliage colormap.
> It also happens with Swamps' water color; I turned water_still.png solid white to test it and it appears obvious they're overlaying a light green color on top of it instead of editing the colormap itself.
Vanilla has no water colormap. Of course it would be preferable if it did. But that's no so much a bug.
This is an important point:
My understanding is this fix will preserve structures that work in 1.6.x in the transition to 1.7 snapshots – if you visit them in 1.6.3.
It doesn't fix structures that were broken in the transition between 1.5.x and 1.6.x.
Correct?
Kabo: "this is extremely easy and I've already given an explanation on how to understand the structure data in a video"
Here is is: http://www.youtube.com/watch?v=l_fsxwrPy34
This bugs me. I keep thinking that night is starting to fall when i happen to walk under some shade.
I like it this way better. Not a bug-- it's a good feature.
A screenshot at night is a really bad way to explain.
The old behavior in caves may have been unrealistic – but it was useful. It gave you a glimpse of what waited beyond in the dark. It is a lot easier to accept odd and unrealistic things in a game when they are advantageous.
I'd rather have:
unrealistic, but useful fog in caves, and realistic fog outside, than
realistic fog in caves, and unrealistic fog outside.
There are simply more plusses to the old way.
Now if they could make the fog realistic in both contexts, that would be even better IMHO, but i don't think that would be easy.
As of 13w42a stained glass seems to have the same back face culling behavior as clear glass. However, clear glass still doesn't allow semi-transparency.
This issue is still present in snapshot 13w42a for both regular and stained glass
It has to do with the level of opacity. In my texture pack, stained glass is everywhere above 50% opacity, and is rendered when an item as completely opaque.
confirmed again for 1.7.2
NOT Resolved.
Boats still break on lilies and other silly things (like chickens) in 1.7.2.
The seed is "Temple", and the coords are approximately x -60, z 600.
But my "Temple" started in 1.5 or before and therefore is different. Creating a new world in 1.7 of that name and traveling to those coords does not provoke a crash. I just tried it.
I did get a third crash in a copy of my world-- this time flying in creative, so i guess it has nothing to do with boats.
Mine got marked as a duplicate of this. I think some of the info may be relevant so i'll copy it:
I pruned my 1.6.x world with MCedit, and opened up 1.7.2 to explore and see the new stuff. When drawing near the edge of previously generated chunks, the game crashed. When restarted, Minecraft immediately crashed after loading that world. I restored the world from a backup, and got a similar crash and corruption when exploring the same area.
I restored from backup again and when exploring in a different direction, i generated hundreds of new 1.7.2 chunks with the new biomes before encountering a crash and corruption in a different location.
The seed is "Temple", and the coords are approximately x -60, z 600.
But my "Temple" started in 1.5 or before and therefore is different. Creating a new world in 1.7 of that name and traveling to those coords does not provoke a crash. I just tried it.
I did get a third crash in a copy of my world-- this time flying high in creative, so Y does not seem to be relevant to the crash..
huh. There must be something more specific wrong at my end.
It was an MCPatcher Bug. I'll make sure i get the bug in a totally vanilla environment next time.
It seems the likelihood of wrecking the boat has to do with the speed. My boat seems to survive most very slow collisions.
The issue is unchanged.
Do they realize this very easily causes a situation where a clearly visible zombie is riding an invisible chicken?
I have seen no announcements that the texture pack format is supposed to change. My understanding was the big resource pack changes from 1.5.x to 1.6.x were supposed to produce a format where packs could be forwards and backwards compatible thereafter. And that has been the case, except for the instance in this report.
Thus i doubt it was their intention to break compatibility between 1.7 and 1.8 resource packs – it was probably an accident. Pointing out that Mojang has accidentally broken something is, i believe, very much on topic for this site.
I assumed there could be useful info in the gobbledegook. If they don't want everyone reported it the readout should have a more qualified statement than:
"Report this to http://bugs.mojang.com please!"
I know about duplicates and searching. But i figured explicit instructions in the crash report overrode that standard behavior.
I'm getting similar results.
On fast graphics:
The opaque version of the leaf blocks has been removed in this release. I don't know if that was a mistake, but it was unfortunate. Choosing the "fill" color of opaque leaf blocks is an important way texture artist make fast graphics less noticeable.
Not fixed in 14w25b.
Also have the crosshair issue in snapshot b with my resource pack – only when stuff is in the inventory bar.
For what is is worth, this bug effects such popular resource packs as: Sixty Gig, Chroma Hills, Sortex Fanver, Good Morning Craft, and Frehdens' Meringued, as well as my own Lithos:Core.
For those who claim this is a case of artists making their pack "wrong", please explain what we did wrong and how to fix it.
Carl and Brad: Your guesses do not explain the glitches i'm seeing. Opaque in the foreground, transparent in the distance.
This screenshot was taken with only the default texture pack and with mipmapping off. No vines are in the picture. Again 14w25b.
I can confirm that the fix Carl suggested almost worked. 1% opacity wasn't enough to show up, but 10% did work. But that only fixed the appearance of the leaves the engine chose to show as opaque. Distant transparent leaves on fast are still there.
As Sphax says, every single entity, except banners works perfectly fine in HD.
Additionally banners almost work in HD. The only issue with my HD banner textures is that the base color of the banner gets turned to white.
The original poster's problem is probably that he forgot to change banner_base.png. If that is a different res than the patterns the patterns don't show up.
Image Attached: Some "disallowed" HD banners. The only glitch is that the background isn't supposed to be white.
Maybe i'm missing something technical, but it looks like you have full entity HD support 99%+ complete.
Sphax:
Good catch! I missed resizing "base.png". Once i resized that everything worked fine in HD.
See image "banners2"
"What is the fix for this when it only happens in certain resource packs? How exactly should the resource pack be fixed?"
All the files in the resource pack must be the same resolution, including banner_base.png which is not inside the banner folder. If not you'll get some or all of the banner looking white no matter what color it is dyed.
I believe i'm seeing this same error. Custom models that worked fine in 1.8 (which doesn't specify all UV coordinates) have textures that have aligned differently in the snapshot.
Confirmed in 15w37a.
It is fairly annoying. We can turn the shading to "false", but that has a miniscule effect compared to this lighting glitch.
OK, nevermind. I expected the standard 1= true, 0= false.
Note that because "Programmer Art" is basically the 1.13 art, this means it is impossible to build a texture pack that works correctly for 1.13 and 1.14.
For example in 1.13 zombie_villager.png has an area used for the arms and hands, where 1.14 looks for the hat.
Unless this is somehow fixed, 1.13 and 1.14 are really not using the same texture pack format.
Brenden Scott Hand is correct.
It's not just chest plates. If you use the "sleeve" area of the the texture (same location as any other player-shaped mob-- including player skins), the sleeve animates properly with the arm, except when doing the "staring at gold" animation.
This bug still exists in at least the Windows 10 v1.16.20. The left leg (the one on our right as we look at the front of the mob) is still wrongly mirrored.
It should look like this:
The above skin is from the marketplace pack: Lithos Monstrous Mobs
This skin should make the issue abundantly obvious. There should be unbroken blue and purple stripes from head to toe-- as in this block bench screenshot.
If the blue and purple switch sides on the leg, then the model is still wrong.
@Orbic
Each leg has a unique texture.
Both horns use the same UVs and are not mirrored.
Arguably they should be, but it is less of a problem that the non-mirrored ears.
It does not.
Except in the vague, general way that both involve UVs.