Maps on Walls do not Update

Confirmed.

Confirmed
Although I can see where this is an issue, but the way maps are setup from there initial release into the game is that they only update when held by a player. The map in the Item frame isn't updating until a player holds the map because its really just a "image" of the map and doesn't count as someone holding it open. I would say that if it did change all the time, servers would start lagging alot if someone was at your map wall and, lets say 30 players (average for the server I'm on) were making the map update through normal survival. I'm guessing this is working as intended but we may need mojang to say.

I don't think I've ever seen a map in an item frame update in my SSP when I'm walking around or changing things until I take the map (or copy) and hold it in my hand.

I realize this is how it has been acting, but that doesn't mean that it should be that way or intended to be that way. And it doesn't have to update when the chunk is unloaded, or when a player is not viewing it. The philosophy they seem to be taking with the maps is that they should update when the player views them in order to give the player an accurate view without causing unnecessary lag. If you view it this way the problem isn't that it doesn't update all of the time, the problem is it doesn't recognize that a player looking at it on the wall should have the same sort of effect as them looking down at it. What the maps do when they are not viewed and do not effect the player is nothing to the players concern and it really doesn't matter whether they update or not when the player is not looking at it. It is up to Mojang how they want to implement the maps behind the scenes, but part of the goal of most design is to hid the implementation from the user and this clearly does not. It acts in a way that the user would not expect and that reviles the two maps are linked to the same underling java objects. The behavior is incredibly counter-intuitive, it would be like if using one copy of the New York Times to start a campfire would cause every other copy in existence to burst into flames.

I can see how it would create lag if they were to update every map at every change, but that isn't what it would take. As it stands blocks don't update constantly, and when they are out of loaded chunks there is usually no need for them to change. In fact, it probably wouldn't even be noticeable if the maps didn't change when they weren't on a player's screen since it would have the same effect as if they always updated .That is how rendering works in most games, including Minecraft to begin with(meaning unseen surfaces are not rendered). And with that solution, there would be no more lag then if a player simply decided to look at a map. As it stands players are led to believe that maps in frames would be a view of the world around them but, as it stands, the only way to achieve this functionality is to constantly reopen the map to make it render or to get someone else to do the same. By the time you actually get the information that you desired out of the map on the wall you already have been forced to find it by other means.

Then what your asking for is a feature request. Right now these maps are working as intended, they do not update unless a player is holding the map. When a map is placed in an item frame it just takes the data in the map file and displays it. The map writing ability is only given access in the map file when a player is holding the map. Maps in item frames will update if a copy of the map is held by a player, elsewhere in the world.

I wouldn't say that this is a feature request, as most people who don't know the innerworkings of the game will expect the maps to update while on walls. They don't know what causes lag and what doesn't, so they will expect what's natural. If it will for sure create lag to constantly update the maps on the walls, then maybe allow a server command to "flush" a certain map, or force-update it? Then for servers (or players) who wish to have a constantly-updating map, they can use a command block or run the command from the game. This is just one idea, there are obviously more solutions.

This is only a feature request if you consider logical consistency a feature. If buildings disappeared when you weren't looking at them you could call fixing it "adding object permanence as a feature" or if health regeneration stopped every so often if you didn't re log or sleep, you could call fixing those issues "adding features" but in reality they are just inconsistencies in what the player believes should happen. If you have that view then the only thing that would be considered bugs are crashes to the infrastructure of the program that make it close or completely unplayable, and that is such a low bar for programming quality that it would result in a terrible end user experience.

I'm not asking to add a block, or add a new command, or add a new creature, or a new game mode or anything of the sort. I'm asking simply for maps to work how the user would expect, and not in some weird way where two maps are "linked" when the user has no reason to know they would be so that one cannot function correctly without the other. To further show that this is not how it should be working clocks that are put in paintings update constantly, just as if they were in the players hand. Why should clocks work how the user expects, but maps only understood it the player has great knowledge of the underling implementation?

@Th3F4114n0n3:

I understand your point of view, and this is working correctly as the code specifies, but it is not "working as intended" in the long-run. Maps should update automatically no matter where they are (inventory, in the world, etc.) as to not be confusing to players who do not understand game mechanics. I'll let Mojang make the final decision though.

I understand both your points but if the code is working as it was intended by mojang to then what your asking them to do is change the code based on what you beleive it should do not because its broke, which by the definition of this website is a feature request. I'm in full agreeance with both of you that this is how maps should work but as the code specifies and the original intenet of how Mojang made the coding for it then this is a feature of maps that is working correctly.

@Michael the term for working as intended is based on what Mojang intended the item and feature to work, not how everyone beleives that it should. There are several things in game that a lot of people beleive should work one way or another but doesn't due to the intent of Mojang. The things that have changed that were W.A.I. weren't fixed because of a bug report and people agreeing with it being a bug and not W.A.I., but by a posting to the Suggested Feature Request/Changes on the minecraftforums, which Mojang does read. Plus the example of buildings not loading when looking at them is a feature of the game (depending on there distance) as it keeps your machine from having to render to many items at once (rememeber this may not be the highest end game, but its coding is very complicated), this was mojang thinkning of the end user. The hunger thing was a bug at one point as mojang and some users opened the code and found an error in the code specifically(a , on the wrong side of a variable).

@Brian That is what a feature request is. Changing a "as the code specifies" item and making it work the way one/many people beleive it should. There's always going to be people who beleive an item should work one way but doesn't and theres going to be people who know it should work this way as intent. Thats why theres a bug on here about skeletons being able to shoot bows when they have no fingers, track a player when they have no eyes, and even mount a spider when they have no butt (which btw, I found very amusing for some reason). Plus if every game made it so people couldn't be confusing to players because they don't understand game mechanics, we wouldn't have alot of games we have (or they'd just be boring, or basically the same as every other game and no one would play them).

There is no reason to believe this is the intended behavior when other objects that update when the player views them work properly in picture frames (such as clocks). Of course it is doing "what the code specifies", every glitch is doing "what the code specifies" code doesn't have a mind of it's own. But I have a lot more faith in Mojang then to think this is there intended consequence. Why would they make maps a special case when other items in frames update consistently? I guess it's possible that they sat down in a meeting and talked it out and decided that maps behaving unpredictably and illogically would be somehow better, but it is much more likely that they simply overlooked a small adaptation in the system when they added item frames. Mistakes like that happen all the time, and they appear more "stable" then other glitches because in reality all they are is a missed function call (calling an update() method when it's seen on a wall).

Furthermore, yes there are things that appear inconsistent in many games, but they don't try to make objects act that way for no reason, and most often such interactions are glitches. Intentional interactions that the user would find strange are usually explained or somehow make sense within the context of the game environment. If such interactions are not explained to the user then they are completely indistinguishable from glitches. That is the position we are in. No matter if this was intended or not, it seems unintentional; and because it seems like it is unintentional behavior it is correct to report it as a glitch because it is code that is doing what they did not expect it to. Neither of us where in the room when this was written, so we don't know whether it was meant to act in such a weird way, but since players are given no reason to believe they should act this way many see it and believe it is a bug. If it is working the way that they want it,Mojang can just explain that and close this report. If it is not how they intended they can fix it. Until Mojang reacts it is completely useless to argue about their intentions. The reality is illogical enough and without explanation that it could be a glitch, and if it is, then this is the place to bring it to their attention. I am not asking for them to add a feature, I am just bringing something that is likely unintended behavior to their attention. If they intended it to act this way, I am perfectly happy with them explaining why it makes sense and dismissing this as intended behavior.

TL;DR
A bug code acting in an unintended way.
This behavior looks odd and unintentional.
Thus this code appears to be a bug and should be reported to Mojang for their consideration.

Dismissing our bug the way you have without seeing if Mojang intended this as a consequence is using the same "It's not a bug, It's a feature!" that has been used to dismiss countless serious bugs in countless applications. Honestly, it is a waste of our time to discuss this any further until we hear from Mojang; we all agree this happens, let Mojang decide whether or not it needs to be fixed.

I'm not going to get into an argument over this. The fact that you've read into and blown what I've said this far out of proportion is ridiculous. This is working as intended as per the code (not because of a mistake in the code or the code acting unusual per its intent). It is a bug in the sense that it's not doing what you expect. The reason why the clocks a compasses work in frames is because that's the way they are designed to. The maps are designed to only update when being held by a player and displayed (only) when in an item frame, as it's been since their release... When Mojang says other wise I will agree its a bug, but do to the nature of the code working correctly (not in an unusual way because of the code) then I'm going to consider it working as intended. Please stop turning this into a forum, I've explained my point, you explained your point and then attacked my reasoning so im done