Tex Pepper

No working beacons here either with 13w39b. On a whim I created a new, default world, and assembled a 3x3 iron block pyramid with beacon on top. No other changes. Beacon will not light.

I'd several dozen working beacons in a different world, none of which now work.

Several other problems which I'll post separately as they seem unrelated to this one.

"... However, all of the crash reports that you have provided are from a modded version of Minecraft."

Are you serious? Modded?? Given that I downloaded the thing directly from Mojang's website not a few days earlier and given that I am still a relatively new user, I must've modded it in my sleep (in spite of the fact that wouldn't know where to begin, let alone pulling it off convincingly)

Explanation #2: Mojang is now offering pre-modded copies to save Modders the effort and at no extra charge?

Explanation #3: It is not actually modded, but your crash-report generator thingie only thinks it is, which raises the question: how do you know your crash-report generator thingie is itself working properly if perchance it isn't? (possibly analogous to the Dunning-Kruger Effect but applied to software instead of Humans)

Explanation #4: The website from which I downloaded Minecraft 1.6.1 is not really Mojang's website, but someone else's; possibly the NSA's Mojang clone (to keep a sharp eye out for, you know, Bad Guys, folks who'd violate our U.S. Constitution given half a chance, all in the name of Truth, Justice and the American Way?) or, maybe a Zombie-in-the-Middle Mojang clone and my copy of Minecraft is really a Trojan Horse? In which case, how do I know you're really Mojang's folks and not Bad Guys? How would I know? How would anyone?

The Plot thickens.... 😉

@Chick3n - This has been a problem since 1.2.5 and it still hasn't been fixed? Oh my! How is it that Mojang hasn't the time to fix what seems to me to be a fairly significant bug, but yet has time to add new features like horses, horse armour, etc (which have introduced new bugs, if I'm to believe some of the other bug submissions here)?

This does not bode well. Not at all. Somebody's not minding the store.

Forced crash report.

You're right. Sorry, I'm still new at this game.

Changed Difficulty to Peaceful but no change: water behaves normally now but repeaters still locked up.

Yet more info: Seems the Difficulty is already set to 'Easy,' and yet there are Creepers and Endermen prowling about. As I understand it, these mobs are not supposed to be present (or at least, visible) in Difficulty: Easy?

More info: this time the redstone repeaters fail to upate at all, even whilst other parts of the scene animate normally. Interestingly, the water blocks update even at a (much more reasonable) distance, with the water 'flowing' continuously from those valves which are stuck open (because the repeaters won't update). This new behaviour is shown in the following video: https://docs.google.com/file/d/0B_DqKqLT946KUWJxVE1PYXJEc00/edit?usp=sharing

I cannot get this to repeat the earlier behaviour of groups of water blocks failing to update, thanks to the repeater problem. Just guessing here, but when large numbers of groups of animated items are involved, all this 'simultaneous' action tends to overwhelm MC's internal machinery perhaps? The cavern in these videos is huge and contains lots of critters, each of which is animated separately. As these seem to receive priority render-wise, possibly there's little left in reserve to animate lower-priority items such as user-created stuff. I'm just speculating here, me not knowing anything about Minecraft's (rather remarkable) internals.

As a test, I'm going to run this again with Difficulty set from 'Hard' to 'Peaceful,' to reduce the numbers of animated items (critters) and see if this makes any difference. On the flip side, the issue with falling groups of water blocks was a problem with Difficulty set to Hard as well, but now it's the repeaters giving me fits and not the water blocks, and so reducing the number of animated items may not make any difference. I'll let you know.

Manually-forced crash report, as requested.

Ah. Blame English, my native tongue. 😉

Please read Nathan's earlier replies to me and please refer to the link I provided to Mojang's support pages in which Mojang themselves suggest this very approach. Now, why would Nathan tell this bloke "No, sorry," to his query about whether you can invoke Minecraft from the command line and yet, here, tell me the complete opposite!? I don't get it, especially in light of the fact that

javaw -Xmx2048m -jar Minecraft.exe

actually does invoke Minecraft AND from the command line, and why shouldn't it? Minecraft is a Java application and this is one way of launching a Java application – any Java application, and so, I'm wondering if Nathan is just jacking with this bloke?

Dinnerbone,

I invoked MC 1.6.1 from the command line (from a batch file, actually) via:

javaw -Xmx2048m -jar Minecraft(v1.6).exe

but it had no effect whatsoever in terms of MC's knowledge of the heap size. Nothing changed. MC still bailed when its usage hit 910 MiB, as before. I've 4 GiB of RAM installed in this (64-bit, four-core) machine. The Task Manager indicated that nearly 3 GiB were available when I launched MC in this way.

Please note, btw, that I've renamed the latest version of Minecraft to Minecraft(v1.6) to distinguish it from v1.5.2.

Good morning, BJ Dinnerbone 🙂

You wrote: " It also does not actually use that amount of memory unless you specify -Xms for "minimum amount of memory to use". Don't use -Xms, that's silly."

Well, yes. But it was Mojang who suggested this as a fix in the first place, else I wouldn't have known about it at all (I'm not a Java person): http://help.mojang.com/customer/portal/articles/928783-minecraft-has-run-out-of-memory

" If you're on 32bit java it'll be limited to about 1GB, if you're on 64bit java it could be more than your machine actually has."

This is very good to know, especially the 64-bit part. I've looked on Bog knows how many sites and they've all seemed more eager to tell me "the -X options are nonstandard and could go away at any time" than telling me what the actual limits are. What you wrote is therefore greatly appreciated.

'Bit Jockey' is a complement, btw. At least in my neck of the woods.

Take care and thanks for your prompt reply!

Tex

Something for Mojang's bit jockeys to consider in preventing (or, at least, forestalling) this out-of-heap-space problem: rather than blindling allocating chunks of memory until you fall off a cliff, programmatically monitor how much heap space is left and increase the heap size as-you-need-more from within the program itself -- and do so in some reasonable, intelligent fashion that doesn't starve other applications of memory, possibly by setting the max heap size to some percentage of available memory (this value having been programmatically gotten from the operating system). The program could further 'tune' this threshold by observing how badly other apps are thrashing (by monitoring overall VMM page-fault rates, possibly. This implies kernel-level operating system support btw, possibly by means of a device driver). This, in combination with some sort of intelligent algorithm which processes to completion as many already-allocated-stuffed-and-ticking blocks as possible and then retiring that processing before grabbing more memory.

Alternatively, a better, more robust approach (requiring a lot more work. There truly is no such thing as a 'free lunch') Mojang could write their own memory manager which shuffles blocks-in-process off to the hard drive, grabbing others off the drive for their turn in the barrel; basically paging chunks of blocks into and out of RAM until everything is finished. You know, the way VMMs work way deep down in the operating system? Yes, things won't complete in real time, but it's certainly better than the curtain coming down totally – and Mojang getting even more bug reports therefrom. Your typical More Work Up Front in Exchange for Much Less Work Later tradeoff.

None of this is trivial, btw. Not even. It's a shitload of work; something I learned the Hard Way from writing custom, embedded, preemptive, 'hard' real-time operating systems from scratch. (Not recommended for the faint-of-heart unless you're a certified, card-carrying masochist with an adrenaline-rush addiction. I am.)

Invariably I also see the 'ticking entity' bit when MC crashes. Now, in my case, I'm not the least bit surprised that javaw is crashing (it's not MC that is giving me fits, but Java itself, on top of which MC runs) because I'm trying to detonate an obscene amount of TNT. First time I got this 'ticking entity' bit I was in the middle of detonating a small thermonuclear bomb's worth: about 30 kilotons of TNT, that is, a little over 18,000 TNT blocks and twice the yield of the first atomic bomb. Moments before everything died the Java VM exclaimed in no uncertain terms, "What do you think I am, a bluddy Cray Jaguar? You deserve this." and then promptly went apeshit. But, in almost every case, the VM went apeshit because it ran out of heap space. That is the real problem here: no memory left on which to blow things up.

Mojang, bless their hearts, recommended the following magical incantation when invoking Minecraft:

javaw -Xms512m -Xmx512m -jar minecraft.exe

On Windows platforms, open Notepad, copy the above line into it, change the file type to 'All Files' (it wants to be a .txt file), save the file as <some name>.bat in the same folder in which minecraft.exe lives and then click on this batch file instead of minecraft.exe directly.

What this does is set the heap's (the chunk of memory in which minecraft remembers things like how much progress a piece of TNT has made in exploding, where it is as it's flying about as the result of other blocks blowing up and really cool, arcane things like that) initial and maximum size to some larger value (512 megabytes), assumed to be larger than what it's set to now, except that 512m is about 512m smaller than the default size I'm currently using (910m is what's shown when MC is running and I press F3), suggesting that this bit of sage advice from Mojang's demigods is now a bit dated.

Problem is, when I do this for the latest MC release, that is, v1.6.1, minecraft.exe shits the bed completely without even so much as a swan song. Setting -Xmx option to some higher value and minecraft.exe never even gets a chance to crash at all - javaw doesn't get past the 'invoke javaw without an error' stage. Thing is, javaw is pretty mum about such things as why it died, given its reluctance to talk to console windows.

I'm no java expert, but if some of you are, please, somebody please give this problem some attention? I've a megaton of TNT (a sphere with a diameter of 159 TNT blocks) just sitting around waiting for somebody to set it alight. It is after all, about to be July 4 in the U.S. and merely the day before July 5 in the U.K. 🙂

This video shows a short pulse racing away to the far end of the tunnel and returning about 24 seconds later, crossing the near bridge and then racing off again:
https://docs.google.com/file/d/0B_DqKqLT946KLURwckpfQ0QyaHM/edit?usp=sharing

This one shows what was originally a 100-200 ms pulse stretched to several seconds' duration by virtue of my character flying through one of those weirdly-lighted areas in the tunnel just as the pulse raced through:
https://docs.google.com/file/d/0B_DqKqLT946KaGM1b01wRzZKazQ/edit?usp=sharing

And finally, this (rather longish) video shows these patches of source-less lighting, the jagged boundary between light and dark in one part of the tunnel, how the pulse 'resets' the lighting behaviour back to Normal most of the time and, at the very end, the pulse as having been stretched considerably. I cut off the recording early, but the pulse duration had increased to about 12 seconds:
https://docs.google.com/file/d/0B_DqKqLT946KNDllWkNOTlV5T0k/edit?usp=sharing

The first patch of source-less light can be seen at around 0:22.
The sharp, jagged boundary between light and dark can be seen clearly at 1:29.

Thanks for looking into this. I really appreciate it.

Please note that I've since removed the Powered Rails due to the apparently intended behaviour of minecarts stopping once they're out of view.

Thanks, Kumasasa,

They're much larger than 10 MiB, unfortunately, but definitely under one gig. I'll upload them to my Google Drive and post the link.

This behaviour is intended? Truly? Why?

I noticed this very recently after launching an empty (stock generic) minecart down 1200 m of powered rails. Once the cart had disappeared from view, it stopped moving - unless I went after it. But, when my character rode in the cart, it completed the trip normally (as might reasonably be expected of a real minecart), bounced off the end-block and returned to its launch point, as expected.

As a follow-up experiment I placed Detector Rails at 100 m intervals over the full length of the tracks, ran Redstone alongside them back to the launch point and then terminated the circuit with a Redstone Lamp just for lulz. The lamp winked three times, not the twelve it would have had the minecart not had this surprising and inexplicable behaviour.

I do wish you would fix this. This behaviour may be intended, as you said but, quite honestly, it is indistinguishable from a real bug.