Dolphin263
- Dolphin263
- dolphin263
- America/Chicago
- Yes
- No
MC-32480Player map pointers don't work if you reload the world in SP or reconnect to a server in MP
If you disconnect from a SMP server but keep minecraft open, then reconnect to the same server, maps you viewed in your first session stop updating player locations. Your old location still is there, but it doesn't update as you move around. If you quit the game completely, and restart it using the launcher, and rejoin the server, the same maps work again.
Similarly, if you reload a world in single player, you have the same problem.
Note that this is not a dup of
MC-3416. (I get that bug too, if I use framed maps, but this is different.MC-3416requires a server restart to fix, this issue is fixed by client restart.)
If you disconnect from a SMP server but keep minecraft open, then reconnect to the same server, maps you viewed in your first session stop updating player locations. Your old location still is there, but it doesn't update as you move around. If you quit the game completely, and restart it using the launcher, and rejoin the server, the same maps work again.
Similarly, if you reload a world in single player, you have the same problem.
Note that this is not a dup of
MC-3416. (I get thatbug too, if I use framed maps, but this is different.MC-3416requires a server restart to fix, this issue is fixed by client restart.)If you disconnect from a SMP server but keep minecraft open, then reconnect to the same server, maps you viewed in your first session stop updating player locations. Your old location still is there, but it doesn't update as you move around. If you quit the game completely, and restart it using the launcher, and rejoin the server, the same maps work again.
Similarly, if you reload a world in single player, you have the same problem.
Note that this is not a dup of
MC-3416orMC-31731. (I get those bugs too, if I use framed maps, but this is different.MC-3416requires a server restart to fix, this issue is fixed by client restart.)
Dolphin263: It's a bit harder because the right class file will be unknown, but it should be possible.
Edit: In 1.8-pre2 it's offset 0x921@buc.class, 84 07 01 -> 84 07 ff
Edit2: Affects 1.8-pre3, the offset above seems to be the correct one to fix it for 1.8-pre3 too.
Dolphin263: The flag M for jar tells it to remove the manifest (META-INF). And good call, that part is necessary for any modding. The bug (and the fix) is client-side only.
This problem still persists in the latest snapshot 13w38c, and is especially important to fix now, Because framed maps are now able to be stitched together and look so cool, people will want to use them more. However, with this bug, they are unusable in SMP.
Ryan, do you have any framed maps in your world? If so, you may also be encountering
MC-3416, which would explain why you need a server restart as well.confirmed
The GUI console is still broke in 13w41b. Either this bug should be reopened, or another bug should be created for the GUI part.
dddeeeffff, I wanted to comment to let you know it is possible to work around the map bugs. I don't want to minimize them, and I too am really hoping that both major map bugs will be resolved, but in the mean-time try these work arounds:
1) This bug is caused by having maps in both item frames and in player hands. It doesn't seem to happen if maps are only in item frames, or only in player's hands. So my work around for this bug is to separate the two: I have two sets of maps, one for players and one for walls. I have a script that runs when the server is offline that copies the versions in player's hands to the ones that go on walls. Here's my current copymap.bat:
copy /y world2\data\map_0.dat world2\data\map_10.dat
copy /y world2\data\map_1.dat world2\data\map_11.dat
copy /y world2\data\map_2.dat world2\data\map_12.dat
copy /y world2\data\map_3.dat world2\data\map_13.dat
copy /y world2\data\map_4.dat world2\data\map_14.dat
copy /y world2\data\map_5.dat world2\data\map_15.dat
copy /y world2\data\map_6.dat world2\data\map_16.dat
copy /y world2\data\map_7.dat world2\data\map_17.dat
pause
In the above batch script, I copy maps# 0-7 to 10-17. Maps 0-7 are in player's hands, maps 10-17 are on walls in multiple locations. This seems to work well, and works around this issue.
2) The above doesn't fix the other major map bug,
MC-32480. However, that bug can be resolved by completely quitting minecraft when you disconnect from the server (in MP) or reload a map (in SP)Hope this helps!
In particular, player held maps look really bad now – blue water don't look very blue (more like light purple), and it is hard to read.
TheBuzzSaw, how are you invoking the minecraft server? Since they stopped publicizing the windows exe, I had to create a batch file with this line in it to invoke the jar:
"C:\Program Files\Java\jre7\bin\java" -jar minecraft_server.1.7.2.jar
(For some reason, their explanation of right clicking it and selecting run with java didn't work.)
Since I've done this, I have no longer experienced this issue. I can see output from commands in both the dos window that comes up, and also in the main minecraft server window, including the log and chat area on the right hand side. I'm also running windows 7 64 bit running Oracle Java 64 bit, so I don't know what would be different other than how I invoke it...
Yes, if you look at their blog entries, they no longer provide links to the exe's. I think they are discontinuing them because of this known issue, and want people using Windows to use the jar files directly instead. There is no link to the exe from their blog entries, and it says "(On windows, right click -> open with -> java)". However, that didn't work for me... but when I launched it from a batch file like described above, it did work, and it also resolved this issue.
I'd also like to point out that now that framed-maps stretch and allow you to stitch together multiple frames, more people are putting maps in frames. In MP, however, this bug makes these maps unusable. Because framed maps are more desirable in 1.7.x, this bug is becoming more common.
On my server, we are working around this issue by keeping maps either entirely wall mounted, or entirely player held. Map #0-9 are player held maps, and these maps are never mounted on walls. Map # 10-19 are wall mounted copies of Map#0-9. A shell script copies map0.dat-map9.dat to map10.dat-map19.dat during nightly backups. This keeps the wall mounted maps somewhat up-to-date and works around the problem. However, this workaround has the disadvantage that the wall-mounted locations are not available on the player maps, and it's hard to enforce – if a player doesn't understand the process, they can mount a copy in the player range in a frame, and cause a random player to loose their pointer.
Thought we would retest since we had not tried it since upgrading to 1.7 on Minecraft nor 1.7 in java, but the bug is still present. Confirmed in MC 1.7.2 using java 1.7 64 bit on windows. Restarting the server helps for a bit, but eventually the bug reasserts itself. We're going back to using the copy map workaround I described earlier, which we have been using since we started framing maps on our server.
Also, note that the biggest problem that happens with this bug is not the extra green pointer, but losing the player pointers. The player pointer appears behind the map rather than over it, and the map does not update as it is moved around. This means while the player is within the map region and away from the edge, they are invisible, and thus the maps are unusable. If a map is in a frame and you are on a MP server, this seems to always happen eventually, but not necessarily immediately. Restarting the server sometimes fixes the problem temporarily.
Ezekiel, I was the original poster, and this does appear to be fixed in 1.7.4. I tested only the condition I was reported originally... that reconnecting to a server in MP without quitting minecraft lost the pointers, and I was able to see the player pointer after reconnecting.
Thanks!
A few extra notes:
1) It is not just minecraft:prismarine that has the problem. Other items that have the problem inculde a water bucket, a saddle, gold horse armor, an arrow, a potion, a sword. Examples of items that do not have the problem include leather, white wool, netherack, oak wood, an iron shovel, flint-and-steel.
2) Having an inventory item with the problem in your hotbar is sometimes (see next point) sufficient to show the issue. You don't need it to be selected. Having a "bad" item in your normal inventory doesn't seem to be a problem.
3) The placement in the hotbar matters. It appears the only determining factor is the LAST NON-EMPTY HOTBAR slot. If that is a "good" item, there is no problem, even if "bad" items exist in the hotbar. If the last non-empty hobar item is a "bad" item, you experience the problem. If the hotbar is completely empty, you do not experience the problem.
WORKAROUND UNTIL MOJANG FIXES THE PROBLEM: Put a "good" item such as a shovel in your last hotbar slot.
I also still see the issue in 14w26b. As I said before it seems to be dependent on the item in the right-most non-empty hotbar slot.
Update: Bigman1103 said he noticed that it seemed dependent on the number of items in the hotbar slot. After experimenting a bit more, I see think I can see the pattern. Can people who have the bug see if the following rules determines whether you have the problem?
1) Look at your last non-empty hotbar slot.
2) The problem won't exist if that item has damage.
3) The problem won't exist if that item has a count > 1
4) Otherwise (no damage AND count=1) the problem exists
For example, one arrow=bad. Two arrows=ok. damaged shovel=ok. Pristine shovel=bad.
With the above, I no longer think it is inconsistent on what causes the issue, but I will update if I see any counter examples.
I confirm I still see the behavior in 14w26c.
Thanks for fixing this!!!! (Works for me too in 14w28a)
Not sure if the seed is required, but I was able to reproduce the problem from scratch by doing the following:
1) delete my world folder and put level-seed=4031384495743822299 into my server.properties file
2) Jon the server, go to creative mode, and tp to 860 35 -421
3) Put eyes-of-ender into all the slots of the ender portal
4) Go through the portal
I get a similar error when I try to go through a nether portal. This nether portal worked in previous snapshots.
Internal Exception: io.nettty.handler.codec.DecoderException: java.io.IOException: Packt 0/38 (jn) was larger than I expected, found 157696 bytes extra whilst reading packet 38
Confirmed fixed in 14w28b for me.
I'm pretty sure that what is happening here is that if the beacon block itself would be in the field of view of the player (ignoring anything in between / blocking it) then the beacon is visible. If the beacon would be off the screen (usually below the bottom edge of the screen) then the beacon disappears. I've got a deeply buried beacon, so this bug is extremely annoying!
sleepyowlet, yes I agree. The place I was testing had a threshold close to that, but as I get higher, the problem occurs significantly before the block would be in the field of view.
I would say, however, that to reproduce this bug you should make sure the beacon you are testing with is significantly below your current altitude. If I am close in y value to the beacon, I don't notice a problem. The further above the beacon I am at, the bigger the problem seems to be. Since beacons are meant to be buried deeply (their area of affect is larger when they are deeply buried) this bug is likely to be frequently seen.
Altti, that is awesome!!! If they don't fix it in 1.8, could you please post an equivalent once it comes out?
Altti, thanks so much! I played for a few hours yesterday on 1.8-pre2 with your patch, and it worked great!
This seems like such an easy fix for Mojang – hopefully someone there will notice. If there are any mods out there that know how to get Mojang's attention, this seems like it would be worth it!!!
One extra point for newbies for step 5 in Michael's instructions is to be sure to delete the META-INF inside the jar. Altti, I assume your script does that? If so, your script might be the best route for those unfamiliar with patching. Thanks for sharing it!
Edit: After reading the script, it appears it uses the "jar" program to do the update rather than a zip program, so while META-INF is not deleted, the checksums should be updated. Correct?
Also I do have one other question: In a server environment, is this fix only needed on the client side, server side, or both? I think it is client only, but I just want to verify. Thanks!
I have noticed that this happens in multiplayer too, if the structure (in my case end-cities) are partially generated and I shut down the server. I use dynmap on my server, and I have taken to checking it before I shut down the server to make sure there are no end cities on the boundary of generated chunks – and if I see any I fully explore the chunks around the city before shutting down the server. I think the other types of structures are just less dense so it doesn't happen as often as end cities.