darkjmknight

I don't see a way to close or delete this ticket myself so I'll just comment on it.

I spent a few additional hours today troubleshooting this issue, particularly comparing my Snapshot Profile environment to my Latest Release profile environment and I discovered the Latest Release had view range set to 32 chunks... Unfortunately with all the busyness of the oceans now 32 chunks eats the default 1GB of memory pretty quickly and it seemed to be the cause of the lag spikes.

I tried adjusting the snapshots to 32 chunks and the release profile to 16 chunks and the issue did seem to transfer so I'm pretty confident this is the cause.

I then adjusted my release profile to run with 4GBs memory and it seems to support the 32 chunks just fine. I will look into optimizing my Minecraft settings and apologies for the bug post. :~)

Meanwhile, 1.13 is awesome!

Just tested latest snapshot 15w49a. Command-Q, of course, quits the game, but Q is definitely the most finger convenient key to press for dropping items. I changed the key to G and pressed Command-G and it dropped only one item the first time but then the whole stack on 3 additional attempts so perhaps I just fumbled the Command key the first time? This has been broken so long I've given up dropping stacks of items via the keyboard, which is really annoying... I either have to spam the Q key to drop a smaller stack, or I click the stack and drop it out the side of the inventory. Both are slower, but at least they don't quit the game or require remapping the game's default keys to function properly, which I think is the ultimate reason this is a bug. I understand the conflict between this bug and MC-13695, but perhaps you need two modifier variables, one used when clicking and one used when keyboarding? Altho then I suppose you run into Command-C/V for copy/pasting... :~\ Control C/V was fine, back in the day, but I expect you'd get some push back if you tried to change it back.

Partly repeating my comment from MC-5951 in case 'closed' means no one looks there... :~)

From their beginning comparators have required strong side-powering to function. They pull signal from behind like repeaters, push it out the front like repeaters, and require strong powering from the sides to change operation, just like repeaters. So MC-5951 was never a bug to begin with, just someone who didn't understand proper redstone functionality. And that basic functionality of comparators was not changed by the fix to MC-5951.

From their beginning RedStone Blocks behaved exactly like any other 'strongly powered' block, except that they were inherently strongly powered, rather than requiring power pushed into them. They have never behaved like 'omnidirectional repeaters' which is how they behave now, pushing power into all the blocks around them. This change severely breaks almost all redstone contraptions that use redstone blocks and throws existing slimestone (including Missile Wars and perhaps most other Realms prefab worlds) out the window for no functional gain (unless you consider hundreds of new BUD possibilities a good thing) and serious functional loss (even if you consider the BUD possibilities a good thing.)

From their beginning comparators have required strong side-powering to function. They pull signal from behind like repeaters, and require strong powering from the sides to change operation, also like repeaters. So this was never a bug to begin with, just someone who didn't understand proper redstone functionality. And that basic functionality is not changed by this fix.

From their beginning RedStone Blocks behaved exactly like any other 'strongly powered' block, except they were simply inherently strongly powered, rather than requiring power pushed into them. They have never behaved like 'omnidirectional repeaters' which is how they behave now. This change severely breaks any redstone contraption that uses redstone blocks (most of them) and throws slimestone (including Missile Wars and perhaps most other Realms prefab worlds) out the window for no functional gain and serious functional loss.

Cube Hamster explains also:
https://www.youtube.com/watch?v=cXm6JlCn8EY

It also creates a lot more BUD situations, which are always difficult to predict, while breaking a number of traditional piston BUD designs which are well understood.
For example:
If you put down a redstone block, put down lamps in a 5-wide diamond all around it, and then break the redstone block, the lamps 2 blocks away from the redstone block stay lit.
Screen shots will be attached.

Ah yes, my bad. I have now commented, ultimately on MC-415, after following the duplicate chain.

Meanwhile I have also experienced this particular bug with end-cities. Just tested now on 15w34a, seed: 2172127531774641369
After defeating the end dragon, I happened to find an end-city immediately through the portal. (And an end-ship.)
At coordinates /tp -933 141 -548 90 27 you can see that a chest has apparently spawned already popped at coordinates: -937 141 -548

Here's how to reproduce this on the latest snapshot 15w34a.
Create a new survival world with a bonus chest using seed: -6625871255631194444
Depending on where you spawn, you may pick up the bonus chest contents before the world even finishes generating, but if you don't, they should be scattered around -84, 72, 258, next to two torches which surround one leaf block that apparently destroyed the bonus chest at generation time.
Chests seem like a particularly important block to protect from leaf generation.

I also tested Chris Keohler's seed mentioned above, but with the changes to world generation that seed no longer is affected.

This doesn't just affect End-Dungeon chests... I just started a new world with a bonus chest on seed: -6625871255631194444
The bonus chest was non-existent, but its items were scattered around a couple torches.
(Side-note, you start in jungle hills and there's a jungle temple nearby, but its loot is disappointing. However its chests are intact.)

I have experienced this also in 1.8 Pre 3 also on my Mac running OS 10.9.

I was loading up various old worlds looking for a specific structure, and with each new world, the time it took to get out of 'nothing is loaded and you are falling' mode and into 'you have landed in your world' mode took longer and longer and longer.

Quitting Minecraft entirely and reopening it resolves the issue, but it seems like a memory leak?

If I don't quit, eventually a load just never quite loads and I fall forever, until I hit Command-Option-Escape and then the game just disappears, no crash, just gone.

The photo I attached from my phone was to replicate the issue I had run into in a freshly generated world, just in case something was broken from an earlier snapshot.
Importantly, it gives you all the details to replicate this bug yourself:
1. Create new creative world with seed: 529770237
This is the same as the seed: New Features
2. /tp -638 63 44 83 19
(Facing a really nice cliff over water, with a waterfall, lavafall, and stone pillar.)
3. Build a nether portal, light it, and travel
4. You were in Creative mode, right? If not, you are now dead. If so, you will not find a nether portal, at least I didn't digging around in the nether rack a lot.

I tried breaking the portal in survival using water poured directly onto it and the entire portal broke correctly. I'm not sure how else to break a portal directly in survival.

I just ran into this myself in 1.7.1 on OS 10.8.5. It seems to happen specifically with game generated portals only, and only on their initial generation. The original description is accurate and it can happen either in the Overworld or Nether.

Steps to reproduce in creative:
1. Create a portal.
2. Walk through.
3. Turn around and try to break it.

Steps to reproduce in creative in Overworld.
1. Create a portal.
2. Walk through.
3. Either have devised a device that puts the portal out (I had a rapid portal toggler going when I did it.) or have someone else join game and put the portal out, or I suppose walking a ways away such that a new portal in the nether wouldn't link to the original portal in the overworld might work also... in which case, build a new portal far away in the nether...
4. Come back through into the overworld, which causes the generation of a new portal.
5. Turn around and try to break it.

In both cases only the one pane of the portal breaks, the rest remain and occasionally one of them will turn 90 degrees sideways, depending on the original orientation of the portal.

If you break all the portal parts and then relight the portal, then it functions properly on future breaks. You cannot relight the portal until all it's portal blocks are broken.

I second this issue and hope it's fixed soon as I use this feature all the time.
Meanwhile, MC-22622 appears to be a duplicate of this issue, altho it's description is more confusing.

You do not need to update to 10.6.8 if you get the pre-release. It works perfectly on 10.5.8. Thank you Mojang folks!!! :~)

This is a Macintosh... while they technically have drivers, you can't upgrade them separately from the OS. In very rare and specific circumstances you can, but it's certainly not a standard or even occasional practice like with Windows boxes.

Googling on the issue, the answer for this case seems to be that you can not.
https://discussions.apple.com/thread/2369659?start=0&tstart=0

Thus, 10.5.8 left behind. It is 5 years old, it's just unfortunate it can't be resolved by working around this particular function or something.

Or perhaps it's OpenGL 1.2 they're leaving behind, and thus this particular OS with it? Either way, it just seems like someone should 'officially' make the decision to leave the OS behind.

From the name of the function, I expect they're taking advantage of some new OpenGL feature to permit them to more easily load all of the textures from separate files rather than from single 'bulk' texture files as was the case before? Just a guess.

So with 13W02a they have started using some function that isn't available in this older OS and they're leaving OSX 10.5.8 behind?

I can understand if they're leaving 10.5 behind, it's almost 5 years old, I was just hoping this was not the case since it's the only computer I have access to at this time, and I was enjoying testing.

Oh well, 1.5 will apparently have higher system requirements.

Also, that issue talks about a crash before the Mojang logo comes up, and this issue is after the Mojang logo comes up, and the dirt background is put in place, but before the menu shows up. This is not a duplicate, how do I get it unlinked?

Unfortunately my computer is stuck at OSX 10.5.8, I can not update it any further at this time, which prevents upgrading Java or the OpenGL drivers. I expect that this prevents updating my LWJGL files, altho I'm not familiar with LWJGL files... didn't those come with the Minecraft installation?

I'm glad that 1.4.7 works, as did 13W01b, only as of W02 did things go south.

Also, this is not a duplicate of MC-872, which was supposedly already been resolved when I posted my case and was the very reason I posted my case. I had also experienced this same issue with 13W02a, and that issue was marked resolved.

I posted this case to point out that whatever issue MC-872 was, resolved or otherwise, I am still having the same issue as before with 13W02b.

I also had the exact same experience, also running 10.5.8 on a MacBook.

The game asks if I want to update, and then puts up the dirt background, and then crashes before the main menu displays.

Doh! I always forget the 'count' parameter when adding damage parameters. But yes, that is the issue. Good intuiting my error'd instructions.

You should have an FN button on your mac that should permit you to press F3, but if that doesn't work, you can change your function keys to work as function keys by going to 'System Preferences'/'Keyboard' and changing the function key setting.