Adam
- MrChoke
- mrchoke
- America/Havana
- Yes
- No
MC-30934
@Torabi It seems you are making this more complicated than it is. The only universal snapping is upon initial map creation where it snaps to the closest multiple of 64. Now when it zooms out it holds the upper left corner fixed and zooms 100% down and to the right. It doesn't matter where you start. And the behavior doesn't help any larger-scale grid alignment. The upper-left corner stays at the multiple of 64, not 128, not 512.... It doesn't move after creation at all, hence the problem.
All this new behavior does is this... If I want to create a map where my base is centered, I have walk 1024 blocks North-West in order for my map reach full zoom-out and have my base centered in it. Try this out. Its broken and makes maps useless. I stopped using them and won't again until this fixed.
14w32d map, started at -1206,770. Graph shows map where each square is 64x64 blocks. Axis values are coordinates divided by 64.
Your Zoom-0 upper left was (-1216, -832) right? Then you zoomed-out and did it go to (-1344, -832)?
I just though of a great idea to show this. I graphed it. I used the divided-by 64 coordinates in my test and each square on the graph is 64x64 blocks. The maps do not overlap at all. And there is no pattern to what it is doing. Its left, then its up, then its both. Its broke. See the file attached, n1216_n832.jpg
n1216_n832.jpg
Are you guys seeing my point yet? Its doing different things depending on the starting point. Things that don't make sense. I understand the intend of a predetermined grid, but then let me re-phrase my question then:
What are the rules for the predetermined grid?
I am going run another test with new coords after this post. But with my 1st test, what you are saying is that Z0 aligns with (-1216, -832) because of a predetermined alignment. Makes sense. Z1 aligned with (-1344, -832). Ok, so zoom 1 is a 256x256 map right? So you would think -1344 and -832 would be multiples of 256 right? So that people can easily line up Z1 maps. Those numbers are not multiples of 256. They are not even multiples of 128. I can make a similar argument for the other zooms. What the grid alignment based on?
Only in 1.9, all 3D floating blocks are way too big. They are the same size as if they were a placed block. This happens when I use any resource pack, even ones that clearly say they work with 1.9. However, the default pack does not have the issue. Also note, held objects are too big as well.
I have been seeing this issue in many 1.9 snapshots but did not add it until now because I assumed pack writers have to make changes for 1.9. But I have been getting replies from them saying the issue is not happening to them. In fact, I am finding nothing on this issue at all. How can that be? I will add screen shots.
I saw this performance issue when I started using 1.11 pre-release and it is present in 1.11 as well.
The performance when I first start minecraft shows between 110 to 120 fps (I cap it at 120). Then over the course of minutes it starts dropping for no apparent reason. After about 10 minutes my FPS is down to the 30s, sometimes even the 20s!! Note, I can immediately get the FPS back up to where it started by either doing F3+A or changing any of the video settings. Only for it to slowly start happening again.
I have been playing Minecraft since 1.6. I never seen this behavior until now.
I don't remember how to attach files to posts here. I want to add my crash report.
Command block A is set to "Impulse", "unconditional", "needs redstone". It has an execute that is a test returning pass or fail.
Command block B is set to "Impulse", "conditional", Needs redstone". The block behind it is A. The command is a simply "say"
Let's say redstone is sent to "A" (a button click). The execute re
turns says "test passed". Command B does not fire its say command.Click the button again to send redstone to "A" and now "B" fires. Also note that "B" is firing based on redstone coming from "A". I guess this is as expected.
Click the button to trigger "A" again, this time having the execute return "test failed". B still fires! Click the button again, now B doesn't fire.
The "conditional" is using the triggering block's previous output BEFORE the test. This has got to be bugged.
Command block A is set to "Impulse", "unconditional", "needs redstone". It has an execute that is a test returning pass or fail.
Command block B is set to "Impulse", "conditional", Needs redstone". The block behind it is A. The command is a simply "say"
Let's say redstone is sent to "A" (a button click). The execute previous output is "test passed". Command B does not fire its say command.
Click the button again to send redstone to "A" and now "B" fires. Also note that "B" is firing based on redstone coming from "A". I guess this is as expected.
Click the button to trigger "A" again, this time having the execute return "test failed". B still fires! Click the button again, now B doesn't fire.
The "conditional" is using the triggering block's previous output BEFORE the test. This has got to be bugged.
Command block A is set to "Impulse", "unconditional", "needs redstone". It has an execute that is a test returning pass or fail.
Command block B is set to "Impulse", "conditional", Needs redstone". The block behind it is A. The command is a simply "say"
Let's say redstone is sent to "A" (a button click) and the execute test passes.. The execute previous output is "test passed". Command B does not fire its say command.
Click the button again to send redstone to "A" and now "B" fires. Also note that "B" is firing based on redstone coming from "A". I guess this is as expected.
Click the button to trigger "A" again, this time having the execute return "test failed". B still fires! Click the button again, now B doesn't fire.
The "conditional" is using the triggering block's previous output BEFORE the test. This has got to be bugged.
Command block A is set to "Impulse", "unconditional", "
needs redstone". It has an execute that is a test returning pass or fail.Command block B is set to "Impulse", "
conditional", Needs redstone". The block behind it is A. The command isasimply "say"Let's say redstone is sent to "A" (a button click) and the execute test passes.
.The execute previous output is "test passed".Command B doesnot fire its saycommand.Click the button again to send redstone to "A" and now "B" fires. Also note that "B" is firing based on redstone coming from "A". I guess this is as expected.
Click the button to trigger "A" again, this time having the execute return "test failed". B
still fires! Click the button again, now B doesn't fire.The "conditional" is using the triggering block's previous output BEFORE the test. This has got to be bugged.
Command block A is set to "Impulse", "unconditional", "Needs redstone". It has an execute that is a test returning pass or fail.
Command block B is set to "Impulse", "Conditional", Needs redstone". The block behind it is A. The command is simply a "say"
Let's say redstone is sent to "A" (a button click) and the execute test passes. The execute previous output is "test passed". Yet command block B does execute it's "say".
Click the button again to send redstone to "A" and now "B" fires.
Click the button to trigger "A" again, this time having the execute return "test failed". B fires again! Click the button again, now B doesn't fire.
The "conditional" is either always using the test block's previous value to determine whether to fire or not, OR it is firing before the test block's evaluation occurs. One or the other. Either way the behavior is that a test has to be met TWO times in a row for a condition block to execute based on it. And also, if the test block evaluates to false, expect another execution of the conditional block anyway, even though its false.
I wish others could comment on this. Seems like a very a serious issue. I opened this bug a month and half ago and still fight with it. I did find a way to force the test block to reset after an execution. Execute the "data" command on the command block updating the "SuccessCount" nbt tag to 0.
@Adam I never said it was only on older worlds.
@Galaxy_2Alex Just helping the issue get a little more visibility by adding a comment, if adding a comment does indeed do that.
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
Adam, you put way too much thought into understanding a system that was designed to require no thought at all. Maps now align themselves on a grid, such that they either represent the exact same area at the same zoom level, or don't overlap at all. This makes it trivial to make a wall of maps in item frames that line up correctly with no overlap. Unfortunately, with this comes the loss of the ability to choose the center point of the map, and a greater risk of accidentally creating two separate maps that cover the exact same area of the world.
Torabi, assuming this change in map behavior is intentional (as you describe), it represents a philosophical change in the concept of maps in Minecraft. One of the beauties of Minecraft is that every individual can play the game in a different way, suited to their own interests. For those who like to explore large areas and stitch maps together, the new behavior will be regarded as a good thing. It will substantially reduce the effort required to get separate maps to line up with each other. For the rest of us for whom maps are primarily about mapping the area around where we live, it forces us to choose a location for our domicile that has a particular orientation to the invisible coordinate system. (Keep in mind that the grid coordinates are only visible if you either have a mod installed or use the "diagnostic" HUD.)
I personally don't like the new philosophy, though I think I understand it and recognize that there are those who will like it. Maps no longer work in an intuitive fashion aligned with the "primitive" character of stone picks and shovels. Instead they act more like satellite images managed by NSA computers.
Has this new philosophy of maps been vetted against the Minecraft vision?
This very succinctly describes the entire situation. However, I'd argue that there's been a gradual shift, at least in respect to maps, from realism to convenience, over the course of Minecraft's development. When they were originally added, they were centered on the exact block the player was standing on, but this was changed in 1.4.2 to center on the chunk. This was certainly less flexible, more magical, and required an understanding of the internal concept of a chunk to be able to predict where the map would be centered. But it made efficiently mapping out an area much easier without counting blocks or using the debug screen.
The ability to clone maps, and for multiple players to appear on the same map, was originally a bug: maps could only be cloned by shift-clicking when originally creating the map, and the player arrows would all be pointing in the direction of the person holding the map, even if the players were facing/moving different directions. This was later fixed up and promoted to a feature: copies of an existing map could be made by crafting it with another Empty Map, and player arrows reflected the actual orientation of each player. Maps also show up as green dots when a copy was placed in an item frame. This information is communicated "magically" between all copies of the map in the world. When item frames were originally introduced, the map showed up in the middle, like any other item, but as of 1.7.2, maps cover the entire block when placed in a frame, to allow for seamless tiling, and thus the creation of large, composite maps. This latest change is just an extension of that trend.
Minecraft is deliberately simplistic, and sacrifices realism for abstraction in many cases. Consider, for example, the use of the same furnace to both cook food and smelt ore. Or the crafting table, which is used to create a wide variety of items, and which features a number of metal (or perhaps stone) tools on the sides, and yet only requires four wooden planks to create. So I don't really think this change violates the philosophy of Minecraft, and I doubt there would have been many complaints, were it not for the absolute loss of the ability to choose the center point of the map.
I don't think reverting to any of the previous behavior is the best solution. That just sacrifices one usage pattern for another. Seamlessly tiling maps is now well supported. Ideally, there should also be a way for players to create maps that aren't locked to the grid, with a way to specify the center point down to the exact block, like when maps were first introduced.
Oh. If this is intended ok. It does look odd but it makes the biome different!
Thanks.
The crash report is attached.
I have an update on this issue. Since I posted this problem, I decided to run Minecraft with a 32-bit JVM. It locked my PC in about 15 minutes. Same behavior.
Until you have another thing for me to do, I will do the following two things.
1) Run the current snapshot on my laptop. Its still a Windows 7 64-bit PC and I ran Minecraft on it for a week on 13w38a. It did not crash once in that week.
2) Revert the game to release 1.6.4 on my primary PC, the one having the lock ups and see if 1.6.4 locks up. I assume it will not. I played 1.6.2 on this same PC for months with no issues. But we'll see.
I ran a hardware monitor for that and no overheating has occurred. Note that this PC is my gaming machine. I play Natural Selection 2 and Battlefield 3 on it, both MUCH MORE taxing on my hardware than minecraft and no lock ups occur. Its Minecraft, not my machine.
I have some more info on this issue. Test 1 above, running 13w39b on my laptop has shown that is does not lock up at all. I had it on all day and it worked fine. Note this PC is fairly new but is in no way a gaming PC. I use it for work, not play. I can give you a crash report for it, if you like.
Test 2, running release 1.6.4 on my gaming PC, the one locking up. I ran this for multiple hours with no lock ups. I then decided to run with the latest version where I thought it was not locking up, version 13w36b. This version ran fine for hours as well. It proves the following:
A change somewhere in week 37 or later is causing my high-end gaming PC to system lock. My best guess is those secret setting shader changes, since they seem "cutting egde" for Minecraft. I never use them. But I guarantee you this, people running good PCs like mine are going to see their machine hard locking from this game if this isn't fixed. I never have a problem with this PC. And I have already found errors on the windows partition from these lock ups. This is a very serious issue.
Hello. A forced crash report is attached as requested. As far as a real crash report, I get none. I don't even get an error in windows event viewer. I don't get an error anywhere that I know to look. My PC simply locks up completely. I have to hit the reset button.
Regarding similarity to
MC-31618, I see no similarity. There is no DLL error or error of any kind. Also, I run 2 nVida GTX 570 cards, not using AMD catalyst. My nVidia drivers are the most current available.So what are next steps on getting this resolved? I see your name as [mod], that means you are a mod on this issue tracker site, right? Do DEVs see these issues? Can serious ones like these be sent to them or can they be alerted that this needs to be looked into. One of them made a recent change that is having serious consequences. They need to be made aware.
Are you kidding me, vote based!?!?! I am not talking about an "enhancement" here. If Mojang releases a bug like this for 1.7 and it crashes even 5% of the PCs out there, how many votes to uninstall Minecraft will they get??? How many votes to blame Mojang for Minecraft corrupting their windows install as it locks up in the middle of writing to disk?
If this issue tracker is a happy-go-lucky vote system, get me the REAL issue tracker or a DEV email address so I can help save Mojang ALOT of head ache with 1.7. They are messing up something bad with newer systems and I AM SURE they want to know.
Ok, I will check out that site.
Regarding this being the only ticket reporting the issue, how many of the tons of people with Minecraft are running these snapshots? 1%? The problem is with the very latest code and it doesn't lock up on all PCs of course. Do you think a PC less than 2.5 years old running 2 GTX 570 video cards and Windows 7 is all that uncommon? I can send you screen shots of how I can run games like Battlefield 3 for hours straight and it runs great.
I have one final post on this topic. I have found 100% root cause of this issue. Since 13w37 Minecraft snapshots and later, if you have TWO GTX 570 video cards running SLI, your PC will hard lock within 45 minutes. If you disable one of the card, through the nVidia control panel, the lock ups stop.
So there is one reason and reason only why this issue has zero tickets. Because very few, if any people are testing these snapshots and running two SLI video cards, maybe even specifcally 2 GTX 570 cards if only this card type is locking up. Either way, if DEVs don't fix this, people are not going to be pleased. I know not too many people run SLI, but certainly enough people that do are going VERY ANGRY at Mojang, VERY quickly.
I don't give a damn about this silly ticket systerm. Let a DEV know they need to fix this.
Thank you.
No. Just close the ticket.
I didn't realize you were a DEV. Thank you for responding to this. I have to admit, though I tried as hard as I could to be certain of root cause, it was not Minecraft. Nor, was it hardware. It was Adobe Flahplayer 11 causing my lock ups. It was a perfect storm of sorts on how I came to the wrong conclusion. if you are interested read on.
I never had lock ups on this PC in anything.
Then recently Minecraft Wiki upgraded their site. When I play MC, I always have that site open in IE. Its very helpful.
After their upgrade, when you run the site in IE, a stupid Ad box renders right over the search box! If that is on purpose someone needs to be shot. My work around to that was, I installed Firefox and the Ad box is in a better position.
Because Minecraft Wiki has embedded videos, Firefox kept asking me to install Flash player. I finally got sick of it asking so I did. I didn't even think twice about it being an issue and I forgot I did it. Its a flash player. How can that lock my PC?
So my PC started locking. Since I always run Minecraft Wiki and MC, my default position was that one of latest snapshots was causing it. Its all I changed on my PC, that I remembered. I tried very hard to prove it was a new snapshot and a compatiblity problem with my gaming PC. However, my test case was flawed. When I tested, I didn't really play MC like I usually do. Basically I had it sit there or I did a few random things. But never did I have Minecraft Wiki open!!! Same as my laptop, when I tested, never did I have it open. Of course Flash may not lock on that, I don't know or care. I even turned SLI off and saw it working even with the latest snapshots. But again I never played like I usally do, so it gave me a false positive of root cause.
What finally changed my position, is playing Natural Selection 2, a game I put over 400 hours into with no locks ever. My PC locked on it! But I had just gotten done playing Minecraft (with the wiki open) and I didn't close the browser. After the lock, I knew MC was not to blame. I then proceeded to the store and bought a GTX 770 card thinking one or both of my GTX 570 cards were bad. No way would NS2 lock without it being a new hardware problem.
The very next day on the new card my PC locked again! The same way. But here is the kicker, before it locked I saw stuttering playing a MC video on youtube and shortly after my PC locked for about 20 seconds. I almost rebooted and then Firefox reported that Adobe flash stopped responding. Shortly after that, it hard locked for good.
I did some reasearch and sure enough, Adobe Flash 11 and their stupid protected mode is locking up PCs just like mine was doing. I uninsalled and will never install again. And my hard locks are gone.
Thanks.
I confirm this is happening in 13w39 as well. One very easy way to re-create it is to have a mob ride in a minecart and than break the cart under him. For about a minute he will walk around half in the ground. After a while, it does correct itself and he starts walking on the ground as normal.
I think what is needed is a post from the DEVs confirming this is a bug and that it will go away in a future snapshot. People who understand snapshots need to deal with issues like this but the DEVs need to respond to them too. Unless of course it goes away very quickly. Like today maybe! I can only hope. I backed up to 13w39b as well because of this bug and the other one where "Rendered chunks" has a max of 8 now and not 16. Both are deal breakers for me.
@Ezekiel, No I missed that it is fixed. Would that be in this entry where it says Fixed Version: "Future Version - 1.7"? I need to look at that field more often if that is the place to look. Thanks.
I confirm this bug is happening in 13w42b as well. I see it most often with slimes but any creature can do it. Its basically the same behavior I saw in older versions. The easiest way to re-create for me is, have the mob in a mine cart. Destroy the mine cart under him.
I have this too. Music overlaps. I don't do anything to force a music change. It just happens on its own seemingly at random.
it is strange I guess but I am not having this problem since 1.7pre. I was before for sure. I get behavior where the music stops when you got to the menu but that is it. I have not heard multiple songs playing at the same time.
I can confirm this is not fixed 14w04b. I first saw it in 14w04a and it continues. I was always getting between 60 and 90 FPS no matter what. What is happening now is some kind of cycle. Even when I am standing still, about every 8 to 10 seconds, the FPS drops all the way down to between I'd say 10 and 30. It stays down for less than a second. Then it comes up again only to repeat the slowdown 10 seconds later. It never used to do this. I know this is a snapshot and stuff is a work in progress. Please don't close this ticket. Something is still broken.
Ok, the crash report is attached. I want to update my findings on this after I rebooted my PC and then played for quite some time. I found the very bad and repeatable drop in FPS like what I reported before occurs only at the beginning and it does "even out" after a short time it seems. The behavior does not exist in 1.7.4 I am certain of it. I played the same world on 1.7.4, and it didn't happen. What I also see is I was actually getting framerates all the way up to my maximum in most areas, the max is 120. It looks like with the latest snapshot I can achieve this same max framerate. My summary of what I see is this:
The framerate is much more volatile since 14w04b. The game "hitches" if you will much more now.
I can confirm this bug as well. On both of my pre 14w04b worlds, every Item Frame and map in them popped. I happened to start next to an Item Frame in one of the worlds so I had time to see them laying on the ground. Here is the other problem. So I put the frame back on the wall and then the map. The map no longer renders in the frame. It shows a green background in the frame but the contents are empty. And YES, the map is fully explored.
I confirm this as well. Both on pre-14w04b worlds and when creating a new world in this snapshot. Maps rendering in Item Frames is completely and totally broken.
I agree it has improved since 140w4a. Whether chunk updates have made it better fine. If you want to close it because of this fine by me. It is still slower than 1.7.4. But call that another issue then.
You guys have all reported that the items popped out, me too. How about when you put them back in with 14w04b? Specifically the map. It doesn't render. Period. I know that is a separate issue. It's this one:
https://bugs.mojang.com/browse/MC-45764
Yet, very few people are reporting it. Put the maps back in the frame and see if they render. If they don't, comment on that bug so it gets better attention.
@Kieren
I do not agree its just older worlds. I created a brand new world in 14w04b and then created a new empty map. I then moved around some so that part of the map was explored. I then put the map in the frame and it added to it. I got the green background on the frame and the map was out of my inventory. HOWEVER, it rendered nothing. Even though part of the map was explored.
I confirm this bug is resolved in 14w50a. Thanks!
I can confirm this bug too in 14w05a. No chest whatsoever in dungeons. This has been broke since 14w04a? Ugh. I guess I shelf the snapshots until this nasty one is fixed.
Ok, two more snapshots with tons of fixes and enhancements and this is still not fixed. How are people going to want to start new worlds or even venture out in an existing world when they know any chunks generated will have completely broken dungeons in them? Come on Mojang. You can't leave existing core functions of the game broke and expect us to want to test out your new stuff. This needs to get fixed. Next snapshot. Some guy above says he fixed it and I assume he doesn't work for Mojang. I am not going trust his fix but I think the point here is made.
This bug is unacceptable IMO. Yeah, you don't want to venture out in your current world because of it. The enjoyment of dungeon hunting is a total waste. Starting a new world is useless too unless you want to go back 1.7.4. 5 or more snapshots with it and this bug is alive and well.
The people downloading these snapshots are your QA group. That is fine. And of course work in progress code has bugs. It just seemed a very long time to fix, as you have indicated, a one line code change. I know there are priorities and I guess given the other issues, this would be lower than those. I guess the grain of salt to rub in with 1.8 snapshots is that stuff out-of-the-blue is going to break that has worked fine for many releases. To be honest I have reported many bugs and not gotten particularly upset about them (except one but that was my bad and I admitted it). This one made me stop being a QA tester and enjoy the game at the same time. I stopped playing it altogether. I want to see the new stuff and I totally understand if the new stuff is broken at first. But I was not prepared for old stuff like this to be broken too.
BTW, you can lay off on the condescending attitude I’ll lay off on riding Mojang for poor snapshot bug turnarounds. Deal?
@Mog:
Didn't realize you posted this in the bug site itself. OK here is my reply also public:
The people downloading these snapshots are your QA group. That is fine. And of course work in progress code has bugs. It just seemed a very long time to fix, as you have indicated, a one line code change. I know there are priorities and I guess given the other issues, this would be lower than those. I guess the grain of salt to rub in with 1.8 snapshots is that stuff out-of-the-blue is going to break that has worked fine for many releases. To be honest I have reported many bugs and not gotten particularly upset about them (except one but that was my bad and I admitted it). This one made me stop being a QA tester and enjoy the game at the same time. I stopped playing it altogether. I want to see the new stuff and I totally understand if the new stuff is broken at first. But I was not prepared for old stuff like this to be broken too.
BTW, you can lay off on the condescending attitude I’ll lay off on riding Mojang for poor snapshot bug turnarounds. Deal?
I rebuilt a new map, same seed. The previous empty dungeon now has chests. This bug is confirmed FIXED in 14w07a
I have not seen this bug in many releases. I will say in creative mode there is what "seems" to be a small overlap in two songs. But if you really listen to it, its meant to be this way. Maybe some people hate the style of the music and think its overlap. I re-played "overlap.wav" that is attached. What I am saying here is nothing like that. That wave is clearly playing music very much messed up. But I haven't heard that in months.
I get this too. The Endermite just sits there rotating very quickly until it despawns.
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?
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.
This issue is fixed for me. I am still using the same version of resource pack (Chroma Hills 1.08). I put the resource pack redstone images back into the folder and they now render correctly.
I too have seen a major framerate drop in 14w28a and b. It runs at the cap I set (80 fps) most of the time and then it will drop hard to the 30s or so and come back up. It has been many snapshots since I have seen this behavior. I just read Kumasasa says its fixed in the next snapshot. That would be good.
Yes, its a duplicate. Sorry I couldn't find the dup when I was searching.
I also have a very fast computer and I get delays of both block placement and door changes or they do not occur at all until another block is placed. The occurrences have reduced since 14w30 I believe but they are still happening.
I can confirm this too. Been doing so good playing these snapsahots, finding only minor problems until this one. I cannot even get a cow, sheep or anything else into my base.
I can confirm this as well in 14w31a. As you zoom out, the map gets more and more off center. By the 4th zoom out, it is like your screen shot, almost off the map altogether
This is not working as intended. If it was, it would be said that a change has been made in one of the snapshots. Before this problem, when you create the map, it always stayed center (except for the 1st zoom I think). So if you created it in your base let's say, each zoom out kept your base in the center of the map. Now, your base moves to who knows where depending on the global coordinates as you zoom. You will never be able to map anything and keep center. That is ridiculous. This is bugged. PERIOD.
I too have seen this with aggressive mobs. It doesn't seem like they do it 100% of the time the way led passive mobs do. What an awful bug this is.
Yes, this very annoying bug appears to be fixed in 14w32a. YAY!
Not sure if these recent posts are building cases to say this is not a bug or perhaps its what Mojang intended. I can't see how it is intended or good behavior. I analyzed exactly what is happening.
When you fist create a map, the upper-left corner is set to the largest multiple of 64, less than your current coordinates. I believe that is how it always worked and I don't think this is bugged.
What is bugged is when you zoom the map. Since 14w31a, the upper-left corner stays FIXED as you zoom. So the result is a map zooming down and to the right by the number of blocks for the zoom (128 for the 1st zoom, 256 for the 2nd, etc...) but not zooming at all up or left. The map zooms out shifting down and to the right for each zoom.
What it used to do before this bug is zoom the same amount in all directions relative to the current upper-left corner. So the 1st zoom would result in a map range 64 blocks up, 64 down, 64 right and 64 left. The map zoomed out centered.
They really need to fix this. It doesn't matter where you start the map, it will always zoom out broken like this now.
@Torabi What you are saying is not holding true. After further testing I find what I posted above, where I say the upper-left corner stays fixed is not true either. I don't know what the behavior is. It seems almost random and random = broken. I also think we need to not consider the world origin, (0,0) unless somehow that is truly part of the calculation. You can make a map anywhere, even greater than 2048 blocks away from (0,0). What then? The rules should apply the same anywhere in the game world.
The only true steadfast rules I can still confirm are the following:
1) The upper-left corner of the map snaps to the closest multiple of 64 from where you created it.
2) Every subsequent zoom-out remains a multiple of 64. But ONLY 64. The map is not snapping to higher multiples as it zooms.
Rule 2 invalidates the concept of a global alignment. A full zoomed out map is 2048x2048 blocks. If the intent is to global align, then the upper-left corner at full zoom should be a multiple of 2048 right? Its not, its 64.
I'd like someone to try this test in their world. Here is what happened in mine:
Z0) I created a map at: (-1206, -770). The upper-left corner (UL) snapped to: (-1216, -832), closest multiple of 64. Divide these cords by 64 and its: (-19, -33)
Z1) Upper-left went to: (-1344, -822). Divide by 64: (-21, -33)
Z2) UL went to: (-1600, -1088), Div. by 64: (-25, -17)
Z3) UL went to: (-2112, -10878). Div by 64: (-33, -17)
Z4, final zoom): UL went to: (-2112, -2112), Div by 64: (-33, -33). Is 2112 even a multiple of the next zoom, 128? NO, its not.
What the heck is doing????????? It is going all over the place. Looking at easier number, the div-by-64, this is what it did:
(-19, -13)... (-21, -13)...(-25, -17)...(-33, -17)...(-33, -33)
Either the rules are so complicated they are stupid, or a better answer: It's bugged.
Try running quickly to a door and opening it. For me, at least 50% of the time, the door doesn't update, it still shows closed even though it is not. And it does not update until I place or remove another block. This is my big test of this bug and in 14w32d, I see no improvement.
@Arjan De Vries: I am not overcomplicating anything. Your comment made me go back and look again. It is doing EXACTLY what I posted. Do the test I posted and tell me what the behavior is. If it is different, post it.
What you are saying is not happening in any consistent, reliable way. I did another map starting at (0,0). The behavior there is a FIXED (-64, -64) upper-left corner. As you zoom it goes down and to the right. What grid-alignment is that other than 64? It stays at -64 and therefore fails the very next zoom-out multiple, 128. If what you are saying is true, shouldn't it be snapping to -128?
I am trying as hard as I can to believe that it is working the way you and Torabi are saying. I cannot.
What I did in this last test is completely blow away my ".minecraft" folder. I downloaded 14w32d clean and created a brand new map. I then did my test again, the test I asked you to do and I am not reading that you did it.
Teleport to: (-1206, Y, -770). Y=whatever, who cares
Start zooming the map out. It did the EXACT same thing I posted, on this new world, clean build.
In your last post you gave me test numbers based on origin 0,0. I agree. It is consistent in how it zooms. Its FIXED upper-left. That is not my point and that problem.
Do my test, Arjan. Until you do, I cannot believe you. I challenge anyone to do my test and tell me what you get.
So in your test, did you get a zoom-1 upper-left coordinate of (-1344, -832)? I hope you did then it is at least doing the same thing as mine.
So I thought of a great idea. I graphed what this doing when I started at (-1216, -770). each square in the graph is 64x64 blocks. The axis coordinates are the values divided-by-64. Look at how it is zooming out all over the place. It zooms left, then up and left, then left again, then up. File attached, n1216_n832.jpg
I agree with SystemReady exactly. I could probably deal with a map that doesn't stay center each zoom, but now we have zooming that goes in different directions depending on the starting point? Its not consistent at all. The zooming is not even snapping to a larger grid. It seems random, zoom left, then up, then up-left. If this is intended and they go live with this, its going to get lit up.
I have not heard a logical reliable explanation to how this zooming works. How can you start a map at (0,0) and it zoom consistently down and to the right, and then you start another map in a different place and see completely different zooming like I posted in the file n1216_n832 above. There is no logic to this. There is no way they have made the game easier, better and certainly more fun. Instead they have broken a great part of the game and most people are going hate this and no longer use maps.
Can someone explain to me why my test mapped like it did? From 0 to 1, the map grew down and the left. From 1 to 2, up and to the left. From 2 to 3, back down and to the left. From 3 to 4, up and to the right. I would actually at least understand consistency if it always did this. But it doesn't. The question:
WHAT ARE THE RULES THAT GOVERN HOW IT CHOOSES THE ZOOM DIRECTION?
OK.... Sorry I didn't catch this sooner. The numbers are now lining up better on what the predetermined grid is supposed to do. My error is expecting the upper-left coordinates to be multiples of the zoom dimension. Even though, I used upper-left because it is easy to determine in the game (look for when the icon changes between arrow and circle), it is not the coordinates of the alignment. It is CENTER. You need to take the upper-left coordinate and add the zoom dimension divided by 2. Then you got center.
So we expect this thing to line up to center coordinates based on origin: (0,0) right??? That means these should be the predetermined alignments used by Minecraft:
Z0: ...-256, -128, 0, 128, 256...
Z1: ...-512, -256, 0, 256, 512...
Z2: -1024, -512, 0, 512, 1024...
Z3: -2048, -1024, 0, 1024, 2048...
Z4: -4096, -2048, 0, 2048, 4096...
HOWEVER, trying to apply this alignment to the test attached, FAILS. BADLY. It is easy to see with using the center numbers:
Start: (-1206, -770)
Z0: Center (C): (-1152, -768). Is a multiple of zoom dim, 128? yes. PASS
Z1: C: (-1216, -704), Multiple of 256. no. FAIL!!!!!
Z2: C: (-1344, -832). Multiple of 512. no. FAIL!!!!!
Z3: C: (-1600, -576). Multiple of 1024. no. FAIL!!!!!
Z4: C: (-1088, -1088). Multiple of 2048. no. FAIL!!!!
What is happening here guys????? Is the grid's origin not (0,0)? If not, why not??????
I did 4 more tests this morning before posting this. All of them setting a starting point greater than 0 and they all lined up how I would expect. I am going now do tests with the starting point less than 0 and see what happens.
I FINALLY FIGURED IT OUT!!!! And I tell you what, it is consistent, and reliable and IT SUCKS. The assumption I made and to me, a common assumption is that alignment points as you zoom stay relative to each other, in that they keep a common origin. A logical assumption is 0,0. This is not true. Each zoom level has its own origin and alignments. These alignments are consistent regardless of where you create the map. And hence I can finally agree, THIS IS WORKING AS INTENDED.
Here are the working alignments for this new mapping logic:
Z0: ...-256, -128, 0, 128, 256, ... (multipler: 128)
Z1: ...-704, -448, -192, 64, 320, 576... (multipler: 256)
Z2: ...-1344, -832, -320, 192, 704, 1216... (multipler: 512)
Z3: -2624, -1600, -576, 448, 1472, 2496... (multipler: 1024)
Z4: ...-5184, -3136, -1088, 960, 3008, 5056... (multipler: 2048)
I guarantee your maps will align to the above pattern.
Now the million dollar question I have for Grum and Mojang is: Why did you do this way????????? Is it bugged? NO. Is it intuitive? HECK NO. I am not a dumb guy and it took me a long time to figure this out. I am all for auto-aligning maps but come on guys. Make it easier than this.
Attached is file, zoom_alignments.jpg. This shows how the alignments work as you zoom. Each square is 64x64 blocks. I am only able to show 1/4 of a zoom-4 map on the 8x11 graph paper. But you will see the pattern. After actually visualizing it like this, I am ok with it. It actually makes sense.
@Joseph Charron. The zooming one is correct and it are universal. Use math and multiply by the appropriate number for the zoom. If you do not understand them or follow them what it means is you do not like or do not understand the new mapping approach they have in 1.8. Prove them wrong.
Sorry I didn't realize the long-winded explanation above is you as well. Your explanation is no less complicated than mine. I think it says the same thing... I think.
I needed to prove this wasn't bugged. My graph shows real numbers that these maps will align to at every zoom. What have you contributed to this thread?
@Arjan: Yes, this was a pain to figure it out and I do take away the proof to myself and to whoever else that may care that it is not bugged. The other advantage I have now is that I understand where the map centers will always go. It is true that you cannot have your base be the center of the map at all zooms, unless you build at the world origin. But if you desire having your base at the center of a map at a certain zoom, the numbers I wrote represent where that center will always be.
For example, you want your base in the middle of a zoom 4 map and the area you are in is like (-900, -900) let's say. You know that at zoom-4 center is (-1088, -1088). You can plan for it, if you want. Now if you don't care about center and you care more about lining maps up in item frames, then it will be automatic.
I think the suggestion others have given in this thread is a very good one. And that is, give us an option on how this mapping works. Let us set old or new.
@Torabi: My over-complication was partially my fault admittedly. I had some principals on how I thought it worked hard-wired in my head and I had to prove them out. However, a good portion of the difficulty will come to anyone who wants to understand where there base goes as they zoom a map. For the people that want to map based on their base, they are going have a hard time now. But if you want to make maps and frame them up, this change is excellent. It is a no brainer.
For me, since I understand it now, I can use them either way. Is better this way? Its clearly a matter of opinion.
What is also really bad about this bug is that it is lingering on through all of the code cleanup and optimization that has been done for 1.8. It must be a difficult problem. So if 1.8 doesn't address it you may as well consider this simply how Minecraft is going to be for a long while.
@Jesper Petersen: Center is (0.0). I first thought that where the maps align to their multiple of X was in the upper-left corner. This is not the case. CENTER is the multiple of X always. X depends on zoom level (128, 256, 512, 1024, 2048).
You have to use math to calculate center now. But only if you NEED it. I started one of the maps I had shelved in my 1.8 world. It looked so bugged when as I zoomed the map, my base was going all of the map. But now I understand that when I see my base near the upper-right corner of my zoom-4 map, all I have to do is move east far enough so that I am off that map, and then create a new map (make sure you go far enough or you will duplicate your current map). I can then zoom this map all the way out to zoom 4 and it will line up exactly where my current map left off. I like it now that I get it. Its automatic. Its easy.
I removed my vote for this issue to be fixed.
I am seeing this too. In the latest snapshots rabbits do not run away from you even when not tamed. When you hold out a carrot, they no longer slowly come toward you. Instead they immediately run up and jump at you. You can still feed them and they go into love mode but that's about it.
Also, I cannot see anything that tells me they are tamed. They don't follow me anymore. They don't teleport to me any more. Is the rabbit AI just completely broken now or am I missing something?
I have read this a few times in multiple issues: " as of 14w34b since rabbits are no longer tamable."
Where do the release notes for 14w34b say this? Did Mojang say that rabbits can no longer be tamed or are you saying its bugged since 14w34b?
Guys this bug is back in 16w06a. I am seeing it right next to an ocean monument. So much so that guardians have fallen into and are flopping around. I can show screen shot if needed.
I can confirm this too in 16w07a. It is annoying. The light will not update until you force a reload with F3+A
Is it possible that this bug is only because its a snapshot? Maybe the code is running in a sub-optimized state and this will go away for pre-release. I can only hope I guess. I sure don't see it in 1.8. Its very bad. I am surprised others are not reporting it.
I added 2 more screenshots. Before with torch and after without torch. Lighting is not updated correctly in many places. This is very easy to re-create.
I added two more screen shots for this. A before with torch and then after the torch is removed. It is very easy to reproduce with the 16w snapshots. I wish this was voted on more.
I am seeing bugged-out skeletons as well. They are all over my world. Its a brand new 16w07b world. Not only do they just stand there but they don't burn in sunlight either. I can hit them and they register a hit one time and then they don't register hits any more either. I can't kill them. Ugh.
I see a 1.9 pre-release is out and this bug is not on the fixed list. Will this be fixed before next week??? I got these frozen skeletons all over the place.
I did. All four of them. They all say its working fine for them. Like I said, I thought it was that too. But I don't any more. Where is the change log that says all older resource packs need to make changes for floating block sizes?
You so quickly closed this. Too quickly. Give me some proof that all the resource packs are indeed broken for 1.9.
UPDATE: I found a 1.9 pack that works. I guess it is a resource pack issue after all. I tell you what, almost all of the resource packs are broken now. Mildly annoying. Anyway, I now agree.
Of course, the next time I go on a wolf hunt after posting this, Yes, I FINALLY find one (3 actually).
Answer this question if you can on how they spawn. Do they only ever spawn once, in a newly generated chunk? Or will they spawn again in a loaded one? If its the former, no wonder I spent hours trying to find one and I was never able to.
Ugh, I am very much in agreement with what
MC-28424is saying. I only finally saw one after I moved to a whole new forest, many chunks away from where I had been. They did not respawn in any chunk I had already been to. And I looked for hours.This really needs to be fixed.
@mod, this bug needs to be re-opened. Or at least link it as a duplicate to something. It is reproducible.
Wow, just realized that this bug was opened way back in Aug 2013. So I guess we can expect this to be fixed basically NEVER. Great. So how exactly do I play minecraft with wolves and oceloets? And no, spawning them is not the answer. One of the main fun thing about survival is finding stuff. I will never find two very cool parts of this game thanks to this. This bug sucks. And for it to be around for almost 3 years is awful.
I did some testing too, not Ocelots but wolves again. My findings are very strange. I generated a new world, seed: "Game's Broke". I can fly/teleport/walk whatever over to around X,Y,Z: 142, 70, -127. Each time I tested, there is always two packs of wolves starting in that area. Now here is the thing, most of the time, if I move maybe 100 or so blocks away from them, they despawn and they never come back, in that area or in any other I have found in that whole biome. This happened all but one time. This one time, they never despawned. I teleported as far as 3000, 80, 3000, came back and they were still there. Go figure on that one.
You know I can understand and even want difficulty in finding wolves. I don't want them to be dime a dozen like pigs or cows. But is this how they are doing it? By having them generate with the chunk, never respawn and in all but the rarest cases, they despawn if you leave the area. How close do you have to get to them before you are close enough that they despawn? I know you can hear them but only if you are close. Also, what if you first enter that chunk at night, wolves don't spawn at night right? So did you just blow your one chance to see them? I would really love to know if this is as intended. It seems bugged to me.
One more point on this. I know this bug tracker has a voting system. But you know what, a bug like this is never going get lots of votes. Most people will just assume that they just haven't been lucky enough to find a wolf. Heck, the moderator closed my issue on this at first because he found wolves. 50 bucks says he never saw them again once he left though. My point is just because a bug like this doesn't get tons of votes doesn't mean it shouldn't be fixed. Its been around for almost 3 years if not longer. If the DEVs really did not intent this odd behavior, it needs to be fixed, regardless of the number of votes.
@Rick Harris. Probably best to add a comment to the main issue open for this,
MC-28424. They marked this as a dup. I agree, some bugs need to be fixed regardless of how many votes they have or whatever other process this bug tracker has. A special route to a DEV's inbox needs to exist so true bugs can get fixed. Period.Crash report. FPS was about 28 when I crashed it.
Just tried it with no resource packs and yes it did the same thing. It started out almost pegged at 120 fps. It took a bit longer for some reason but it did start dropping. It got down to upper 30s. Then like with the resource packs, I do F3+A and it goes right back up to 120.
Not that I can confirm happening every time but I started seeing the drop after I heard mobs nearby. I will have to test some more. Right now I can't say what triggers it, if anything.
So am I the only one on the planet getting this problem? I run Battlefield 1 in Ultra and get 80 frames per second and Minecraft won't give me more than 25 at times. Something is up here guys and I know its not just me. There must be one or more threads that start hogging the JVM. It's not a memory issue that's for sure.
Guys, this needs to be reopened. I am using version 1.11. I can confirm hostile mobs are not crossing rails, ever as far as I can tell. They chase me and then stop like they are walls. But they still can see me. I can hit them too and they still will not cross the rails. This applies to all mobs I have seen so far, zombies, creepers, skelektons
What I read was the intended behavior is to not cross rails UNLESS a mob is chasing you. This is not the case. They never cross the rails. BTW, I know why this bug tracker exists.
Sure. I attached screen shots showing FPS variations, before and after F3+A.
I have seen a few more things about this behavior. I attached night screen shots because it is worse at night out in the open. My best guess on this could be that the mob AI is slowing the JVM down but I don't know.
One other thing is it's not as slow with the default pack. I never run that. I run a 128x128 pack (no optifine or any other mods). Just that pack. With the pack the low range is probably 20s to 50s. With the default pack, probably 40s to 60s. But note, with both packs, hitting F3+A picks the FPS right back up to 100s to 120 (I cap at 120). Only to slowly start dropping again.
Thanks.
I recently played 1.12. I have yet to see this happen again. I do have a new video card, not sure if that matters as well. Anyway, I will update this if I see it again but so far, I do not.
F3+C no longer forces a crash. How do I do it?
F3+C no longer crashes the game. How do I do it?
Hi. I have done a lot of testing since. I even went back to 1.12 and tried it out. The behavior is actually the same it turns out. I still think it is wrong however.
I am attaching the 1.12 config. My testforblock is based on setting this NBT tag:
{CustomName:"AA"}/blockdata -141 63 243
Block A's command:
{CustomName:"AA"}/testforblock -141 63 243 command_block -1
Block B's command:
say AAAAAAAAAA
The test used doesn't matter. I had used presence of a torch as well. All you do for the test is switch the CustomName value and click either of the buttons (one for block A or one for B). Block A works OK in that the test is run when its button is pressed. However, change the CustomName and click the button for block B. You have to click it twice but it will make block A's test execute. Even though no redstone is going to A.
UPDATE:
Re-writing the comment I had earlier. I can create the bug on 1.12 as well as 1.13 but I'll give the details for the 1.13 test.
Command block A set to "Impulse", "Unconditional", "Needs redstone". Command is:
/execute if @p[tag=Test1]
Command block B is behind A and is set to "Impulse", "Conditional", "Needs redstone". Its command is:
/say B FIRED
To make A evaluate to true, execute command:
/tag @p add "Test1"
For false, execute:
/tag @p remove "Test1"
In the description above I explain what the behavior is.
Yes, this was introduced in 1.13. I tested 1.12 and it did not happen. Slabs are not transparent. If it is a slab placed on the bottom-half, it is treated like an open block and pathfinds fine but ONLY if there is a block under it. If it is air for example, the mob will not path find over it.
I confirm this bug too in 1.13.2, It's not just animals but mobs too. Any walking entity. The problem only happens when the entity starts its path on a water-logged block (seagrass, kelp near the surface, etc....)
ADMINS: Can you guys please move or delete this bug? I accidentally put it in the wrong version of Minecraft. I am using the Java version, not Bedrock. Thanks!!!
It can? Ok cool. I missed that. Thanks.