Eris

Thank you. Although honestly I'd rather that it became a background process (see my previous comment) when it's set to hide, so the dock icon goes away altogether. That way I don't have two "Minecraft" icons in my dock.

Ugh, guess I don't need to attach the crash report then. I don't care if this is intended behavior, it's wrong behavior for a Mac OS X application. At the very least, clicking the dock icon should bring the window back.

If the launcher wants to run in this hidden state, it should become a background process. There's a C API to do this:

ProcessSerialNumber psn = { 0, kCurrentProcess };

/* become a background process */
TransformProcessType(&psn, kProcessTransformToUIElementApplication);

/* become a foreground process again */
TransformProcessType(&psn, kProcessTransformToForegroundApplication);

I know Java has some kind of FFI, so I'm sure it can be done from there too.

17:55:50 - Launcher with icon in the dock, no problem.
17:56:17 - Minecraft running, launcher icon still in the dock, no launcher window.
17:56:54 - After quitting Minecraft normally, the launcher icon sticks around. Still no launcher window.

I don't think you've understood the issue properly. It's not an issue with launching Minecraft; it's an issue with correctly closing the launcher once Minecraft has been launched:

• the launcher window closes (this is correct, and what I have chosen in the settings)

• the launcher '''application''' doesn't quit, but stays in the dock (this is wrong)

• clicking the launcher's dock icon does not re-open the launcher window unless I quit the launcher

• Minecraft functions as expected

• after quitting Minecraft, the launcher application remains in the dock in its useless state (also wrong)

The bug obviously isn't triggered if I set the launcher to stay open, because the bug is in the launcher not quitting. There's no way to have the developer console open and trigger this bug at the same time.

I'll attach screen shots to show what I mean.

Then there shouldn't even be a version in the bootstrap launcher's Info.plist. It's been 1.0.0 since the new launcher was first introduced, and I know the bootstrap launcher has been updated.

Oops, thanks. It's really confusing that the file names aren't cased consistently. I guess I misread the case when I glanced at the directory listing. 8I

Looks like a bug to me too, dear mods. This is a case of minecarts (entities) behaving in a manner that is inconsistent with item drops (more entities), players (yep, entities) and mobs (also entities).

Oh. This was actually done to prevent baby animals from wandering into a smaller space than an adult would it in, growing up, then immediately suffocating. Can't find the source, but I am pretty sure Notch himself said so.

Yeah, this just bit me in the posterior (apologies for the earlier phrasing). It's even worse if you're making an HD texture pack, and it gets worse the H-er D it is.

I think making the lid slightly bigger is the best route to go here. Container lids often fit over the top of the container, after all, right?

Yep, this is still happening in 13w03a. You guys who commented and are still having this problem need to vote on it so it gets seen.

Affects 13w03a and 13w04a as well. Is there some way I can update this ticket myself or does the original creator need to do it?

There's no technical limitation, because the chat buffer has decent line editing support. I'd love to see books brought up to parity with that.