Ron F.

Still present in 1.6.2 Pre-Release.

While I have not tested using the OPs method, I can say this still exists in 1.6.1 Release. I'm using "non-existant" players to track map specific options. This was tested in single player as I am developing a map that will be intended for ssp and smp.

Create a configuration scoreboard:

/scoreboard objectives add CONFIG dummy CONFIG

Add it to the sidebar

/scoreboard objectives setdisplay sidebar CONFIG

Add yourself and a non-existant player

/scoreboard players add "your_real_player_name" CONFIG 0
/scoreboard players add "non-existant_player_name" CONFIG 0

Create some redstone contraption to check with. I used a redstone clock->command block->comparator->redstone dust->piston

Edit the command block to use this command:

/testfor @a[name="your_real_player_name_here",score_CONFIG_min=0]

The Piston will extend.

Edit the command block to use this command:

/testfor @a[name="your_non-existant_player_name_here",score_CONFIG_min=0]

The Piston will retract as the non-existant player is not online.

A work around could be to use enitre scoreboards for EACH option and attach scores to all players, but that I would think, would add unnecessary bloat to the scoreboard.dat file.
I hope this is not intended behavior. This scoreboard system will have much more potential as custom variable system.

Kumasasa - After removing the trailing comma, I received a different error.

Jonathan - You lead me in the correct direction. Apparently, snapshot 13w24a and prior allowed mcmeta (and texts) files to list more frames than there were in the image. In the example above, I had 0-7 (8 frames), where as the image only has 7. Removing the reference to 7, resolved the issue. So as of 13w25a, 0 is still a valid index start.

Thanks to both of you for your help.

Thanks Kumasasa. My animations were converted by the ender tool. I'm still getting used to this new format. Ill follow up on that thread.

Grum,

Does this mean we should edit out mcmeta files or leave them as is for the next snapshot? I had a the same issue.

I'm only commenting to help the user/OP, I'm not asking for this to be reopened as I don't believe its a bug in MC specifically.

This does affect the Logitech G35 headsets too, even with the newest 8.45.88 drivers with the 1.6 launcher. MC 1.5.x and lower are not affected by this. It is an odd issue though. In my case when I disable surround on the headset (via the hard switch) the walking sound of the player only comes out on the right side...only when walking on anything other than wood. When I walk on wood, the sound is correctly coming from both sides. Since testing 1.6 snapshots I've had to enable the surround to hear things correctly, but am not a fan of surround in MC. I'm too used to stereo.

Also I recorded a video in Fraps and played it in VLC to see if it was the headset drivers or MC...but the audio recorded in Fraps was fine. So it has to be the logitech driver.

To resolve this, I simply changed the driver for the headset to Microsoft's "USB Audio Driver". Yes you kill the surround feature, but the Minecraft sound works fine.

This was very similar to an issue with a version of Flash that came out some time ago where flash video sound only played on the right part of the headset. I forget if Logitech fixed it in later drivers or Adobe did in a Flash update.

In any case, I hope this helps anyone having this issue.

You might be correct Stefan with the hitboxes and it may not be limited to fences/walls. Here is a simple test for the suffocation:

1.Create a room say 6x6x2 of cobble/stone blocks (not the walls).
2.Spawn a fair amount of chickens/babies. Say 10.
3.Sit a watch (from above) for a few minutes as they tend to group in corners or along the wall.
4.Notice that some are nearly half way into the blocks (clipping).
5.Close the map.
6.Load the map.
7.X amount of chickens suffocate or rarely escape the block wall.

I tested this with sheep, creepers and zombies. The creepers are less likely to suffocate than the zombies. Creepers are slender compared to zombies as zombies extend their arms. Baby sheep are as likely to die as chickens and chickens/baby animals are smaller and or longer.

So it seems to me this is more of a collision issue with the game knowing where a mob is (or the mob model itself) than specifically the hitboxes of fences/walls. It could even be a client/server issue as both SSP and SMP use a server now. Like the server saying "the mob is here", but the client is saying "ok they are in the wall now".

This bug, whatever the cause, is more noticable to us since fences/walls are smaller (and transparent) than a standard block and the mobs can pass through them without suffocating (most of the time) when the chuck loads. I think there is a decimal number off in the code some where. 🙂

Chickens (didn't test other mobs) seem to like getting stuck in the corners of fences. As more get stuck they are pushed around to adjacent blocks, in this case the surrounding fences over a period of time. See screenshot above.

I've also caught the suffocation in solid blocks on video. I have yet to render it (it was part of a lets play), but if that is needed I'll post the link once its up.

This is still an issue in Snapshot 13w06a. Has anyone tested if hostile mobs can "penetrate" walls/fences?

The more of us that "up vote" the bug the better. Added my vote.

There are hardly any dust in the fans. I want to side on maybe a driver issue that appears to be affecting the snapshot. I will update those after work today.

Thanks for your time.

So I loaded a new 13w03b world in creative to play around in. Less than 2 mins in, both monitors started flashing black, minecraft lagged, choppy audio, etc. So I forced crashed it to get the report. Windows responded after that.

Ok...the plot thickens. Those last three screenshots I posted appear to be missing those purple dots (ignore the enderchest particles). I killed dwm.exe (Desktop Window Manager) and that seemed to fix the dots. Both in game and in the screenshots!

This lead me to believe dwm.exe is the culprit. So to troubleshoot it I went and enabled "Disable Visual Themes" and "Disable Desktop Compostion", but Minecraft.exe doesn't seem to do that. My theme switches to basic then right back to the normal Aero Theme.

I'll have to do more testing on my end. I'm trying to replicate the first screenshot I posted with the textures messed up.

When back in the game, you can see how the purple dots are distorted where the shadow is in front of the blocks and a little on the blocks themselves.

This was what the main menu looks like after running minecraft after that force crash. Note the purple distortion is similar to the dots while I was in game.

Here is the force crash report after getting the dots in the other attached screenshot.

This occurred just after a quick flash of black. Force crashed Minecraft for report.