![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png)
[Mojang] Grum (Erik Broes)
- grum
- grum
- Europe/Stockholm
- Yes
- No
MC-267![[Mod] Ezekiel (ezfe)](../../../data/assets/gravatar/ezekielelin.jpeg){kind=small}
duplicates
MCPE-1duplicates
is duplicated by
Livestock jumping through 1-high fences
duplicates
is duplicated by
is duplicated by
This glitch allow you to make fireball to stop their speed to 0
This glitch can be done by following the stepst:
1. Spawn aghast/Go to the Nether
2. Wait for aghast to showyou
3. Whillit it's shoting. Press ESC
4. Go to option ancchange the dificulty to Pacefullllllllllll
5. Then Save to Title screen
6. Enter again in the game and you can see the fireballMatrixing in airThis glitch allow you to make fireball to stop their speed to 0
This glitch can be done by following the stepst:
1. Spawn a Ghast/Go to the Nether
2. Wait for a Ghast to shoot you
3. While it it's shooting. Press ESC
4. Go to option and change the dificulty to Peaceful
5. Then Save to Title screen
6. Enter again in the game and you can see the fireball hanging in air
Unable to reproduce. I can kill them fine.
is duplicated by
is duplicated by
anvils/sand/gravel placed on end portals aren't falling into the portal
duplicates
[Mojang] Grum (Erik Broes)[Mojang] Grum (Erik Broes)duplicates
is duplicated by
[Mojang] Grum (Erik Broes)duplicates
[Mojang] Grum (Erik Broes)is duplicated by
is duplicated by
[Mojang] Grum (Erik Broes)[Mojang] Grum (Erik Broes)[Mojang] Grum (Erik Broes)[Mojang] Grum (Erik Broes)[Mojang] Grum (Erik Broes)is duplicated by
duplicates
[Mojang] Grum (Erik Broes)[Mojang] Grum (Erik Broes)duplicates
is duplicated by
duplicates
[Mojang] Grum (Erik Broes)[Mojang] Grum (Erik Broes)[Mojang] Grum (Erik Broes)is duplicated by
duplicates
Low[Mojang] Grum (Erik Broes)[Mojang] Grum (Erik Broes)Font for swedish language bug.Translation problems
is duplicated by
[Mojang] Grum (Erik Broes)[Mojang] Grum (Erik Broes)[Mojang] Grum (Erik Broes)Creative inventory glitch/dupe
duplicates
duplicates
duplicates
is duplicated by
is duplicated by
[Mojang] Grum (Erik Broes)[Mojang] Grum (Erik Broes)[Mojang] Grum (Erik Broes)[Mojang] Grum (Erik Broes)[Mojang] Grum (Erik Broes)[Mojang] Grum (Erik Broes)[Mojang] Grum (Erik Broes)[Mojang] Grum (Erik Broes)Z-fighting of iron bars when placed understairsZ-fighting of iron bars when placed under any block
Book and Quill Bug!Unable to write in Book and Quill after renaming it in an anvil.
is duplicated by
MC-1837
duplicates
is duplicated by
is duplicated by
duplicates
is duplicated by
is duplicated by
[Mojang] Grum (Erik Broes)duplicates
duplicates
duplicates
Breaking things through an open fence gate will close itOpen fence closes after a block touching it updates (eg: gets destroyed)
duplicates
duplicates
is duplicated by
duplicates
is duplicated by
is duplicated by
[Mojang] Grum (Erik Broes)Bug of the JungleAnimals sometimes spawn within leaf-blocks in the jungle
duplicates
duplicates
duplicates
is duplicated by
duplicates
duplicates
is duplicated by
Creative bugSticky shift
duplicates
is duplicated by
Food eating bugEating food sometimes consumes two
duplicates
Transparent worldSlow loading chunks
duplicates
is duplicated by
is duplicated by
duplicates
is duplicated by
is duplicated by
duplicates
spooky cowPartial transparant entity
duplicates
is duplicated by
duplicates
is duplicated by
duplicates
Report X360 bugs on http://minecraft.net/bugs
No eating animation in 3rd person
Bad Blaze SoundSound glitches when many sounds are supposed to play
Sound glitches when too many sounds are supposed to play
[Mojang] Grum (Erik Broes)[Mojang] Grum (Erik Broes)[Mojang] Grum (Erik Broes)duplicates
duplicates
is duplicated by
You cannot have '!'s in your user name / profile name, this breaks java horribly.
This is something we cannot control or fix
You can fix it by not having '!'s in your user name / profile name name.
For more information on how this bug can be fixed on your side, see https://minecrafthopper.net/help/special-characters/
This bug was submitted to Oracle in 2001 and still awaiting to be fixed: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4523159
Downloaded the 1.6 launcher last night, and after the files were downloaded, I attempted to start the game. Basically, it threw a bunch of code(and since I'm not particularly learned in Java coding), I have no idea what it means, save that there was an error of some sort.
After looking around for a while the only other players having this error are apparently on macs, which I am not; I'm running Windows 7 64-bit. I've updated Java to the latest version in both 64 and 32 bit.
Also, if it means anything, prior to the new launcher I was having the "can't connect to Minecraft.net" error, which has apparently been resolved in this launcher.
nope it's still an issue, I just experienced it. But [Mojang] Grum (Erik Broes) and [Mojang] Nathan Adams. your crash system works perfectly!! my mc crashed and it send me straight to this page. hats off! 
Some strings are not translated because they are not currently available on Crowdin. I'm talking about:
Presets in Superflat Customization > Select a Preset that are in English and aren't translatable on Crowdin.fixed in 1.11The text in debug menu (F3) is also not translated.Mod edit: It's a debug screen, only for testing purposes, not for normal gameplay.The biomes in the biome slider (Customized world) also doesn't have translation.Invalid according to [Mojang] Grum (Erik Broes).- The Elder Guardian as well – Unable to find this one [Mojang] Grum (Erik Broes).
Default empty world name is "World"Invalid according to [Mojang] Grum (Erik Broes).Commands in spectator mode ("Press a key to select a command, and again to use it.", "Teleport to player", "Teleport to team member", "Next Page", "Close menu")fixed in 1.11Options -> Graphics settings -> "Entity Shadows"Fixed in 1.9New 1.8.2 / 1.8.3 Statistics (Fixed in 1.9MC-77880)Potion item does not translate since the removal of data valueFixed in 1.9The new error message added in 16w02a: "Invalid damage property. Please pick in [Valid Blockstate Numbers]"Message got removedThe new debuging messages, for example "[Debug]: Reloading all chunks"fixed in 1.11A number of subtitles: Are at cowdin, but not translated in game yetFixed in 1.9.2Video settings: chunks and FPSfixed in 1.11"Color" on dyed armor in advanced tooltipsfixed in 1.11"NBT x tag(s)" in advanced tooltipsfixed in 1.11"Unable to load world" screen is not translated at all (outside of the cancel button)fixed in 1.11
While typing a command into a command block, if you press either the up or down arrow key, it will insert an invisible character into the command block that can cause the command to not execute correctly.
Steps to Reproduce:
1. Place down a command block
2. Type in a command, like "/say" then type the up or down arrow, then continue with " hi"
3. Power the command block with redstone and it says unknown command because pressing the arrow key inserted a character after "say", so the command block saw "say(character here)" and didn't recognize the command. (An invisible character was inserted into the command. You can tell because if you hit backspace on it, then the cursor doesn't move.)
Or, alternatively:
1. Place a sign
2. Enter some text on the first line
3. Hit the down arrow to switch to the second line
4. Hit the up arrow to go back to the first line
5. Hit backspace, nothing happens - only when hitting backspace again or typing something before will backspace work
Also affects book and quills.
Postponed until Minecraft has updated to LWJGL 3 according to [Mojang] Grum (Erik Broes).
ezekielelin@PixelPower ~ $ /usr/libexec/java_home -V
Matching Java Virtual Machines (4):
1.8.0_20, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_20.jdk/Contents/Home
1.7.0_51, x86_64: "Java SE 7" /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home
1.6.0_65-b14-462, x86_64: "Java SE 6" /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
1.6.0_65-b14-462, i386: "Java SE 6" /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
/Library/Java/JavaVirtualMachines/jdk1.8.0_20.jdk/Contents/Home
[Mojang] Grum (Erik Broes): have you heard back from LWJGL yet? If not, it might be better to just remove the F11 shortcut, as suggested by Finn Wilke.
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
I agree that recent additions to the game, such as blocks of redstone and slimeblocks, provide alternatives to at least some of the buggy piston behavior. However, Grum has said that it probably won't be reconsidered unless it can be shown that all, or at least most, of the devices that depend on this bug can be reproduced without it. See this comment for an explanation.
The current behavior makes independently controlling pistons that are stacked on top of each other impossible in almost all cases. I believe I've seen one design that depended on manipulating block updates, only worked on a single tower, and still required activating undesired pistons to reset it.
Ideally, the current behavior would be replaced with something intentional, intuitive, and consistent. It may be some time before such mechanics are implemented, however. As multiple people have commented, including [Mojang] Grum (Erik Broes), it would be very helpful to have a list of the devices that depend on the current behavior, so we could determine what solutions need to be developed. With all the people interested in seeing this fixed, it should be possible to produce such a list, and alternative designs that don't depend on the current behavior.
It's simply how [Mojang] Grum (Erik Broes) decided to fix MC-8220, MC-3737, and many others. Placing water "breaks" the block it replaces, so that it drops them as items if appropriate. This happened with water and lava for a while (See MC-18365), but Grum was able to fix that, so I'll bring this ticket to his attention and see if he wants to revisit this.
As far as I can tell, "java.net.SocketException: Protocol family unavailable" means that it's trying to bind an IPv4 socket to an IPv6 address (and obviously failing). The "BindException" errors [Mojang] Grum (Erik Broes) mentioned appear to be what happens when an IPv6 socket attempts to bind to an IPv4 address, and fails (among other things).
The underlying problem may be Java. An IPv6 socket is supposed to be able to communicate with both IPv4 and IPv6 peers, but it may be OS- and implementation-dependent.
Minecraft.exe/Minecraft.dmg/Minecraft.jar are all the "bootstrap". The first two are native code for the relevant OS, and the last is platform-independent Java. They're intended to be updated very infrequently, preferably never, because it's apparently difficult to make them auto-update due to security/permissions/sandboxing or something. All the bootstrap does is download and run launcher.jar, which is how they are able to automatically update the launcher.
You'll get an error like "MCO Availability Checker #1/ERROR: Couldn't connect to Realms" when using any version that's not realms compatible, such as snapshots. It is interesting, however, that it's coming from the client, and yet you later receive a "Protocol family unavailable" error. It looks like you're trying to connect to a local IPv6 address (::1). What happens if you try to connect to a remote IPv4 address?
I would have hoped that all of this would have been cleaned up when the networking code was switched to netty, rather than IPv6 support being broken in the process. I'll have to see if I can get one of the devs to take a look at it.
[Mojang] Grum (Erik Broes) has decided to take another look at this. It's not a high-priority item, so it may take a while to get around to it, but he thinks he should be able to do it.
I would personally prefer if stone stairs were renamed to cobblestone stairs, for consistency and ease of searching, as you've brought up. I suspect they're named this way partially to deflect the frequent requests for actual "smooth" stone stairs, which [Mojang] Jeb (Jens Bergensten) is strongly opposed to adding.
[Mojang] Grum (Erik Broes) has taken interest in some naming or spelling tickets before (such as MC-19032 or MC-2453), so I'll reopen MC-3100 and see if someone from Mojang will be willing to address it. Don't be too surprised if they mark it "Working As Intended", however.
When I last asked [Mojang] Grum (Erik Broes) about it, they were all neck-deep in merging about 3 months worth of code from several members of the Minecraft team for snapshot 14w25a. They've been a bit busy since dealing with the large number of resulting bugs. I'll bring it to his attention again when things cool off a little. Any testing or research we can do in the meantime will help.
One of the obstacles is that the bootstrap (minecraft.jar) needs IPv6 support – as MCL-2627 shows, you can't even download the launcher (launcher.jar) if you don't have IPv4 connectivity. And the bootstrap can't be updated automatically, so they're reluctant to make any changes to it. There are three different versions of the bootstrap: a native Windows binary, a native Mac binary, and a Java version as a catch-all for anything else. It's possible that the Windows and Mac versions of the bootstrap don't have this problem, though they may also deliberately disable IPv6. I think they might just package up the Java version and run it, and are just there for people who have trouble launching jars directly.
Unless this documentation is wrong, your sample code isn't going to accomplish anything. java.net.preferIPv4Stack is only read at VM startup time, so setting it using System.setProperty() is pointless, because the VM is already running. I guess it might be inherited by a child VM. Or maybe the documentation is flat-out wrong. It seems like it's wrong on what the preferIPv6Addresses setting actually does.
It looks to me like the launcher and the game run in separate VMs. I vaguely remember reading somewhere that the launcher passes "-Djava.net.preferIPv4Stack=true" in the command that runs the game, which might be why setting it to false in the JVM argument box wouldn't work. I also don't know how or if those settings affect Netty, though I suspect that there's more to it than that, since reportedly the client did work on IPv6 before the switch to Netty. I would guess that the realms checker doesn't use Netty, which is why it works(ish) with your wrapper. So most likely the network code in the client is written to explicitly use IPv4, and thus doesn't respect the system properties.
Look at the Resolution, not the Status. It's marked Works As Intended. You're not supposed to be able to acquire these blocks in your inventory. They were a bug that disappeared when they changed how items were defined. However, [Mojang] Grum (Erik Broes) has said they might change their minds on this, and several other blocks that are now unobtainable, and add them back into the game officially, with a proper item and crafting recipe.
[Mojang] Grum (Erik Broes), which Java version are you using? Try switching to 1.6 and see if you can reproduce it.
[Mojang] Grum (Erik Broes)'s comment:
Now the block remembers its 'shape' when it started falling. When it lands it will take the final shape it will get as if it was placed there.
The bug
When FallingSand falls, it changes its texture for every block position it passes instead of using the texture from the block where it started and then only changing it once it landed.
How to reproduce
Use the following command to summon FallingSand above you and watch it fall
/summon FallingSand ~ ~20 ~ {Time:1b}
[Mojang] Grum (Erik Broes) in MC-62166:
Use 29a for more consistent behavior. 29b is just a 'threaded batching of chunkdata to renderbuffers'-experiment.
See [Mojang] Grum (Erik Broes)'s comment in MC-62166;
Use 29a for more consistent behavior. 29b is just a 'threaded batching of chunkdata to renderbuffers'-experiment.
If your issue is gone in 14w29a, then it's the same.
An in-game composition window would be preferable, but if external floating windows are what foreign language users are used to, in Minecraft or other software, then it may not be as much of a problem as [Mojang] Grum (Erik Broes) believes it to be.
There's an interesting comment here about the use of getEventKey(), specifically that the LWJGL documentation recommends this instead:
(Keyboard.getEventKey()==Keyboard.KEY_NULL) ? Keyboard.getEventCharacter() : Keyboard.getEventKey()
The same information is present on issue 59 at the LWJGL bug tracker. This may also fix the issue of Minecraft ignoring keyboard input when an IME is enabled.
The comments in MC-30704 contain some more information and code to fix the problem for other non-English keys, and may also fix this issue as well.
See the comment of [Mojang] Grum (Erik Broes) :
Server sends chunks in suboptimal order sometimes because it generates them in a suboptimal order. There are no holes, this is what the client knows at that moment.
Well, this probably fixes MC-11519, though [Mojang] Grum (Erik Broes)'s notes suggests the change wasn't made specifically for that reason. I'm a little surprised it doesn't appear to have fixed MC-460, since that is reportedly caused by a client-server position mismatch.
Control+Left-Click triggering a right-click is handled by LWJGL. They broke it, [Mojang] Grum (Erik Broes) hacked together a temporary fix for 1.6.2, which he then pulled once the issue was fixed in LWJGL. So in the current release of Minecraft, it's completely transparent to the Minecraft code. On a Mac, it receives a right-click event from LWJGL, and doesn't even know that it was actually Control+Left-Click. So it would not be possible to make this an option anymore, unless LWJGL exposes such an option in their code.
The option you do have is to change sprint to a different key.
MC-2292 suggests that [Mojang] Grum (Erik Broes)'s hack is no longer in effect, or never actually remapped control to command like he said it would. And yet ctrl+Q still doesn't work on Macs. We have an open issue for that too.
[Mojang] Grum (Erik Broes) could have marked it Invalid himself, if he so chose. Or Won't Fix. But he left it open. I think his comment was only to let people know it wasn't a high priority, or something they were going to actively try to fix. If some novel idea on how to fix it occurs to them, they might implement it, but it's not something they're going to focus on.
[Mojang] Grum (Erik Broes): I saw delays of 10 to 20 frames when I just tested 1.8-pre1. I maxed everything out and disabled random ticks to get those chunk updates to zero and to make sure the server can take it, but to strain the client. Eventually I was looking at a huge jungle with render distance 32 which dropped me to 7 fps. Depending on where I placed a door opening or closing it produced 1 to 4 chunk updates (I suppose up to 8 if you pick the right spot). The integrated server was fine because the hitbox changed and the sound played instantly. But the visual update would often take one or several seconds. I didn't move and kept my mouse perfectly still. I saw only the occasional spurious chunk update (sheep eating grass or something), so I don't think the chunk update limited mattered.
Oddly, reloading the game got me up to 13 fps. Even when I looked all around me to display every single chunk at least once and turned back to the jungle it remained at 13 fps (if you fly around it does become slower over time but I guess one 65x65 area isn't enough). Well, during the previous run I noticed a sudden frame rate drop which would probably explain the difference if you could figure out why it happened (no RAM pressure; maybe VBOs overloading VRAM?). Updates could still take a second or so, but in slightly offset locations were pretty much instant as you describe, even with 4 chunk updates per click. At least it beats updates being deferred indefinitely. I can't rule it out based on such limited testing under deliberately limited conditions, however.
Why do chunk updates slow to a trickle when the frame rate drops, anyway? Especially at low frame rates they tend not to be the bottleneck; you could probably process at least tens per frame unnoticed. The current limit is a good way to test the limits of the engine, but it's not so good that the world takes unnecessarily long to load if you just want a nice view regardless of frame rate.
Just for completeness:
Graphics: Fancy
Render Distance: 32 chunks
Smooth Lighting: Maximum
Max Framerate: tested both 60 fps and Unlimited; doesn't make much of a difference when you can't hit either
3D Anaglyph: OFF
View Bobbing: OFF
GUI Scale: Auto
Brightness: Moody
Clouds: OFF
Particles: All
Fullscreen: OFF (but I used OS X's rightmost title bar button, which makes a kind of fullscreen window)
Mipmap Levels: OFF
Alternate Blocks: ON
Use VBOs: ON
Noproct: Jitter as in the moment the world changes near you, the game halts for a short amount of time. The effect probably depends on your current bottleneck.
[Mojang] Grum (Erik Broes): Yeah, 32 chunks isn't very workable. Your hypothesis about the cause of the delay is utterly wrong, though. The server was running at full speed after all chunks had been loaded (only one "can't keep up" message skipping three seconds, showing up three seconds after joining). Things like block placement made a noise immediately (these sounds are server-controlled, if you didn't know).
Regardless, this bug is about the disparity between the internal model of the client (which you can probe by bumping into it and aiming at hitboxes) and what it renders. That is what I tested; it wasn't the server causing the textured door to update 20 frames after the hitbox did. It can potentially rubber-band you if you walk into an obstacle only it knows about so far, but that wasn't what happened. Many reports here are detailed enough to say that wasn't what happened there, either.
Also, assertions like "it should be delayed by at most one frame" (I assume there have been no further changes in 1.8-pre1 since you didn't mention any) should be true regardless of whether or not you like the render distance. If you can't explain it, it's plain wrong and you'd better figure it out. If, on the other hand, immediate updates were disabled and we'd have to rely on ordinary chunk updates which are kept artificially low (for example), it may work as expected but still be a design flaw.
One more thing: Of course I don't normally overload the system like this. But should overloading be an invitation for anything other than proportional slowdowns or growth of memory usage? If it is, the system should be more robust. Remember exceptional cases occur all the time; deliberately looking for them only makes them easier to identify so you can reduce their (arguably smaller) impact on 'normal' use, with the added bonus that you can explore the limits if desired.
@[Mojang] Grum (Erik Broes) what do you mean by "Invalid item"?
Can confirm this in 1.8 at least.
@[Mojang] Grum (Erik Broes): Those blocks still show up in the superflat customization, even if you can't get them in item form, so they should have proper names.
There you see how hard some bug are to fix. [Mojang] Grum (Erik Broes) is fixing since 20/Aug/14.
Because we are almost sure that this bug is caused by water, I am (also) posting this here: [Mojang] Grum (Erik Broes) is trying to fix the immense water lag at http://www.reddit.com/r/Minecraft/comments/2k3rg6/water_woes/cli9h2k.
[Mojang] Grum (Erik Broes) is trying to fix the immense water lag at http://www.reddit.com/r/Minecraft/comments/2k3rg6/water_woes/cli9h2k.
@[Mojang] Grum (Erik Broes): Stop troling, there is no version 1.10 in the "Unreleased versions" list
[Mojang] Grum (Erik Broes) wrote:
Yeah, when you limit your fps chunk-loading is slow now :/ Something we should fix now it works better on slower machines.
[Mojang] Grum (Erik Broes) commented in MC-21433
Indeed. Works as intended.
For feature suggestions or changes please see: Minecraft Suggestions on Reddit.
[Mojang] Grum (Erik Broes) in http://www.reddit.com/r/Minecraft/comments/2sirzn/searge_on_twitter_minecraft_182pre2_is_now/cnq14ox
The server has been creating chunks at the same pace as ever. We're uploading less chunks to the videocard at every frame to spare older systems from getting major loading fps dips. Downside is that things now load a bit slower if you have a massively fast system. Removing Vsync and using a high fps limit (higher than 60) should make loading 'fast like before' if you have a system that handles it.
[Mojang] Grum (Erik Broes) in http://www.reddit.com/r/Minecraft/comments/2sirzn/searge_on_twitter_minecraft_182pre2_is_now/cnq14ox
The server has been creating chunks at the same pace as ever. We're uploading less chunks to the videocard at every frame to spare older systems from getting major loading fps dips. Downside is that things now load a bit slower if you have a massively fast system. Removing Vsync and using a high fps limit (higher than 60) should make loading 'fast like before' if you have a system that handles it.
@kasamikona: [Mojang] Grum (Erik Broes) said:
Confirmed for every version upto 1.10.
Means: Cannot be fixed until Minecraft 1.10
KingSupernova, even if "Won't Fix" was a more appropriate resolution, it was [Mojang] Grum (Erik Broes) who resolved it as "Works As Intended", and thus we won't be changing it unless directed to do so by Mojang. Beyond that, while [Mojang] Grum (Erik Broes) has stated that he shares the opinion that this is a bug, it would appear that [Mojang] Jeb (Jens Bergensten) and [Mojang] Nathan Adams both consider it to be intentional behavior.
So its normal that with 14w33c version and before, there was no problem with signs color ? And that since 14w34d, it s ugly ? It s an intended behavior really ? _
[Mojang] Grum (Erik Broes)
Confirmed for
- 1.8.6 [Mojang] Grum (Erik Broes) can you please explain that resolution? Other blocks which aren't accessible in the creative menu like the command block support pick block
Fixed, as per MC-83724. Thanks [Mojang] Grum (Erik Broes)!
![[Mojang] Panda](../../../data/avatars/users/41658.png){kind=small}
@[Mojang] Grum (Erik Broes)
I get that there are repositions and I agree for the most part that they are a good thing.
But the one in the head slot of an armor stand which is visible in the bottom right of C.png
doesn't make sense and breaks stuff.
That the item is higher is good and is something we can adapt to, but why isn't the item in the center of the armor stand, but instead set back?
Please consider changing that unless there is a good reason.
Thank you 
@[Mojang] Grum (Erik Broes)
Yes, it looks good for players/mobs. I fully agree with that.
But not for armor stands. For armor stands it would look good if they were centered and enable people to keep doing their creations.
Thanks a lot for replying
[Mojang] Grum (Erik Broes) That would only be true if you consider being on top of the Nether as game-breaking. Having the bedrock barrier be passable through clever use of the Chorus Fruit could be considered a nice secret.
![[Mod] NeunEinser](../../../data/avatars/users/39263.png){kind=small}
@[Mojang] Grum (Erik Broes)
I actually think we are not the only ones who think, that change is really gamebreaking and not just a slight Change.
This breaks a whole bunch of Adventure Maps and some cool and creative contraptions.
Why did the block positioning changed like that? I don't understand the reason if you don't tell that to us. And you must have a big reason to break so many contraptions.
~NeunEinser
[Mojang] Grum (Erik Broes) Can you please make it so that
{text:"text here"}
works again? or at least tell us the reason why you won't change it back and give inconsistency troughout json commands in minecraft, and breaking a lot of 1.8 minecraft maps.
You have wildly misinterpreted my comment on MC-58445. It was never intended for you to be able to define textures for "unused" or "out of bounds" damage values. That the game even attempted to treat them as valid items was a bug. The feature [Mojang] Grum (Erik Broes) is currently adding to resource packs is only intended to allow you to customize currently existing states for currently existing blocks and items, not define new ones. That would be part of the plugin API, which has not been implemented yet. I'm sorry for any confusion.
Thanks Christie N for confirming!
It seems the memory usage jumps by about 600 MB each time I exit a save and load it again, eventually running out of memory even with 4 GB XmX… Bad memory leak indeed. Good luck [Mojang] Grum (Erik Broes)! ^^
There are two basic motivations to declare something "Works As Intended", but only one of them is obvious to a non-programmer: the code produces the desired end result. However, in some instances, a programmer may care more about how the result is achieved than the result itself: they probably want the code to be elegant, easy to read, understand, and maintain. They may care more about performance than accuracy. Doing things the right way is sometimes more important than getting the right result. Catching corner cases can be both computationally expensive, and make it harder for them to update the code in the future without creating more bugs. If the undesired result doesn't interfere or disrupt their intended use case for the software, then it may make more sense to the programmer to not handle that corner case.
Here's the relevant history, as I understand it: The mob AI was originally built directly in the mob code, inherited when possible from one mob to another, with mob-specific behavior scattered throughout various functions. Jon Kågström was hired to write a generic artificial intelligence system, and built the basic targetting and pathfinding code before being moved over to Scrolls. Only a few mobs used this new code for a long time, with the remainder only being switched over fairly recently. However, it only handles very generic behavior, and all the unique behavior for each mob type is still buried in their respective classes, completely unconnected to the AI system, and therefore not controlled by it. The NoAI tag does one very specific thing, and that's disable the AI system for that entity. That's all it's supposed to do, and how that affect's the mob's behavior depends entirely on how much of that behavior is controlled by the AI system. From a programmer's perspective, that part's Working As Intended. The code that reads the tag, and the code that disables the mob AI work exactly as they're supposed to. The mobs just aren't designed correctly, because the AI system isn't developed enough to handle their specific behavior.
The right solution, and presumably the eventual goal, is to expand the AI system to cover a wider variety of behavior, and then rewrite the mobs to use it for all that behavior, removing all the special-case code scattered throughout their classes and consolidating it in code that interacts with the AI. That would be elegant, and far more maintainable. But the developers don't have time to do that right now: they're busy doing things like overhauling combat and the world storage format. Hacky solutions like scattering !this.isAIDisabled() checks throughout the code don't make the code more correct, even though they make it produce the desired behavior. They just increase the technical debt, make it even more work to eventually do the right thing the right way: expand and use the AI system. They're still trying to dig their way out of a massive pile of technical debt, and throwing a few shovelfuls more on top may not slow them down that much, but it still isn't going to help them get there any faster.
To summarize, [Mojang] Searge (Michael Stoyke) has marked many of these bugs as Won't Fix, and instructed us to do the same, because they don't view them as bugs so much as features they've yet to implement. The part they have implemented works correctly. The other parts they just haven't worked on yet. They could put in ugly temporary code to make it work how people want it to, but it's not a productive use of their time. This will eventually get "fixed", not as a result of deliberately setting out to fix it specifically, but as a byproduct of restructuring the code. They have done a lot of work on entities already in the 1.9 snapshots, moving code up the inheritance chain, like how mobs hold and use items. [Mojang] Nathan Adams has recently tweeted about working on the AI a few times. Maybe they'll get to upgrading the AI system in time for the 1.9 release, if [Mojang] Grum (Erik Broes) stops breaking worlds with every snapshot .
[Mojang] Grum (Erik Broes) Awesome news! Thanks for the heads up!
Unfortunately based on word from [Mojang] Grum (Erik Broes) himself on MC-1230 this is now the intended functionality.
Things will not get pushed up when they get stuck in a block. They will prefer to fall down.
I think the current behaviour is at least predictable
[Mojang] Grum (Erik Broes)
I found a few minor issues probably related to this fix: MC-88863 and MC-88870.
Also for block 36 there is an issue where it rather uses the hit box of the block than the collision box, I think.
So if you have something standing on top of fences and move the fences sideways with a piston below it, it falls through. (Because the block 36 of the fence is just 1.0 blocks tall, not 1.5 as the collision box)
This might not be new, but I guess it is still related to the change.
Surprisingly few bugs for the far reaching change though :-P
[Mojang] Grum (Erik Broes) Mr. Broes, would you be so kind to add an additional column (or any of the mods) and mark those fixed which you fixed, and those which you won't fix for your mentioned reasons, also add the according text in that additional column?
Thank you!
[Mojang] Grum (Erik Broes) PS: Alternatively, it would be nice to know their fixed/changed/remaining overall size, height as well as width.
This information is crucial for farmers and also the tech community, e.g. for mob farms.
Panda or a mod could add that info then into the additional column, for everyone to see.
Thank you!
[Mojang] Grum (Erik Broes) Thank you 
I will update the list after the next snapshot, with the ones that still seem odd.
After that you maybe can just put an "intended stamp" on the ones that got good reasons to be that way as Meri suggested
Meri Diana
I planned to do so anyway, but didn't get to it yet. It would be easier to wait for a full release with MCP to do that though.
Interesting. [Mojang] Grum (Erik Broes) has talked about overhauling how redstone is implemented for various reasons, but hasn't gotten around to it because they've been busy with other massive changes to the game engine. Considering Notch's coding style, the current implementation was probably designed as a brute force approach to ensuring signals propagated correctly under all circumstances, knowing that a more efficient solution probably existed, but not wanting to expend the effort to find it unless necessary. You say that this is a simple fix, can you provide some code examples of the necessary changes?
[Mod] redstonehelper I think they were missing, I just updated the list. But your comment just got me to think about it again. I will update the list again, trying to explain why some mobs probably won't get an exactly fitting hitbox.
In the case of witches for example, they always fit below 2 high spaces. So it probably is intended to stay that way, so their head doesn't count. That is of course just speculation, but it makes a lot of sense and seems to me like [Mojang] Grum (Erik Broes) thought ahead there
Nick Denton Which version? It seems to be fine in 15w39c
Comment of [Mojang] Grum (Erik Broes) on reddit
Nothing wrong here.
It's should be a debug statement not warning.
It is just saying it has to allocate bigger buffers. Some versions ago we had some issues with stubborn buffers that refused to grow. The messages you see were added for debugging.
It should all work fine now
You can trigger it yourself be making a 16x16x16 area in 1 chunk section from fences or slime blocks
[Mojang] Grum (Erik Broes) Doesn't that ignore the second argument, regarding its use to mapmakers?
This is a feature. See comment by @[Mojang] Grum (Erik Broes) on MC-135 for more information.
[Mojang] Grum (Erik Broes) May we know, why this is intended?
Excuse me, [Mojang] Grum (Erik Broes)
Would I be able to get permission to let users have the resource pack hotfix for their 1.8.x versions?
I'd happily replace my game name with a Mojang listing in the zip's pack.mcmeta, please let me know if this would be acceptable to mojang,
And thanks in advance.
To [Mojang] Grum (Erik Broes):
I would appreciate the related issues being resolved as well
MC-33304 is resolved:
[Mojang] Grum (Erik Broes) made changes - 21/Jan/15 7:49 AM
| Status | Reopened [ 4 ] | Resolved [ 5 ] |
| Resolution | Works As Intended [ 6 ] |
[Mojang] Grum (Erik Broes) added a comment - 23/Jan/15 6:32 PM
The reason is because you are using colors. Because you are you are also responsible for picking colors you can see well.
okay, so JSON-texts get not converted into NBT. That's interesting. So thanks, [Mojang] Grum (Erik Broes) for answering here.
@[Mojang] Grum (Erik Broes): Under MC-72390, I have a PoC script that is tested and, via Rcon, will crash a server with a ConcurrentModificationException; though I'm not sure if that bug is caused by this one. They're almost certainly related, however.
@jonathan2520: do you have further details about how this issue relates to MC-72390?
@[Mojang] Grum (Erik Broes): I managed to make a quick hack in Java (which I don't normally use a lot, so I'm not going to make a full-fledged client). I'm attaching it. Be sure to set the static variables in the source.
@TerrorBite: This is unrelated to MC-72390. They're just both more problematic the more you send.
[Helper] Michał that's of no help at all...
[Mojang] Grum (Erik Broes) can you explain why this is all of the sudden intended?
[Mojang] Grum (Erik Broes) Can this please not be closed? I get that its probably not something you want to spend time on, but it's still a problem regardless.
Can we leave it open incase Searge or someone else feels like fixing it?
[Mojang] Grum (Erik Broes) what you are asking for rather sounds like MC-85627
Like I said in my comment above commands placed by setblock still default empty lines to "null". This was also the case in 1.8.8
Confirmed for
- 15w47c
[Mojang] Grum (Erik Broes) always makes these weird/funny but correct statements, but this is intended, is what he's kinda saying
@[Mojang] Grum (Erik Broes):
Yes.
Source version: 15w47c
Last version: 15w47c
Command used:
/setblock ~ ~ ~ minecraft:standing_sign 0 replace {Text1:"Hello !"}
Affected world attached: ^sign-null.zip
This is because minecarts can rotate, and hitboxes can't (as of now), in order for this to be fixed mojang needs to switch to OBB for hitboxes, instead of AABB, and that is a major change, [Mojang] Grum (Erik Broes) has show intrest in this tho, but until then this is working as intended
See MC-91376
This is because boats can rotate, and hitboxes can't (as of now), in order for this to be fixed mojang needs to switch to OBB for hitboxes, instead of AABB, and that is a major change, [Mojang] Grum (Erik Broes) has show intrest in this tho, but until then this is working as intended
See MC-91376
I agree with Warren Liddell here, [Mojang] Grum (Erik Broes) can you at least make a gamerule or server propperty that disables any MC debug/warning messages?
I request you take another look at this, [Mojang] Grum (Erik Broes), because it just limits what map makers can do, and it provides inconsistency
I request you take another look at this, [Mojang] Grum (Erik Broes), this is going agains what the gamerule implies it should do
[Mojang] Grum (Erik Broes) marked this as intended, not a modderator
@[Mojang] Grum (Erik Broes) Hello... Can you hear me... I was wondering why this issue was marked as Works As Intended...
Re-emphasized [Mojang] Grum (Erik Broes)'s comment:
It now only accepts proper json for each line and each line has to exist.
It will show as an empty sign otherwise.
[Mojang] Grum (Erik Broes) made changes - 24/Nov/15 10:26 AM
Resolution Works As Intended [ 6 ] Status Reopened [ 4 ] Resolved [ 5 ]
source enough
[Mojang] Grum (Erik Broes) made changes - 24/Nov/15 10:26 AM
Resolution Works As Intended [ 6 ] Status Reopened [ 4 ] Resolved [ 5 ]
Source enough ?
Edit: user-f2760: LMAO
[Mojang] Grum (Erik Broes) in MC-9488:
Whatever is in the splashes is intended, how broken it might seem
[Mojang] Grum (Erik Broes) Not asking for a high amount, but a mere 32 for example would be a sane limit
As said, there are cases where players with 15-16 character names can not write their name on the sign due to character width.
I really believe its beneficial to let them write the name and let the client truncate as it does for any sign created pre 1.8 with names that no longer can be typed.
For servers that read data off the signs, its game breaking when some players can not have their name written on the sign without resorting to third party resource packs.
All I'm asking is to remove the need to use 3rd party resource packs to achieve a sane result of a mere 16 characters on a sign.
This isn't a minecraft bug, see [Mojang] Grum (Erik Broes)'s comment
[Mojang] Grum (Erik Broes) added a comment - 26/Dec/12 5:32 PM
LWJGL issue, we can't help it as we cannot update right now.
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
Could this be helpful [Mojang] Grum (Erik Broes)? https://redd.it/42glrg
it does, but as [Mojang] Grum (Erik Broes) said before:
[Mojang] Grum (Erik Broes) added a comment - 24/Oct/15 10:08 PM
The model gets assigned randomly in the world, not possible to sync this up.
[Mojang] Grum (Erik Broes) have you considered using the fix provided in this comment?
This was working as intended according to [Mojang] Grum (Erik Broes).
[Mojang] Grum (Erik Broes), the only situation I commonly ran into the issue in practice was Apples and Saplings from tree. Will the changes in 06a alleviate these incidents?
As [Mojang] Grum (Erik Broes) said,
so this won't be reopened, and it's already listed as affected, so no need to say that at all
When this actually is fixed depends on the next asset deployment!
You don't need a crystal ball, just the history of this ticket 
[Mojang] Grum (Erik Broes) made changes - 2 hours ago
Resolution Fixed [ 1 ] Fix Version/s Future Version - 1.9+ [ 15516 ]
[Mojang] Grum (Erik Broes) this is definitely present in 1.9 pre-2
As you may notice, a fix was already attempted in 1.7.3, and [Mojang] Grum (Erik Broes) is assigned.
The camera only changes vertically when you start flying, it doesn't move forewards, so there is no problem there.
As for the fix, if they wanted it differently, they would have made it differently.
This might be changed in the future ([Mojang] Grum (Erik Broes) has shown intrest in changing the hitbox system to account with rotation, etc) but as of now, it's intended behaviour.
Game currently uses AABB, to change to OBB is not a super trivial thing to do, we might consider the major work involved to do it in the future however.
Until such time, this ticket is sadly WorkingAsIntended.
duplicate of MC-64634, see [Mojang] Grum (Erik Broes)'s bottom comment
like [Mojang] Grum (Erik Broes) said:
It doesn't work for the ones without blockmodels
water/lava has no block model files
![[Mod] Les3awe](../../../data/avatars/users/79847.png){kind=small}
Possible cause:
[Mojang] Grum (Erik Broes):
Arrows have a bounding box that is much bigger than you think and actually sit inside a block.
It may, or may not be, mojang may fix that issue by printing it cursive everywhere instead, and then this can be considered inconsistant.
If mojang didn't want it to be cursive, then [Mojang] Grum (Erik Broes) would've marked this as intended instantly, instead of just assigning it to [Mojang] Searge (Michael Stoyke).
Reopened, and changing report to only take account of iron (trap)doors, as fences was resolved as intended by [Mojang] Grum (Erik Broes) because they're intractable blocks, but iron (trap)doors don't know any form of interaction.
[Mojang] Grum (Erik Broes), you should consider solving this in a different way, for example printing the exception the method net.minecraft.block.state.BlockStateContainer.StateImplementation.withProperty(IProperty<T>, V) throws and just skipping these properties. Currently when you use 3;minecraft:hopper:1;1; as Superflat preset, the game crashes because of this exception
Introduction
Even though [Mojang] Grum (Erik Broes) wrote in his comment on MC-86949:
Using internals gives you internal errors
(Not sure if this applies here)
There are enough situations in which plain exceptions are printed in the log without a message like "Couldn't process command".
The bug
Using commands which do not run successfully because of an exception while executing them only prints the following in the log.
Couldn't process command: '[COMMAND USED]'
This makes it pretty difficult to find the reason why this happened. Instead the exception should be printed as well.
How to reproduce
- Use the reproduction steps of
MC-116927while having the world open - Use the /reload command
You cannot tell what why the command could not be executed. (In this case the advancement file had an invalid content)
Sorry, but [Mojang] Searge (Michael Stoyke) resolved it as such, so this is intended.
And [Mojang] Grum (Erik Broes) resolved MC-91224 the same way.
[Mojang] Grum (Erik Broes) I'll inform the Tech Community and ask them to test the fix and leave feedback here then.
[Mojang] Grum (Erik Broes) Is it possible to push this fix into the 1.9 version? No offense, but knowing the Mojang update schedule this will be rolled out to the majority of players not earlier then a year. And it certainly is quite a game-breaking bug, at least for some portion of the game.
somebody mind checking?[Mojang] Grum (Erik Broes) added a comment - Yesterday 9:53 AM
This change is rather scary, please test it
Seems to work with my limited testing setups.
ItsPlantseed [Mojang] Jeb (Jens Bergensten) already got assigned by [Mojang] Grum (Erik Broes), so I doubt it's intended.
That there's no nether wart block -> nether wart is intended, said so by [Mojang] Grum (Erik Broes)
![[Mod] Pokechu22](../../../data/avatars/users/92931.png){kind=small}
Note that sometimes it's the right control key that gets stuck, even if you rarely use it. If you press both control keys and then release them, then it should work.
Duplicate of MC-886; according to [Mojang] Grum (Erik Broes)'s comments there this isn't necessarily a hardware issue but still isn't something that can be directly fixed:
[Mojang] Grum (Erik Broes) added a comment - 26/Dec/12 5:32 PM
LWJGL issue, we can't help it as we cannot update right now.
![[Mod] Skylinerw](../../../data/assets/gravatar/skylinerw.png){kind=small}
@RobloxPro300090 It is working as intended for the MCPC version. See this developer comment by [Mojang] Grum (Erik Broes) on that report:
Actually it is working as intended because it is a bug turned feature by demand of the community. Would you rather have is break all existing maps and make certain constructs impossible?
Try making a 10x10 wall of pistons that all move together without this quasiconnectivity (use that mod above).
If you can make alternatives for all the existing structures we might consider it.
Windows 10/PE editions decided against this implementation and introduced the Observer block instead. That block may be extended to PC edition, but that is a feature request and as it stands the current behavior is intended.
[Mojang] Grum (Erik Broes) I don't know how I shall interpret that.. That's exactly the thing, it'd be great if the entity wouldn't stop rendering as long as a bit of it is within the field of view of the player, and that's what is happening here, the entity, e.g. an ArmorStand (without true Marker) with equipment does not render that equipment although it's still within the screen/field of view of the player.
It has gotten way better than in the beginning at the very least, so if it can't be fixed any better than what we've got currently, then we'll have to live somehow with it.
Edit: I didn't have the time yet to test it in 16w32a myself, will do some tests after work; if the entity gets rendered whereas its equipment doesn't, I'll post it to Mojira-Reddit with the hope maybe something can be still done about it, if one sees some examples.
Just a quick feedback note from other map and concept makers:
They see it as important that a large model (or any equipment) can be displayed despite the entity not being rendered, if it's possible code-wise, for better immersion of the player.
One thing I find very important (which I also mentioned in the bugpost):
I hope it's possible to make Marker:1b-Armorstands render their equipment at any time, because that'd be very much important for mapmakers, as it breaks immersion of players in maps greatly when it stops rendering its equipment: MC-98146
Thank you }=)
PS: Opened a Redditpost for further discussions about that topic, without knowing of course currently if having equipment on an entity being visible despite that entity not being rendered.
[Mojang] Grum (Erik Broes) The issue is that the rendering does not account for models that exceed their natural size.
If an entity is holding a block that is visually 3x wider than the entity itself, it makes little sense for that entity to stop rendering before the large block model is also out of a player's field of view.
[Mojang] Grum (Erik Broes), for a short moment I thought your behaviour regarding closing reports changed :/
Please at least comment "Will be removed" and then I at least know why it was closed, because I am pretty certain that leaving kind of dead code is not "Won't fix"
[Mojang] Grum (Erik Broes) I don't get it.
/summon item ~ ~ ~ {Item:{id:"dirt",Count:1b}}
/summon armor_stand ~ ~ ~ {Passengers:[{id:creeper}]}
/setblock ~ ~1 ~ minecraft:mob_spawner 0 replace {SpawnPotentials:[{Entity:{id:"minecraft:item",Item:{id:"cookie",Count:1b}},Weight:1}]}
DO work. Minecraft just adds minecraft: to the id of dirt/the creeper/cookie. Why shouldn't it work like this the same way for entity-types if you add the check on them upon summoning with a spawn egg or spawner? Makes no sense.
Because [Mojang] Grum (Erik Broes) said so.
My bad, actually a duplicate of MC-886.
See [Mojang] Grum (Erik Broes)'s comment
[Mojang] Grum (Erik Broes) added a comment - 26/Dec/12 5:32 PM
LWJGL issue, we can't help it as we cannot update right now.
Ouh, this is super awesome, thank you so much for fixing, [Mojang] Grum (Erik Broes)!
Can confirm the fix!
[Mojang] Grum (Erik Broes), when I asked for feedback when a report was closed I did not mean generic statements like this. Of course you can call it design, but it is inconsistent and matches the definition of a bug perfectly. The tag is called CustomNameVisible and "Cow" is definitely not a custom name.
Could you please not close reports like this. It is always annoying to comment and / or write on /r/Mojira just to get reports reopened and I am sure the mods, everyone watching the reports and you as well does not enjoy that very much because it is a waste of time.
What in the world are you talking about?
[Mojang] Grum (Erik Broes) said it's intended, so be it.
[Mojang] Grum (Erik Broes) I know this is kind of a suggestion, but there should be a way for the sounds.json file to tell that a sound event should play no sound. The way it currently is is pretty confusing because this is logged as warning.
But [Mojang] Grum (Erik Broes) himself resolved it as duplicate but did not close this report. Let's wait and see.
[Mojang] Grum (Erik Broes) This might be a good visual representation: https://youtu.be/HTw87opulQg Taken from MC-99604
See [Mojang] Grum (Erik Broes)'s comment on MC-106842:
It now keeps parsing and just ignored any invalids.
Christopher Martin, please retest this. [Mojang] Grum (Erik Broes) has done a considerable amount of work on pistons within the past few snapshots, and I am no longer able to get the falling blocks to break in any of my tests. I'm hoping this is fixed, but would like confirmation from others who have successfully replicated it in the past.
The bug
Based on MC-105820 commands which modify blocks or get data from them use the block grid instead of the position of the command executor. This causes values from 0 up to 1 (exclusive) to select the block the command executer is in, while -1 to 0 (exclusive) selects the block in the negative direction. This behavior was stated as WAI by [Mojang] Grum (Erik Broes). The problem is that as these commands allow decimal values you would expect them to be based on the position of the command executor.
To make it clearer that this is not how it works, it might be more intuitive to allow only integers as coordinates (relative as well).
Affected commands
- /fill
- /setblock
- /blockdata
- /testforblock
- /testforblocks
- /stats block
- /replaceitem block
Repeaters and comparators only give out block updates in case a solid block is in front of them.
Powering a dropper/dispenser or piston like in picture 1, which was possible in all previous versions, is no longer possible, because the dropper/dispenser/piston doesn't receive the information, that it is powered.
Powering only a single piston (picture 2) would be no longer possible without workarounds.
Placing a block in front of the repeater wouldn't work, because it activates both pistons (picture 3)
[Mojang] Grum (Erik Broes) added a comment - 2 hours ago - edited
This happened when we made the observers not be able to power the airblock in front of them and thus being able to power the observer line with a gaps in it.
See @[Mojang] Grum (Erik Broes)'s comment on MC-25537:
Only on top for now. Buttons behave now like levers.
1. SpawnPotentials is not part of /summon and nbt of spawners only
2. It is not, and mojang is still in control of the main programming
3. That's not a bug
4. Again, not a bug
5. Search the tracker, there's enough open issues that are actually getting fixed that actually are bugs
Reply to your summary:
Works as intended
Works as intended; it always makes that tag, as it randomly grabs one out of the list (based on weight) and overwrites SpawnData, so you don't lose your first mob spawn data
Again works as intended
Don't quite know what new render you refered to (didn't bother reading the entire conversation as this report is fully wai/invalid anyway)
Only certain things are actually unsupported by mojang; if it isn't obtainable without commands, it's mostly unsupported, with only a handfull of exceptions.
Reply to second to last paragraph:
Did you even read [Mojang] Grum (Erik Broes)'s comment on the other ticket? It's required for proper upgrading the entity in future versions.
The namespace actually prevents mods from clashing when adding entities, effects, enchantments, blocks, items, loot tables and structures, if it does anything to the modding community, it is helping them with better mod support.
Reply to last paragraph:
We just follow the rules of the tracker, what you submitted is mainly suggestions and duplicates, that means you didn't even search the tracker.
If you provide invalid data, that means it won't work as you would expect; outside of that invalid data -> invalid issues.
If you searched the tracker, those 5 hours could've been a few minutes.
We aren't forcing you to report issues, nor are we forcing you to stay; if you want to leave, go ahead, we won't stop anybody from leaving. It's your choice to come here, but by doing so, you are expected to actually search to prevent duplicates and see the difference between unintentional and intentional behaviour.
It's resolved as such by [Mojang] Grum (Erik Broes) so it IS intended.
I remember another bug that has been flagged as "Works As Intended" by [Mojang] Grum (Erik Broes). https://bugs.mojang.com/browse/MC-23952?page=com.atlassian.jira.plugin.system.issuetabpanels:changehistory-tabpanel
So we lost 2.5 years…
I just listened to [Mojang] Grum (Erik Broes), he's making the changes, and as the changes are being made, this list gets updated.
This ticket was reopened and assigned to [Mojang] Grum (Erik Broes), which means that the developers (at least one of them) think that this bug needs to be fixed. This ticket won't be closed unless the issue gets fixed or the devs say to do so.
![[Mod] Sonicwave](../../../data/avatars/users/94627.png){kind=small}
Based on [Mojang] Grum (Erik Broes)'s comment, I actually think that he misunderstood this issue since he said that you can see the floor without issues, while this bug is describing the exact opposite. There are discussions on Reddit about this issue here and here.
In any case, this behavior is inconsistent between computers: it didn't occur to me in 17w17b or 1.11.2 on a Windows 10 with NVIDIA (seen in attachment 2017-04-27_16.13.25.png), but when I tested it on another computer in the same versions it did occur (will get screenshots/specs when I get access to that computer again).
Edit: This seems to have the same cause as MC-4647, which describes blackness when in the Void with Night Vision.
[Mojang] Grum (Erik Broes) resolved MC-117005 as "Works As Intended" himself. The wiki is not a valid source.
Piyotato, look into the history tab:
[Mojang] Grum (Erik Broes) made changes - 05/May/17 10:00 AM
Field Original Value New Value Resolution Works As Intended [ 6 ] Assignee [Mojang] Grum (Erik Broes) [ grum ] Status Open [ 1 ] Resolved [ 5 ]
So, the ticket was resolved by Grum himself
Thank you for your report!
However, this issue is Working as Intended.
This behavior is intended, as established by [Mojang] Grum (Erik Broes) in MC-102040.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – 📖 Game Wiki
when MCpatcher, a 3rd party thing, was still supported
It never was supported
does Mojang ever intend to fix this
It's marked as postponed, meaning that it will be fixed later.
allow us to customize those hardcoded colors.
Mojang really need to make it easier to edit the skybox and biome/foliage/light colors.
[Mojang] Grum (Erik Broes): I have a branch with a prototype for this somewhere, might have time to work on it for 1.13
The ticket has been resolved as "Works As Intended" by [Mojang] Grum (Erik Broes).
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
Thank you for your report!
However, this issue is a Duplicate of MC-886.
LWJGL issue, we can't help it as we cannot update right now.
It will be linked to this report. If you have additional information, please add it to that report.
Please search before reporting, as it's likely that one exists already.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – 📖 Game Wiki
[Mojang] Grum (Erik Broes): The issue now is that villagers run extremely fast when getting into houses, but slower when actually escaping from zombies or illagers (which seems to be reversed logic, they should be more afraid of zombies than the night itself). I made a ticket with code analysis at MC-121175.
Oooh [Mojang] Grum (Erik Broes)...!
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
Yes, it is meant to be in the game, but any bugs you find because of it are invalid. See this comment by [Mojang] Grum (Erik Broes):
[Mojang] Grum (Erik Broes) This is also very controversial, but if you actually intend to have a feature in the game, that replaces this "bug", glazed terracotta is not the way to go, for reasons others already mentioned above.
However, a kind of replacement could be introducing a sort of slippery piston. The slippery piston always can only do one action, no matter what pulse length it receives. You could realize that by having a block state for that piston that stores information about whether it has pushed a block the last time or not.
![[Helper] Michał](../../../data/avatars/users/43368.png){kind=small}
We wanted to do changes to the worldgen system to make it simple/clear and possible to datadrive it in the future.
While doing so we noticed at a certain moment that we generated some areas of the terrain differently than before (not meaning the things placed as decoration, but the actual shape of the land). It took a while to figure out why, but it turned out that in the old code, there had been a bug from the beginning. We forgot to reset the seed of a random when we merged rivers and the biomes.
In the new code there was no way to reproduce this wrong behavior and this is why [this issue] has been resolved as Working as Intended.
We're not happy that we ended up changing the world where the intention was not to. We found no way to keep the bug while also keeping the new functionality we've added. So we chose to keep the new bug-free implementation and hopefully be able to offer datadriven biome definitions in the future because of it.
The new world generator changed some biome and landscape generation compared to 1.12.2. Examples:
- Changed terrain and missing ice spikes and hill of flower forest biomes (Seed 5178019746038571832, /tp @p 340 104 -3085 40 20)
- Missing Desert M and Sunflower Plains biomes (Seed 1443894742985852992, /tp @p 100 200 100 0 90)
- Changed terrain and new Savanna M biome (Seed 1443894742985852992, /tp @p 195 115 555 60 27)
- Missing flower forest (Seed 554762737523904, /tp @p 394 118 -353)
[Mojang] Grum (Erik Broes) say:
Super flat behaves different so make another ticket for that.
Reopened and resolved as a duplicate of MC-122532 instead; [Mojang] Grum (Erik Broes) resolved that ticket as Working as Intended, saying beds not being able to be remodeled is intended. (A result of that is that the side of the bed is no longer completely textureable)
I certainly disagree with that decision, but well, the devs decide how the game should work, not us.
Because [Mojang] Grum (Erik Broes) said it was intentional.
I've got a few things to say:
- This is a feature request, please use /r/minecraftsuggestions for those.
- Enchantment levels which aren't reachable in vanilla (survival mode or /enchant) aren't supported:
Any effect outside of those provided in vanilla circumstances should be considered unsupported officially and may or may not work as you'd expect.
Also seeMC-10755about this. - Your fixed files are ridiculously huge (with that I mean, over ten times bigger than the actual current language files). It wouldn't make any sense to include the strings into the language files that way, it would be way easier and simpler to just add a simple roman numeral converter to the game for that.
- As far as I know, the Romans didn't write big numbers that way. They had ↁ for 5000 and ↂ for 10000.
[Mojang] Grum (Erik Broes) originally set MC-109829 to "Postponed", so it was likely going to be fixed. Observers are supposed to detect block state changes, not random ticks. Just because something is useful in redstone does not mean it's a feature.
Added a zip file containing model files, textures and block state files for the beds; hoping [Mojang] Grum (Erik Broes) will change his mind.
Might be related to skin files containing malicious data.
But also [Mojang] Grum (Erik Broes) commented the following 3 years ago:
We have never deleted any skins nor do we have plans to do so in the future.
[Mojang] Grum (Erik Broes): Showcase of Hafydd attached.
Fabian Röling Thank you for testing all of it in the latest snapshot
I'm all for keeping this report closed. It was way to many little, sometimes subjective issues combined.
Some of the issues are already confirmed as "WAI" or "Won't fix" as of the comment of [Mojang] Grum (Erik Broes), as certain mobs are supposed to fit through certain spaces, but as they are mixed in with the other issues they never could officially be closed as such (One could argue that the rendering should change in these cases, but that's best done per case basis as well).
Sure, it will be a bunch of little reports that are all related, but at least it is possible to work with them. If we reopen this report it will stay open forever, because there will always be a collision box that could be better as cuboids only have to offer so much.
I would say don't report all of them, but just the ones where you see a significant enough offset or annoyance. Some small grouping might be reasonable if it affects all types of a mob or so.
That's just my take anyway. But the Mod-Team might have discussed a course of action for this issue.
Works as intended, see this comment by [Mojang] Grum (Erik Broes).
Edit: Didn't see that Mojang considered fixing this judging by that they didn't resolve this as WAI, which contradicts the comment I linked. In that case, MC-92484 should be reopened and be linked as relating to this bug. Maybe this report should clarify in the title that mob entities are affected while MC-92484 is about placeable non-mob entities like item frames.
[Mojang] Grum (Erik Broes) , are you sure you did it correctly? The MC-169319 resourcepack does not seem to work.
See MC-156961 ([Mojang] Grum (Erik Broes)'s comment.)
[Mojang] Grum (Erik Broes), still occurs in 1.16-pre2.
![[Helper] pine1needle](../../../data/avatars/users/41329.png){kind=small}
This is a duplicate of MC-87935, which was resolved as WAI by [Mojang] Grum (Erik Broes). However, that ticket was resolved in 2015, so perhaps a mod should mark that ticket for Mojang to review.
The infos in MC-197538, are very great, they explain on what places in the code the wrong distance is written.
But when you read correctly, [Mojang] Grum (Erik Broes) yust said "non-scaled radius" is fixed.
That means, it was wrong that in BOTH worlds the detection range is the same. Its tells nothing against a 1024 (OW) and 128 (nether) range.
Its try, maybe they "intended to reduce the range", but the point is that it breaks all existing portal gateways, and I think that is not intended.
And for sure I can tell you, that the 1024 blocks range is at least a fixed part of the game since 1.11.2 or before, because in that version my server was created and the long range portals where used since that version.
I dont realy unterstand what you mean with "turning 3 blocks into 1024".
Thank you for sharing your Idea of an alternative way to travel, but For me it is no real solution to replace a portal travel agains walking 128 Blocks for each part of the route. (And I think the most players would aggree)
And Farming thausends of ice blocks only to repair already working portal routes would take a gigantic effort in a big world.
I think you missunderstood the comment from [Mojang] Grum (Erik Broes) .
He yust said yust said "non-scaled radius" is fixed.
That means it is intended that the radius in nether must be "scaled" (overworld radius divided by 8).
This issue here handled exactly the problem that for nether and overworld the same radius was used (non-scaled).
But grum did not tell anything about which nether radius is correct.
To make that clear on the code from MC-197538:
Before 1.16.2 it was something like:
int radius = 128;
That was wrong because it created useles portals because it did not detect liked portals in overworld in a range between 128 and 1024.
The problem was that the radius in overwodl was to small.
Since 1.16.2 the code is:
int radius = inNether ? 16 : 128;
Here the scaling is correct, but I say the changed the wrong value, because that causes that portals in nether between a range of 16 and 128 are not linked.
The problem now is that radius in both worlds is to small.
So I think the correct code should be:
int radius = inNether ? 128 : 1024;
Because it fixes the bug and all portals will be linked like they where linked before the bug.
![[Mod] markderickson](../../../data/avatars/users/18946.svg){kind=small}
Hi! This issue will not be fixed. Any issues that can be created using the debug stick are not going to be fixed, based on this comment by [Mojang] Grum (Erik Broes).
fanFix2.zip
[Mojang] Grum (Erik Broes) I've attached an alternative fix above for coral wall fans that solves the backface texture flipping issue while at the same time not having said unnatural mirroring. Can you confirm that this fix works/is sufficient?
Before (current vanilla model):
After (model in the newly uploaded fix):
[Mojang] Grum (Erik Broes) I decided to revisit a fix for this after discovering/while reporting MC-250679. The resource pack I've attached there fixes this mirroring issue while still managing to have seagrass sway in the same direction underwater. The fix is overall rather simple - I have an in-depth description of how it's done in that ticket but it basically entails using two copies of the seagrass animation, with one offset halfway, and applying the two different animations on different parts of the model so that the overall animation/direction remains synchronized.
Current vanilla model:
With the fix from MC-250679:
Would this fix be acceptable? I think the outcome is actually preferable to vanilla's current behaviour, since for large bodies of seagrass the texture's repetition is less obvious.
@[Mojang] Grum (Erik Broes), particles and damage are indeed more synchronized in 17a.
I will close this issue and create another related issue.
I think [Mojang] Grum (Erik Broes) doesn't understand how vines work. When you place vines, it places it on only one side of the block. So if you want vines on three sides, you must place three vines. Later, if you break the vines, even with shears, it drops only one vine, meaning two vines are lost.
People aren't asking to be able to place one vine and have it cover three sides then break it to get three vines back (meaning the amount of vines tripled). They are simply asking that if they place three, then break the three, they get all three back, instead of only one.
This is inconsistent with Glow Lichen and Skulk Veins.
Thanks for sending in a report
This was reported a while ago as MCL-774, which is now resolved as Invalid. In the report, [Mojang] Grum (Erik Broes) mentioned that this is unfortunately not something that Mojang can fix, as it is an issue with Java itself. 
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
![[Mod] ampolive](../../../data/avatars/users/18949.svg){kind=small}
Thank you for your report!
However, this issue is Working as Intended.
The report you have submitted is working as intended: as per the fix of MC-117063 and this comment by [Mojang] Grum (Erik Broes).
Please note, that mechanics of the game may change between updates.
Things such as graphics, sounds, world creation, biomes, redstone, villagers, and animals may not work the same in current versions.
Full Version History – Snapshot Version History – Feature Requests and Suggestions
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Actually a duplicate of MC-122814, the client has full control over the player motion (and by extension vehicles they control; see also [Mojang] Grum (Erik Broes)'s comment there.
Additionally, modded versions are not supported.
![[Mod] j_p_smith](../../../data/avatars/users/92851.png){kind=small}
This is the expected behaviour; see for example this comment by [Mojang] Grum (Erik Broes):
If you get water in the boat, you will sink.
This is considered quite normal behavior on the PC version, items also vanish in lava, the cactus just damages it and the item 'dies'.
Unable to replicate, here the sound actually stops a tiny bit early.
Intentional. We'll reconsider this.
Unknown if intentional.
Has to be >100 not >= 100 as the subject says
Workaround: Dig one down, place fence on the edge. They can bunch up and jump of eachother
How would the client know what sound to play? there are quite some factors. Especially when the API comes in.
I'm quite sure no(t many) servers are running the pre-release right now.
Still cannot reproduce.
This works in the pre-release.
We need a way to replicate this problem else it will go on the 'heap' of a render glitch (and seeing that you are not having transparency in your trees, possibly just a 'slow system'/'driver issue').
Could you give a seed on which this happens?
Heard of this before, unable to replicate it locally. This could perhaps have to do with lag and client-sided prediction of sorts.\
Are you having this issue locally as well?
In which version did it actually give a score that was not 0 or &e0?
Does work with 1 block of air under it.
Yes, but that is not a bug to the game itself.
Playing locally or on a far away remote server?
Works here; the wait is 3-5 minutes.
Which videocard are you using?
Just edit the original issue.
Fixed, they all look like the ones on the 'North'/'South'. Also fixed the missing faces.
If you spawn an ocelot it has a 1/8 chance to spawn with 2 kittens.
Really strange, they do not change speed and it doesn't happen when they fall or are on fire.
You will need to give a bit more information. What are you playing on exactly (machine specs)? Which OS version? Which java version?
Can someone give a proper explanation how to reproduce this? I cannot seem to get it done (and 'clicking by sword' and 'hit the stone' is a bit 'strange')
Also for carrots.
Creative items are unlimited stacks, so yes, it will 'dupe' but it matters nothing, as you are in creative mode
Popping as in 'breaking into an item' as it should.
More details are needed. Is this locally? or on a remote server (lag/permissions)?
Also anvils in hands are fixed.
Surprisingly hard to fix.
Harder to fix than imagined, item does teleport now but it leaves the block as well, no idea why
Maybe you are wearing leather boots that muffle the sound. Point is, this is how it will remain because upcoming API will make it impossible for the client to know beforehand.
Moved it 2/256f forward.
This will never happen. Blocks != items.
Thanks for the clear pics
I'm guessing you have less than 512mb free memory available and thus java hits a hard-cap trying to allocate more eventhough the vm was started requesting that amount of memory?
We need machine specs
I think this is an OSX 'special' fullscreen mode. (Apparently it also works on windows ... well not really ;D)
There is simply no supported fullscreen on OSX from minecraft right now. Should be fixed in a future client though.
Not sure where this keybind is coming from, probably lwjgl.
Apparently this is a 'goal' problem.
Psst lots of words typed, relevant information still missing.
Which videocard are you using? and if its one of those build in chipsets, names+numbers please!
Could you make a screenshot of it?
The core issue is that the server and client are extremely naive. If this problem exists in the server please let us know, this right now on the client matters little.
It differs from how Diamondblocks behave however.
Falldamage can occur on a remote server with pvp turned on.
Which potion effect are you under?
Has to do with an inconsistent order of updating redstone wire.
Yeah, and this is the last warning. Be patient.
It's bloody 1:14 AM and I'm still fixing bugs and spending time here, we're not robots.
psst its fixed.
Server says no
.. anti spam.
We need some more info, which video settings did you select ingame? simple/advanced etc?
Can you do this consistently? is it only on this map/location? Could you perhaps upload the map to a public location so we could check if that is the case?
It seems like a transparency flag of sorts is still turned on. No idea what causes that.
Can't seem to reproduce it. Do you have some way to create this? Looking at the textures on the first image i can reproduce the setup but not the effect.
You can put water in a cauldron.
Humz not so trivial to change sadly ;(
Also fixed.
Random is random. I didn't get Silk touch, keep on trying?
You can spawn as long as the blocks you are in are neither liquid nor solid
The turning is fixed; see
MC-196– the disappearing could be lag to the server?Either the server sends you an old texturepack or you have one yourself.
Very confusing :/
What exactly do you mean with 'doFireTick' ?
NO! ... well yes! invalid ticket though
The snow tiles explode and that takes 'energy' from the explosion.
Are you able to recreate this? it seems only 1 piston out of the manylots is suffering from the problem. A contained testcase would be wonderful.
http://www.minecraftwiki.net/wiki/Tutorials/How_to_Install_a_Snapshot
That should resolve it
The translations are a community project. You can add you them yourself: http://crowdin.net/project/minecraft
Fixed when I test it here locally.
Did you by any chance use any form of modding that did an unknown enchant on the weapon? that is the only reason that i can see that might cause this.
Breeding gives 1-5xp. Maybe it got grouped with other xp that was already on the floor?
A bit more specifications might help.
The itemstacks merge on the server and one vanishing is the server telling the client to kill one. You get 1 stack of 2 back.
Intentional, you can make them in the air if you want to.
Impossible to do in mc.
Yipes wrong window
Paintings do the same.
No, the data is stored and loaded correctly, the only reason you do not get damage is because you get 3 seconds of invulnerability when you login. I spend a good 45 minutes with a debugger jumping of a pole seeing what happened
See the url in the linked ticket.
See the url in the linked ticket.
Closed as requested.
The top snowlayer gets replaced after a random amount of time. Maybe for you this random amount of time was short enough to make you think it was 'doing it on purpose' ?
It works here though i really dislike playing with the trackpad.
Please confirm this bug exists in the latest version. The reason you couldn't select 1.3.2 is because we fixed quite some issues in the pre-releases, the idea was to test them there and only report things that existed in them.
It is fixed in my development version. Should be in the next version out there (1.4.3?) The workaround for now is making sure the farmland is wet.
Fixed for the future.
Fixed for future.
Unable to replicate this with using seed '1945'. Could you give some more information? Could you perhaps upload a copy of the world somewhere so we could inspect it? (dropbox/attached here).
Fixed in the future!
In the future they can only spawn in pools that are 2 or more deep.
Yes, this is working as intended, the firewall SHOULD block this. Turn it off for local network connections should solve it.
Seems to work here, can you replicate the problem?
Unable to reproduce, it looks good, yes the hand is rotated ~45 degrees to the left from the 'hanging next to your body'-view but otherwise it appears sane.
Suggest a shorter translation at http://crowdin.net/project/minecraft
It's a road without end if we're going to make specialized renders for each and every language that doesn't work with stand-alone glyphs.
We need some more information on how to reproduce this error. I'm unable to reproduce it myself
Maybe some firewall/hosts entries that make you not reach the minecraft domain? This is the launcher indicating you cannot reach the place to login which is something that is on your side.
This is how it should behave.
Totally unable to reproduce
TNT+Redstone works as intended here, could you perhaps explain this better and if the bug still exists create another report?
I'm betting firewall on mac and/or windows.
Fixed for future.
Fixed.
The achievements/tracking are just numbers. You can totally play without them. No gameplay elements depend on them.
Seeds will unpop when place in an insufficiently lit area. If you have lit the area properly and it still happens, please make another report explaining what you did (uploading a screenshot with it would be useful).
Fixed for future.
This warrants at least a screenshot; a video would be even better!
No we do not have a 1.4.3 version to attribute fixes for >.>
This is not the latest java version, and frankly running some weird ancient beta version might be asking for problems
the latest 1.6 version is 1.6.0_37 currently.
http://www.oracle.com/technetwork/java/javase/6u37-relnotes-1863283.html
How did you get into this fabled 'fullscreen' mode?
Yes the world is being generated as you load it, this causes lag. Either get a beefier box to play on or just wait a bit
Please do not make issues 'private' if they do not contain sensitive data.
I'll do that for you!
You annoy a spider? It will annoy you, you can however just keep running until it gives up
Same problem as that
Prove this with a dataset that makes your results significant if this is going to be considered valid
Yes you just failed to use the search.
Crash log would be ever so useful.
Modified servers are not supported, if this doesn't happen on vanilla, there is no problem.
What is the bug reported? O.o
There are no 'true' wooden slabs. Feel free to replace them yourself
Were you playing locally or on a remote server?
Rain doesn't drop where you are standing (so if you look up, it never rains in your face). Rain does fall through ladder-blocks though.
So. The common issue is that you all have ancient PPC based systems. Apple dropped support for them quite some time ago (you cannot update to 10.6+). People who build bindings for OpenGL/OpenAL hardly ever give any priority to get compatibility with PowerPC-based systems and this makes it impossible for us to support it beyond a 'best effort basis'. Which in this case is: it works? good; it doesn't .. well ... :'(
You routing traffic over a VPN makes this your own problem. It falls in the same category as not being able to get your portforwards working.
Please report bugs for the X360 version at http://minecraft.net/bugs
Modified minecrafts are NOT supported.
Argh, you are right, i missread a part of that output.
The only 'curious' thing i can see is:
[06] unspecified - 36.04%/18.61%
The rest could very well be with a lot of entities.
Ugh wrong ticket
Please Do Not Type Every Word Starting With A Capital On This Bug Report Environment, cheers!
Which videocard?
Please do not abuse the 'security'-level for things that do not need it.
It seems you are having problems with releasing your cursor when opening a gui-window/screen. I however have no idea why it works properly when you are in the main menu.
Could you give some more information about the system you are on? Are you using some sort of non-standard mouse orso? I'm also running on a mac and I can't really replicate it
There are some extremely alpha osx-bugfixes in the work for lwjgl; see: http://lwjgl.org/forum/index.php?topic=4711.msg25685#msg25685
Maybe give those a shot? You should unpack them in your ~/Library/Application Support/minecraft/bin folder. You can remove it again by doing a force update.
Does this happen on the 1.4.3 pre-release?
Either duplicate or fixed. In either case, cannot reproduce in development.
Just a note, this is supposed to eat the items in creative.
Nasty one to find, should work from the next release
Future will bind to 'null' (which ends up being INADDR_ANY) now.
You can just distribute the launcher which would download the client. just saying
See: https://aur.archlinux.org/packages/minecraft/
Blocks you cannot normally attain but you can /give to yourself simply has no tooltip as... they cannot be normally attained.
It actually doesn't emit light in a gameplay sense, yeah I do indeed notice an ever so tiny brightness increase. Actually not 100% what is causing it, I think the fact that its a tile-entity slightly offsets the lighting.
Not really much of a problem though
Also Jon; get better diff-tools
There are sleeps in the main loop.
When is it using 100%? What are you doing at that moment? it can be totally justified if you have a sub-par machine, which in this case is not really likely.
Either fixed or unable to reproduce. On my dev-version after a short amount of time the itemsframes AND items pop out of the block.
Are you really sure what is what you want?
https://www.dropbox.com/s/99hy68iavhm5x97/2012-11-06_22.08.41.png
Unable To Read With Each Word Being Capitalized On Its Own, Please Stop Doing This You Have Been Warned Enough By Enough People. Thanks.
Seems to be a workaround as well.
They get aggressive towards the thing you hit, if you kill it .. they are happy.
Blocks in the world are different from items in your hand.
If a way to reproduce it is found, please let us know.
Undead really being healed by your instant-damage-potions
(Try instant-heal potions on them!)
Feel free to attach a profiler to the JVM and report back with some hotspots
This is indeed fixed. I wasting time verifying.
The real problem is:
OpenGL: Intel(R) Graphics Media Accelerator HD GL version 2.1.0 - Build 8.15.10.2021, Intel
I'm pretty sure you need to install a handcrank to get some performance out of that.
I dare to say: no bug, doing stupid shit with the generator is supposed to break you hard.
try manually upgrading your lwjgl, google the minecraft wiki for how
Let me guess, you have an Intel 'videocard'?
Unable to replicate this problem on my desktop/macbook.
Unable To Parse Your Weirdly Created Sentences Where Every Word Starts With A Capital, Can You For The Love Of All That Pertains To Be Holy STOP THAT ALREADY!
Thanks!
This is something we cannot fix, if your hardware doesn't understand OpenGL there is nothing we can do.
Try drivers? .. or maybe the handcrank! ;D
Unable to replicate. Please instruct how to do this using vanilla minecraft.
Is Modded: Very likely; Jar signature invalidated
Please try again without a modified client.
It matters absolutely nothing what happens with items when you are in creative mode.
This is a bug that should be reported with http://lwjgl.org/forum , we cannot change it.
Fixed
Fixed.
You turned on unicode because you picked french.
Ugh right now almost impossible to fix sanely.
Fixed.
The 'protocol family unavailable' is just what it says; you cannot make outgoing ipv6 connection without having an interface support it.
Crashlog please
Able to see it happening with that map. What on earth is going on
This is actually intentional, you cannot permanently fix up certain items.
Unable to replicate. What sort of videocard do you have?
Modified client, please try without and provide a way for us to replicate it.
A modifier button is stuck; try manually updating your lwjgl. Problem should be gone after restarting the client too. http://www.minecraftwiki.net/wiki/Tutorials/Update_LWJGL
What videocard?
Same with quicksand.
This looks perfectly fine.
Pretty sure the minecraft auth servers are not responding. Has nothing to do with 'hiding the ip address'.
Minecraft doesn't get 8gb ram allocated. How are you starting it? Must be either a custom commandline or launcher.
You must have been in creative mode, unable to replicate in survival.
Confirmed not sure if intentional, i think it is
If chunks are not loaded nothing will happen. This is intentional.
Already fixed.
Completely unable to replicate, all 3 work perfectly fine.
We did change the way stuff is wrapped but it seems to work 'as before'.
Is anyone able to reproduce? :/
Minor hickup in the auth-system. Works again, reviewing what happened.
I do not see the issue; Windows 'locks' files for change when they are in use. Nothing you can do about that.
SheIt can healherselfitself.Really fixed for updated 1.4.5 now
It's actually with any non-full-block-height block.
The code is not using any proxies, if you are routing all of your traffic through proxies that mangle the data that comes back and thus violating tons of standards there is absolutely nothing we should do to support that.
I think the real issue is substandard videocard drivers. I can't really do much about that. If the drivers do not see the difference between 0 and 3f/256 .. well ...
Actually the zfighting happens within the map itself, not with the frame, maybe we can do something about it.
You know, my input maps perfectly when using Dvorak on Win7. When I type I get the proper characters, when I make keybindings they are named properly. IIRC on OSX the Q-key location on the Querty keyboard would always be called the Q-key even though the character-code attached is ';'. This would only give a display problem in the keybinding screen, the bindings would just work like normal. This is a LWJGL limitation, the hardware keycode is still Keyboard.KEY_Q but because of the Dvorak mapping it would map to ';' as character code. There is no way to ask LWJGL about this mapping, so the display in the keybindings will be wrong, but it should be working.
We do indeed bind to the keycodes, we bind to the thing we get back from LWJGL, LWJGL just 'gets it wrong' depending on the OS. Also stuck keys is also LWJGL but we cannot update right now (as it would horribly break all osx).
LWJGL issue, we can't help it as we cannot update right now.
My fix didn't end up working because of some weird anti-dupe code for sand/gravel in combination with pistons. This is likely code we'll go over for 1.5 so we then might be able to fix this.
This ticket is invalid as it relates to a modded or 3rd party client/server.
They only grimas when they are hurt by something (mob/fire/cacti/falling etc). Otherwise they always look 'normal'. Did you accidentally drop the ones you spawned?
Known issue, apple added whining about signed applications meanwhile the launcher hasn't changed. Wont be fixed until we overhaul the launcher completely, you can fix it by turning off gatekeeper.
Because you have modified your client we cannot possibly do anything with your report.
If you can replicate the error without a modified client we might be able to help.
If you 'Open to LAN' the idea is that you will connect to the server via the 'Scanning for LAN Worlds' in the Multiplayer menu. All available worlds will show up and they are found using multicast (so unless you have some crappy setup that somehow disables that – you can just find the worlds in that menu). The multicast will know the right IP to connect to so you do not need to know the IP at all. I think we should perhaps disable the display of the IP when you've turned on 'Open to LAN', so it just says: LAN world listening on port: xxxx.
Furthermore the code binds to all available interfaces (using INADDR_ANY), this also means it should bind to 127.0.0.1 as that should exist as your local loopback device, as well as to any IPV4/6 interfaces available to java.
So, if you say you have problems, please give exact details on what you are using and how you have set it up. Also be aware your local firewall might be preventing multicast or outside connections, this however is not something Mojang can solve/help with.
Let's give this another shot:
Please explain IN DETAIL what you mean by:
Because when I test it, the chat works as it should and the keybinds are on the correct keys eventhough the textual representation in the configwindow is wrong.
As I've explained in the other thread, there is no way in LWJGL to obtain the charactercode for a keycode when it is not being pressed and thus loading a binding configuration 'goes wrong' because it displays the raw keycode locations (KEY_Q is always KEY_Q eventhough it has charactercode ';' on OSX. As LWJGL is the only player who has this mapping there is no way for Mojang to figure out the proper character for display.
You are claiming that your keyboard map has two Q,Z,E and W's ? How did you check this? Where did things show up double?
Please tell me with which developer of LWJGL you've been talking, over which medium (email/irc/?) and show me a log of the chat. That would probably give us some more useful information than you are providing.
TL;DR:
Again, I cannot replicate the problem, I do not have duplicate keys in my mapping, I'm testing this on a 15" Retina macbook running 10.8.2 with setting my keyboard mapping to 'Dvorak'
Also feel free to not be so aggressive, if a problem doesn't get solved there are good reasons for it. Right now the reasons are that you are providing unreproducable information (and a horrifying attitude). Tails closed the ticket perhaps a tiny bit fast but you've never actually responded to what I said, I advise you to do so and rant a bit less.
I've attached a screenshot with me moving the keys from 'qweasd' one to the right; the keys show the Qwerty names but they are bound properly.
Works here, one shows up as 'E' the other as '.' under both US Qwerty and Dvorak. It doesn't show up red, it doesn't register a duplicate key, in chat they are identical.
Which is what makes it so strange, it works fine here, i do not get duplicates when pressing 'E' and '.' in Dvorak mode, the chat works fine. The only 'issue' is that the displayname of the keys are the QWERTY locations, which is again something only LWJGL can fix.
Who did you end up talking with on irc? Was it in the public channel? (then I can find logs)
Also any testing you have done was against a completely different version of LWJGL.
This is because you have to bind against a keycode not a charactercode because otherwise here is no way of asking LWJGL if the key is down (as you can only ask it by keycode).
Stuck keys is 100% LWJGL.
There is no version-history back until then, but if you know the version that 'broke' it we could decompile ancient versions and diff them.
As with any bug, if I cannot replicate it there is no way to fix it.
Actually, I am not 200% sure, I did update to 1.4.7 which normally brings in the lwjgl fresh too. After checking it seems it runs my modified 2.8.5 ... I should put that in a nice place somewhere =)
Erm, so yeah, the keyboardmap is completely messed up with Dvorak and 2.4.2+osx, yay able to replicate the problem!
To temporarily mend your problem, download the LWJGL osx alpha branch from: http://lwjgl.org/forum/index.php/topic,4711.msg26004.html#msg26004 and override the files in your Minecraft installation
You should get a bit more consistent experience eventhough the 'display value' in the binding window is still wrong.
Also, we cannot update LWJGL right now, there is no release that works on all OSs. 2.8.5 is broken on win7, fixed in the repo. anything > 2.6.x is broken on osx + java7. We're waiting for the osx-java7 branch to mature after which LWJGL can release 2.8.6/2.9.0 which we will push out for Minecraft as well, this might happen as late as 1.6 though.
NOPE; Try that horrible attitude again and I'll get your ass banned of JIRA. I'm not joking, be respectful, even with the shit you threw my way that is what I did.
You can be persistant without having a horrible attitude.
I still believe that Tails perhaps closed the ticket too early, but in retrospect, as I said then, this is LWJGL and not Minecraft so all in all Tails did the right thing.
The Launcher is highly un-capable of almost everything, we'll fix this but it'll likely be around after 1.5 (see how vague I am? no pinning me down on this later ;D)