When using resource packs: Redstone dust line is rotated the wrong way when connected to another

Sage Stevenson, That's MC-53460

this has GOTTA be a bug. y would mojang just rotate the redstone texture by 90 degrees for no goddarn reason?!?

Your resource pack is outdated, complain to the makers of the resource pack.

Same bug on Windows 7 64 bits.

This can be easily fixed by changing the new model to rotate the texture 90 degrees so you don't need to change the texture, in fact an MCF member made a fix here: http://www.minecraftforum.net/topic/1650340-latest-changes/page__st__140#entry30840023

So why would they break compatibility on every single resource pack out there with redstone, when all they had to do was rotate the texture in the mesh file instead of rotating the actual texture?

Seems funny that all of a sudden, all the redstone would change like this. It is not just his resource pack, to call it invalid is like saying we changed something and don't want to admit to it. Sorry Mojang, but this is true across multiple resource packs, how much of a difference really did changing the rotation of the image make. Seems silly.

Yeah, they did, and rather than correcting it, they said that is the way it is supposed to be. So every single resource pack broke because of it. And I guess it is easier to change every single resource pack rather than changing one line of code.

It "seems silly," but it could easily have affected far more than 1 line of code.
I think it probably has to do with the implementation of block models, though I may be wrong. In addition, there is the bug page RIGHT HERE, so it is considered a bug and they probably they intend to fix it.

I guess you are right, it could be a lot more code, but in aall seriousness, it can not be that much to make one texture read as one direction compared to the other. And, it is not listed as a bug. Based on this page RIGHT HERE as you put it, this page is marked as invalid meaning thay are not pursuing it at all. They do not consider it a bug are therefore all resource packs are required to conform.

You can temporary fix this issue by extracting the redstone textures from the 14w17a or 14w18a.jar located in the .minecraft/versions folder, I did it myself because I can't stand to play with 16x default textures, I love the Faithful32x a lot more, I simply copied the redstone textures for the line and cross + the overlay of the .jar and it works #1

Just to be clear, it will never ever be fixed, its the new way the blocks and items are coded and it won't change anytime soon for really good reasons, so don't expect mojang to correct this, the work must be done by the ressource pack teams instead.

And for Lukas Fischer, the link is to a picture, not a website, can't understand why I can't link to pictures here.

This is what files you need to copy to any ressource pack/Texture pack to fix this issue, it will get you the default textures for the redstone, but at least it works with any texture pack you may have at the moment.

McDodge34, this breaking was either an intentional decision or thoughtless oversight (or a mixture of both?), there is NOTHING in the new model system preventing them from fixing this, all they would have to do is use the texture as before and rotate the UV mapping for the needed usages in the model files instead of using a rotated image.

As it's just a rotation issue in the model files, you can fix it in there instead, which also does not screw up 1.7 compatibility like rotating the texture itself would. Alternatively, you can use this (either pack-stacking or adding it manually):

http://www.minecraftforum.net/topic/1650340-latest-changes/page__st__160#entry30959159

To fix it via the model files. You can also just make 3D redstone wire models and circumvent the issue entirely. But telling people to just "rotate the texture" is bad advice considering 1.7.9 is stable right now, so you'd end up breaking redstone for most of your users to fix redstone in a version that's not likely to become stable any time soon (and even less sooner will people actually start USING said stable version). The fix is a small (albeit technical one) that allows for compatibility in BOTH versions, so I'm not sure why people wouldn't choose this option.

EDIT: Also, your fix is wrong. You're telling them to copy the default files into their pack, which is unnecessary because to have the game use default files all you need is to have missing assets. Deleting those files in the chosen resource pack would have the same effect.

This bug shows as resolved. it is not for me. I have 14w19A and the redsatone dust is rotated incorrectly still. Always north/south. No one else is having this anymore?

@Adam It's resolved as "invalid" not "fixed"

Sage don't remove the moderator edits, they'll be mad D:

Note to creator: This is a warning, please don't remove the moderator note, otherwise we'll change the Reporter in order to prevent such steps on your side,

I don't think they want you to make changes to the moderator edit either...

I won't remove the moderator edit, but I won't change to the default resource pack because I don't like its pixelated graphics. (looks very ugly)

Vattic WILL update the faithful32 resource pack; I just know it! 😃

I'm pretty sure changing moderator edits is a bad way/place to tell your opinions. Correct me if I'm wrong.

Last Warning, the "do not remove" also includes "do not edit" - It's a moderator note.

@unknown, the moderator edit is for other people with the same issue, not for you, as you already know that the resource pack causes that issue.

Don't add Future Versions to the Affected Version list. In fact, please don't add any additional Versions. This is marked as ""Invalid", nothing will change at this point.

@unknown, you have been warned.

This bug affects 14w17a, 14w18b, 14w19a, 14w21b, and 14w25b.

Because it's not a bug. It's simply the way the game works now. The reporter was changed to prevent you from editing ticket, because you were warned several times and did not stop.

Bending over backwards to maintain backwards compatibility makes the code more complicated, and increases the risk of introducing bugs in the future. It's better to write code that is clean and makes sense just by looking at it, instead of inserting special cases and trying to remember odd behavior and why it was put there in the first place. Consistency is good. While this may be a harder transition for people already invested in certain resource packs, it's not hard to fix the pack, and will make things easier for both the developers and pack creators in the future.

Torabi, this isn't a problem in the code, nor would Mojang had to "bend over backwards" to prevent/fix it. It's a simple line of adding "rotation":90 to the model files, which would have been a 1-time thing that would have stopped all this 75+ bug reports and compatibility madness.

So code-complication and consistency isn't an issue here, won't make things easier either. It was just a dunderhead decision where somebody decided to "cut corners", or didn't take the time to think of what their actions would cause.

Meanwhile it can be fixed without changing the texture just by fixing the model files to be how they should be. There's a link in the comments above where someone has done this to put in your "pack-stack" to allow all resource packs to have this fix without breaking 1.7 compatibility.

And yet it would be something different from the other model files that they'd have to remember why it was there, and possibly accidentally break in the future. Special cases just for the sake of maintaining consistency with an older version complicates any project, and while individually they may not seem like they'd cause any problems, the more of them there are, the harder it becomes to change or fix anything, because it causes a cascading effect where you either have to create another special case, or update an existing special case, in order to avoid breaking them. And that, in turn, can necessitate adding or updating another special case, and so on.

Putting a rotation tag in the model files might be confusing to anyone creating a new resource pack, because they probably wouldn't be aware of the history or the change. It would be an additional thing for someone to accidentally leave out or mess up, because it wouldn't be obvious why it was there. If it had always been that way, wouldn't there be people asking why they didn't just make the texture and the model in the same direction in the first place, rather than tweaking it with a rotation in the definition file?

I don't know why they created the model so that it would be oriented differently than the old texture. It's possible that they didn't have to, but I doubt they would have done it that way without a good reason. It's not like they wanted to break existing resource packs, and they certainly must have known that it would do so, because they had to update the default.

Required compatibility changes are one thing, unneeded or hasty changes that break things for little-to-no-reason are another. For instance, the 1.6-1.7 changes was justified, and the resource pack format has clear and awesome benefits, ones that artists who make them can actually SEE. (however, the 1.5-1.6 format was short lived meaning somebody should've thought about it a bit more before releasing it and then deciding there was more to be done).

As for what you said: This is a one-time thing. They should never need to change the model files in a way that would break compatibility. Updating the new model files to new specification can easily be done on a per-file basis, so carrying over a rotation value should be easy should it change. So, there should NEVER be any issue as you're saying, it should be set-it-and-forget-it.

As for creating a resource pack? It's not confusing for resource pack artists. Most resource pack creators aren't going to be messing with the model files at all. The ones that do need to know how to do it anyways, and it's fairly complicated, so chances are that anyone attempting would either know how it works or have a guide. So really? This causes more confusion because this new rotation affects more resource pack makers/users who use redstone at all compared to this imaginary user you've thought up who specifically knows nothing about the modelling format yet wants to change the redstone model for some reason.

Likely, they had a different starting orientation. You could make a 2D restone that didn't require the file rotated just by making the "parent" model EW instead of NS.

EDIT: The reason this is even an issue isn't because this is a compatibility issue, but because it's in a snapshot that is likely far from a release, so a standard "fix" as many are recommending (just by rotating the file) breaks 1.7 (which most users are on) compatibility. This change comes out of nowhere, and leaves "no good solution" for those who don't know enough about the model format that it can be fixed that way instead of through the texture. So really it ends up looking like "we broke this because you don't matter" considering most users don't know why they rotated the texture, and the ones that do know why know they didn't need to rotate it.

Is the new orientation actually worse, or more effort, in any way other than because it is different from how it used to be? This will only affect older packs, in much the same way as the transition from texture packs to resource packs. Anyone making a new pack will have no idea that the texture was ever a different direction. No one making a new model will know either. In this respect, it's the cleanest way to go forward, because it does not burden new users with learning the history of a feature in order to use it. Putting a rotation in the model definition would affect anyone who wanted to edit the model, or make a new one. Its purpose would not be obvious without knowing that it was there for backwards compatibility.

Once again, there's not enough information to determine why they built the model in a different orientation than the old texture, and whether or not there was a compelling reason to do so.

Again, this is a very edge-case argument you're using. Someone who wants to make their own redstone model should know how the model format works in the first place, including rotation. So they look at the file, and see that the texture use is rotated, bam, done. If they don't know, they'll have to search or ask, and if they can't find out why this simple thing is I might wonder how they're making a resource pack at all, or using a computer for that matter.

The problem here is that the only "clean fix" is to fix it with model files, which most resource pack creators know nothing about, so they either will have to break it for 1.7 or leave it broken until 1.8 is officially released, or release a different version with the fix which most users won't bother to even download.

And it won't only affect older packs, it will affect about 90% of packs, considering most packs don't add snapshot support, even current ones, and then the ones that do likely doesn't even use the custom model feature, so the fix will also be a break for 1.7 (as said above) or a wha? considering most users won't know of a separate fix.

No, it's not easier or harder either way. It's different, and it doesn't need to be. It complicates things, and no, it's not the "cleanest way to go forwards" because all it's doing is adding is entropy to the resource pack as a whole considering 1.7+ is seen as a "stable" format where packs should work for. There are also in-file comments where if it's that much of an issue they could put "__comment": "rotation for backwards compatibility", and now it's A-ok.

@unknown, pain before gain. If change is never made, the reason being to satisfy all the users, then progress cannot be made.

If Mojang listens to all requests, they'll never get anything done. It's that simple.

Ezekiel, but there is no real gain here. If they had just rotated how the old texture was used, it would not have been that much work (less than 2 minutes when they were making the redstone model files) and after that it really wouldn't matter to Mojang.

I'm not saying they should stop changing things, but changes that ruin compatibility and seem unnecessary are quite annoying, like when they changed allitems.png (which was the old creative menu) to inventory tabs, despite that not making sense, when all they needed to do was change the name (which they have now).

Some compatibility issues are fine, like the enchantment table slots, because at least they are a different functionality (only slightly different from the old one), and seem justified because they can't be avoided without Mojang "jumping out of the way" to do it.

However, this is just for initial ease for creation of some of the model files, which is not justified.

Models are a pretty significant change internally, and it took a lot of work to create something that will mostly look the same to the average user. And they're not done working on the model format either. There will be other changes to resource packs by the time 1.8 is released. The way textures are assigned to a model is changing significantly, so this won't be the only thing pack creators are going to have to update their packs to fix.

Because they have so many changes planned, compatibility was not a priority. It may not be as hard a transition as when texture packs were replaced with resource packs, but it's still a significant overhaul, and is intended to be a clean break from the old system. This one texture being rotated a different direction is pretty minor in the grand scheme of things. It's unfortunate that it's caused so much confusion, but this is a snapshot: changes should be expected, and most users shouldn't be affected.

Torabi, considering this is not a model format compatibility issue, but a texture issue, and that it is a 1.7(stable)-->1.8(snapshot) change, most users WILL be affected until 1.8 has been stable for a significant amount of time. I think 75+ dupe reports is proof of that, and just think of how many more there will be when 1.8 hits stable..... it'll likely be another MC-37106 fiasco.

Sure, "in the grand scheme of things" this isn't important, but there's nothing "in the grand scheme of things" that really justifies it, either.

Most users are not, and should not, be using the snapshots, and thus will not be affected during this transitory phase in which most resource packs are not updated. Snapshots are experimental versions released to the public for testing, and as a preview of what may be in the next release. They are not intended for normal or widespread use, but for advanced players who would like to be involved in the testing process.

When 1.8 is released, existing resource packs will not work without being updated, and so users should not experience this particular issue – either the pack will not work at all, or it will have been updated, and the pack creator should have already corrected this. If users experience this at that point, it will be because the pack creator did not update their pack correctly or completely. MC-37106 was such a major issue because it was introduced in a release, and not a snapshot, and thus users were not given the opportunity to test it. By the time 1.8 is released, resource pack creators should be well aware of what changes they need to make for their packs to be compatible.

As a final note, Mojang doesn't need to justify any of their changes to you, and neither do I. I've spent far more time and effort attempting to do so than is reasonable. You're the only one making a fuss about this on this ticket, or any of the duplicates. Everyone else seems perfectly willing to adapt.

You're right, but that's a double edged sword, considering most resource pack makers probably don't use snapshots, either, meaning most packs won't be fixed until 1.8 has been out for a while.

"When 1.8 is released, existing resource packs will not work ...at all"

What? Where did you hear that? That's completely wrong. 1.7 and 1.8 use the same pack format. A pack made for 1.7.2 will work in 1.8. That's the problem here, because the texture file is used by both versions, and 1.8 isn't stable yet.

Yes, "Mojang don't need NO MAN!". But unjustified changes make them look bad, specifically when people ask why an issue occurs. If someone has 25+ packs they used in 1.5 and they don't work anymore, at least newer packs are better because of it. Breaking something "because it made it a little easier to make the files" is not a good reason, especially considering it's a one-time thing.

You're right, I'm the only one "making a fuss" about it, because I actually USE the modelling format and know WHY they did what they did, and realize the impact that it will have. However, I think you don't get my intentions here, specifically the "adapt" comment, considering as I have stated previously, I've already fixed the issue at hand with my own custom redstone model that uses the texture how it's placed in 1.7. So I've already "adapted" in a clean way, but the problem is that I've made a tutorial on the subject of model files, so other pack makers will likely be content screwing up compatibility when it's possible to make small modifications to the redstone model files (or make them in a certain way) to preserve compatibility. Many likely won't even know that there is an alternative to rotating the texture!

The reason I'm commenting is because of the mods here having such a lax "carry on, it doesn't matter" attitude. Yes, I get it, you don't want a fuss. But it's perfectly clear from mods' arguments here that you don't know what you're talking about on the issue. I don't blame you for wanting to "defend" Mojang, but this is a fairly technical subject that I don't think anyone should try to argue on if they aren't familiar with it.

So what's my whole point? This is a bigger issue than you mods are making it out to be, for little reason. Think about all of the entropy involved here:

• fixing requires either knowledge of the model format, or breaking compatibility with 1.7

• the "easy" fix requires breaking compatibility now or waiting until 1.8 is released

  • waiting increases entropy because the maker must remember to include the fix

• the user must then update to have the fixed file

  • many users cannot be bothered to update installed resource packs

• many users and servers rely on mods/plugins which rely on tools/APIs that need to be updated

  • as a result, many users are likely still using 1.7.2 or even 1.6.4

  • this will create more of an issue when users download a pack for 1.8 unknowingly but use an earlier version, causing this same issue in an earlier version

This is worse than MC-37106, as there is more entropy. For that, old version = bug, update to fix. For this, a mismatch of MC and pack version results in the "bug". I wouldn't be surprised is this issue is dup'ed 3 fold of 37106 is. And all because of taking a shortcut to save less than a lunch-break's worth of time. If someone is worried about that much time, they're either working themselves to death or are preparing for a Swedish holiday.

I've been playing with broken redstone textures for weeks, it doesn't bother me.

For what it is worth, I agree with "Imsomniac_lemon". This issue is not getting the proper attention it should and the mods on this forum are somewhat to blame. Mojang are people too and can will make mistakes or do things without thinking of the bigger picture. A little change for convenience sake or any other small reason that long term will cause hundreds of resource packs to break when 1.8 comes out is not seeing the big picture. And it is the "job" of this forum and the moderators in it to at the least point it out. This "bug" is getting downgraded and deemed not an MC issue so much by the mods that Mojang may not realize that they should re-consider their decision here. In my opinion this needs to be classified as a BUG with no resolution. Until a Mojang DEV comments on why it was done and explains how to mitigate its impact, it needs more attention.

Resource packs for 1.7 currently work in the snapshots. However, I was told by @unknown that they have plans for further changes to resource packs between now and the release of 1.8 that will break compatibility and necessitate updating them. This isn't change just for the sake of change, there will be added value, similar to the transition from texture packs to resource packs. I realize that it's not present in the snapshots yet, and thus you're not in a position where you can see the benefit.

I may not know as much about the model format as you do – I didn't bother researching it, because I knew it was going to change – but that doesn't mean I don't understand the issue. The texture wasn't rotated to "save less than a lunch-break's worth of time". It was done because it made more sense to the person making the model, and maintaining compatibility with 1.7 was not important because the pack format is going to change anyway. Yes, the could have done it differently. But it wouldn't have been worth it in the long run. When you're building something that you have to maintain and update for a long time, it's important that it makes sense to you. The harder it is to keep it in your head and understand it, the more likely you'll make mistakes when you edit it in the future. It's better to break compatibility now, when they're making large changes to the format that break compatibility anyway, rather than later, possibly by accident.

Altering the model just to avoid rotating the texture is just going to cause more conflicts, because everyone else is just going to rotate the texture. What you're suggesting isn't the "clean" way – it's encumbered with the history of the format. It's a decision that won't make any sense out of the context of that history. Why have the texture facing a different direction than the model, and have to rotate it in the model? The only reason to do so would be for backwards compatibility, which won't make any sense a version or two down the road. You're trying to save resource pack creators from a one time change, at the cost of making development slightly more difficult for Mojang in the future. You seem to be assuming that they'll never touch the models or textures again, which, considering the past, doesn't seem like a safe bet.

I'm not here to defend Mojang. I'm here to be an advocate for sense. Some of my comments across the tracker have been critical of their decisions, but I've remained polite in expressing them, and respected their right to make decisions about their product. I'm here to help make Minecraft better, by helping organize and maintain tickets, and communicating between the developers and the users. They're fully aware that this ticket exists – several of us moderators have brought it to their attention, and asked for them to comment. They gave us their reasons, but did not wish to waste the time arguing about it. I've attempted to pass that information on for your benefit, but as predicted, you do want to argue about it. They've made the decision they thought would be best in the long run, and felt that having to rotate a single texture was a reasonable cost. Bigger changes are still coming, but their benefits should be far more obvious.

It's not just that I can't see the benefit, but that is literally the first time I'm hearing anything about these "plans". You're also not part of Mojang (that I know of) so I can't just take your word for it that "Mog told you they have plans". Also, what does "plans" even mean? Mog also announced changes to the pack format that he made sound like they were going to be in the next snapshot at the time, and a month later these changes still aren't implemented. How do I know "plans" wasn't just Mog and Grum briefly discussing the idea? How do I know you haven't misunderstood what Mog was saying for the changes in the model format which will require all models in resource packs to be redone?

I still feel that actually developing a resource pack, specifically models, is very important to this conversation. Without knowledge of it and making a decision on it is a bit like what the US congress does. Also, you're recycling your arguments now, most of which I've already addressed.

Mostly: What is so confusing about a rotation? Look at the model file, look at the image file, if you have actually used the modelling format you should be able to see what's going on. The ability to add a comment

"__comment": "Remember, redstone_dust_line and redstone_dust_line_overlay need  to be rotated by 90 degrees",

goes a long way. And Mojang, why would this cause them trouble, and how would they forget? When they update the file, just carry on that rotation and remember that is required for the "line" textures.

There are also other outliers that Mojang or users could potentially screw up on:

• plants needing to be recolored

• vines needing to be "twoSided"

• any blocks needing "rotateVariantTextures": false, to have proper top/bottom textures

• curved rails have a differently mapped bottom texture as to look correct

• what texture is west supposed to be again?

• if anyone has a problem understanding rotation, changing the fire models isn't going to be fun

• which blocks am I disabling shading on? What about custom shading?

I already know you're going to say it: "but those have nothing to do with compatibility!"
Yeah, but a few rotations aren't any more confusing than those. As for Mojang, couldn't someone make a converter to update major syntax changes instead of doing them by hand? Then there'd be little room for mistake because all of the properties would be carried over automatically.

Overall, the model format is a technical and confusing thing, but rotation should not be too big of a hurdle for anyone using or developing it, and if it is I truly believe that something is wrong.

As for "making sense to you", why are things like rain, snow, and then enchanting book upside-down? That doesn't make sense at all. Seriously, how is having random textures flipped for no reason less confusing than rotating a texture and having a comment about it?

"I've attempted to pass that information on for your benefit"
"It's better to break compatibility now, when they're making large changes to the format that break compatibility anyway"

Since when are you a messenger? If what you say about resource pack changes is true, than my argument is truly moot. But why wouldn't someone from Mojang come out and say it then? Hey a simple "we're thinking of changing the resource pack format again so this won't be an issue" might help.

A bigger question is: If they're really doing this, why not wait until they've made this change, and then make as many splits from legacy as possible? Seriously, make changes when they are needed and make sense. When you make a huge shift in hierarchy, that is the time to break as much stuff as possible. Not beforehand when you're "thinking about it". If it's going to be broken anyways, break it as much as possible before you create more entropy via adoption.

If that's what they're doing they shouldn't tiptoe around and make random breaks, even in snapshots. Doing so seems out of place, careless, and un-thoughtful because there is no reasoning seen behind it. Doing it all at once would also have the added benefit for resource pack makers to need to do testing to see what's broken, or better yet a changelog of what has changed so it can all be fixed in a clean version, rather than a "random snapshot surprise" that's not even mentioned in the regular changelog. (seriously, that's not an "open" change and is what causes harboring of negative feelings)

If that's what they're doing they shouldn't tiptoe around and make random breaks, even in snapshots. Doing so seems out of place, careless, and un-thoughtful because there is no reasoning seen behind it.

I'm not going to claim to have read your entire post, I'm done with it and I'm letting the rest of the team handle it at their will, however this part stood out to me and I wanted to say one thing about it.

Just because most snapshots work fine doesn't mean they all do. You get a nice big warning saying that problems and data loss may occur. Snapshots are, essentially, the QA team for Mojang and gives a certain amount of quality control. If you can't handle drastic changes between versions, don't use the snapshots. If you want to prepare your resource pack early on use the pre-releases which are usually released about a week early. These are meant to give the public a final product to work with, without completely releasing it (as to verify its bug level is acceptable).

Ezekiel, my point wasn't about "drastic changes" at all, but HOW the changes are released. Torabi was saying that this isn't and issue because Mog told him that they are "planning on changing entire format", and I was saying that if this is true, they should make all changes with the version that this new format is implemented AND have a changelog for WHAT changes happened. That was what my comment was mostly about, because Mojang still isn't doing "proper" changelogs (at least they even HAVE them now unlike for a while there). I mean they don't need to list every little thing they do, but when it comes to changing things that things built for your game (in an intentional way) a heads up would be nice.

So the implementation of changes and the entropy involved (rather than the changes themselves) are my concern. By all means I'd like to see changes about how many of the resources are used, such as rain/snow/enchanting book being upside-down, GUI stuff still using atlases (specifically the arrows for the resource packs and server lists only use 1/4th of their atlas, and the Minecraft logo is split very annoyingly), and less derived textures (like the options slider being taken from the buttons). However when it comes to these sort of changes, doing them all in 1 update and telling the community the changes is the absolute best.

hey Kumasasa, remember when you said the user creating the 100th duplicate gets a free hug, (commented on a duplicate of this) well only 1 left, there are 99 duplicates now 😃

Steve Verberne: That issue already exists, MC-55794, but a mod marked it a duplicate of the wrong issue. I commented by it still hasn't been marked as a dupe of this one.

O ha lol

I'm back to see progress. So far, going well.

Still looking at progress. Right now I'm at 14w25b. Keep it going!

FINAL NOTE: My Faithful32 resource pack broke on me. The cursor is no longer a crosshair, but a square. For now on, I'm using the default resource pack.

WHY MOJANG?! WHY?!

SFC_, that issue is MC-56884

On another note, why was this reopened, and why was it assigned when this is clearly a resource pack issue?

@unknown, the progress is that this ticket got reopened and this issue will be fixed.

After merging the different development branches each of the team members were working on for the past three months, they decided that they needed to make some changes to the models, and @unknown decided to address this at the same time. They didn't deliberately set out to break compatibility with older packs, but couldn't justify the extra complexity at the time when they knew they weren't done with the model format, and would have to do additional work on the models again later.

Ninja-fixed in 14w26c

I'm most definitely getting a "Not entirely fixed" vibe. I'm submitting 3 screenshots, running 14w27b. First one shows how my texture pack's stock redstone texture behaves, totally screwed up. Second shows the ones I altered (rotated 90 degrees to dodge the bug). You can see there is still something wrong... or something that still further needs explaining. As in, what to edit to make redstone going up the vertical face of a block be oriented correctly. 3rd shows the default texture pack behaving just fine as usual.

I'm still finding it unclear whether this is up to users to fix on their own or if this will be fixed for GOOD.

Is it a 'blockstate' issue? I noticed the default texture pack has a new directory with JSON files for blockstates. Is this related since legacy resource packs don't have this as a reference?

@@unknown: If your resource pack works well with any 1.7 version or 1.8 snapshots 13w52 .. 14w11 it will work well in 14w27. Take the default resources (only the PNG files), put them into your resource pack and see how it has to be done. This has nothing to do with blockstates.

@Kumasasa: No, as I've said here before, you DON'T need to put the default resources in a pack, just DELETE the files from the pack and it instead will load the default resources. This will also fix the pack for whatever version you use, rather than for the version you're taken the files from.

Please don't perpetuate more-complicated and WRONG solutions.

EDIT: And just to see how it needs to be only requires LOOKING at the default resources, not overwriting them into the pack. In that case, they could look at the default files and rotate them if this is the problem.

Uploading 2 new screen shots. First shows the redstone wire PNGs working fine in my texture pack for 1.7.10 ... and then not working in 14w27b.

If i rotate the PNG files 90 degrees I still have orientation issues when placing redstone wire across two blocks (and two blocks only) that are seperated by 1 level in the Y direction. If I extend the wires further, the orientation corrects itself.

If it's not blockstates then I'm confused as to how to solve this on my own.

@@unknown: Ask @unknown.

Okay through a little further investigation I'm discovering that there is some other bug at work here, slightly related. I'll have a video demo up in a moment. I will add though that my PNGs that work in 1.7.10 are oriented the same way as the Default texture pack that works in 14w27b. But when I use those same PNGs in 14w27b, they are 90 degrees off. So looking at the default PNGs and comparing them to your custom texture pack doesn't exactly clear things up.

Video demo of redstone wire bug for custom texture packs, behavior as of 14w27b - https://www.youtube.com/watch?v=KBGjIIDkO9o

Quality isnt the greatest but it was a dirty render just to get the point across more clearly.

When redstone wire is placed on a descending surface facing in the East or West direction it takes on the wrong orientation until more wire is connected to it at the same Y level. This only occurs with custom texture pack PNGs. It occurs regardless of orientation of the PNG files.

@Kumasasa: I'm sorry if you feel I'm not in the place to say such a thing (to the point where you resort to passive aggressive comments), but it's a basic function of the resource pack system that missing files are happily loaded from default assets instead. The only needed files are the pack.mcmeta file and whatever you want changed. So you should never suggest putting default assets in a resource pack, because it's not needed. Many people don't seem to understand that you don't need to distribute every single vanilla asset that you don't edit along with your pack, so it's not something you should encourage by giving bad advice.

@ea: If it's only in your resource pack, it's likely a problem with the resource pack. Please check to make sure you don't have any older model files or blockstate files in your pack that might cause this. If you do, simply delete them from your pack, you don't need them. If not, please upload your pack somewhere (mediafire, dropbox, or google drive) and paste the link here so we can take a look at the files.