eluMC

@Amanda While I certainly hope that isn't the case, I agree that it would be helpful if Mojang provided some clarity on this issue. Because even if that is the case (expected behavior) then it still needs tweaking. It's far too extreme.

AFK farming is practically a fundamental staple of Minecraft and has been since the beginning. There is plenty of satisfaction a player can get in thinking through strategies on how to utilize game mechanics to optimize resource gathering... in the quintessential RnG game of the past decade. If that's taken away... Many will stop playing.

I concur with @recon; This is most definitely not limited to a multiplayer scenario. I experience the same abysmal spawn rate in both SP/MP with the same world.

I really hope this gets some attention soon. I was throughly enjoying the new release until I discovered this bug and have completely stopped playing. I'm certainly not going to allow my Realm subscription to continue until this issue is addressed.

With regard to evidence I've made a rough demonstration video to bring light to the issue. The following is the video description:

"Rough piece of evidence to demonstrate the stark contrast in mob spawn rates between 1.12.2 and 1.13

The video is divided into two parts showing virtually identical general mob farms. Identical in the sense that they are both built above an ocean, the spawning pads are at Y=224 with the player at Y=200, the collection area is a 2x2 square placed in the center of 4 neighboring chunks which puts each 8x8 spawning pad in it's own chunk and they also have identical construction.

In the 1.12.2 test, after setting difficulty from Peaceful to Hard the stats show mobs beginning to populate in the farm and after about 2-3 minutes it appears that they collect a little faster if I move around the collection pad (somewhat irrelevant, but I apply the same technique in the 1.13 test). While I feel I've collected more from this farm in a similar amount of time, after about 5 minutes you can see I have 40+ mobs on the collection pad with a few dozen more still up in the farm.

Alternatively with my 1.13 farm, after nearly 5 minutes only 1 mob made it to the collection pad regardless of my movement. There are also fewer than a dozen... at times fewer than 5 mobs inside of the dark room itself.

I only have loose suspicions that the new ocean mobs, both friendly and hostile are having some adverse effect on the mob cap, and/or mobs that are supposed to be despawning beyond 128 blocks from the player are not despawning. I have no conclusive evidence to identify where the problem exists. I only have this empirical evidence that a problem DOES exist. I've come across many other people that have describe similar problems with mob spawn rates in 1.13 even in biomes other than oceans."

Video: https://www.youtube.com/watch?v=mIYUTymzsEY

Video should be available in 1080 and 720 HD resolutions following further processing by YouTube.

I have the exact same dark room mob farm built in a world for 1.12 and a world for 1.13. They are both built above Y=200 over an ocean with no nearby islands (within 8 chunks, easily) and positioned at the junction of 4 separate chunks, with 1 8x8 spawning pad in each chunk.

Sitting idle by the 1.12 farm I roughly get between 40-60 kills every 5 mins. Meanwhile I sat by my 1.13 farm for 10 min and killed 1 skeleton.

Where are we supposed to comment/address this issue for the Java edition then? The same bug exists. Shouldn't the scope of this bug report change rather than directing people to other parts of the JIRA site where inevitably a moderator will just it "duplicate/resolved"?

Just dropping my name in the hat as well; can also confirm (v1.13 for Win7 Java edition). I started a new world when the new version came out, completely Vanilla on my Realm, found an ocean and built a standard dark room general mob farm up in the sky. While a few mobs did spawn on the structure while I was building it... nothing has spawned since completing it.

I get where you are coming from, I do, but the fact of the matter is the lag isn't necessarily a bug. Lag is a fundamental part of any game and players are going to experience lag when things like this are pushed to their limit.

A fill clock functions off taking advantage of how chunks are loaded each game tick. The lag only occurs when fill clocks are overused within the bounds of single "chunk column" (the magic 63 limit), or when extreme amounts of command blocks running off fill clocks were being used. Even then, the experience of lag was localized to the region where the command blocks exist.

Mojang recognized how fill clocks were being used almost exclusively to keep certain command blocks running every game tick. The choice then becomes to either radically modify how chunks are loaded to optimize the performance of these fill clocks (which btw, are not a feature added by Mojang, they are an exploit of the game mechanics and could even be labeled a bug all on their own), OR add a mechanic to the command block that allows them to be on all the time without needing to be powered by redstone, thus allowing the block/chunk updates to be avoided altogether.

The latter obviously wins out because it is easier to implement, it follows the natural progression of how command blocks are evolving, and it doesn't stop any previously used functionality of command blocks or fill clocks. Map makers/operators can keep doing what they are doing and the experience of lag from chunk updates is side-stepped.

So yes, this is going to be labeled as "Resolved" and "Works as Intended" because chunk updates do need to happen and Mojang has added features to the game to allow you to avoid them when using command blocks in large quantities.

There is no more need for excessive fill clocks running command blocks anymore with the implementation of the new command block features. Stop your fill clocks and set all the cmd blocks to always on. No more lag. Thus this "bug" is now a moot point beginning with 1.9 and there will likely be no need to address the lag issue.

Obviously that was a joke...

Glad to see this reopened and confirmed. Just wanted to add that it's still occuring in 15w34b; however behavior seems slightly different perhaps...

I created a world with seed 3076852608952083953, saved and quit, restarted then used an eye for the FIRST time ever in the world and it led me to the portal room. Then saved/quit/restarted again and it pointed to a spiral staircase.

previous snapshots had a legitimate bug where spawner rates were entirely too fast. (i rather liked it actually) but since that's been patched, it seems like it was over done somehow. Spawner rates now seem WAY too slow.

Even at hard difficulty, i spend a few minutes idle by my skeleton spawner and only collect ~6 skeletons... maybe fewer.

It seems slow enough that mob spawners generally are no threat/challenge when encountered, and building a grinder/farm out of them is almost pointless. I hope there really is something wrong as of 14w31a because it pretty disappointing and I'd hate to just receive a "works as intended" response.

Look at the screenshots again. The command block IS outputting even thought im outside the defined region. That's the issue. The arguments are not working as intended.

Seeing the same behavior with totalKillCount, some sort of "sorting" parameter would be greatly appreciated 🙂

I think that nicked it. Yeah I had copied over the default block states and model files into my resource pack when this problem reappeared and forgot about them. Alright, I'm satisfied that this is all fixed.

Nope, was still occuring in 27b and now still in 28b. https://www.youtube.com/watch?v=lszMSDq4UZ0

Video demo of redstone wire bug for custom texture packs, behavior as of 14w27b - https://www.youtube.com/watch?v=KBGjIIDkO9o

Quality isnt the greatest but it was a dirty render just to get the point across more clearly.

When redstone wire is placed on a descending surface facing in the East or West direction it takes on the wrong orientation until more wire is connected to it at the same Y level. This only occurs with custom texture pack PNGs. It occurs regardless of orientation of the PNG files.

Okay through a little further investigation I'm discovering that there is some other bug at work here, slightly related. I'll have a video demo up in a moment. I will add though that my PNGs that work in 1.7.10 are oriented the same way as the Default texture pack that works in 14w27b. But when I use those same PNGs in 14w27b, they are 90 degrees off. So looking at the default PNGs and comparing them to your custom texture pack doesn't exactly clear things up.

Uploading 2 new screen shots. First shows the redstone wire PNGs working fine in my texture pack for 1.7.10 ... and then not working in 14w27b.

If i rotate the PNG files 90 degrees I still have orientation issues when placing redstone wire across two blocks (and two blocks only) that are seperated by 1 level in the Y direction. If I extend the wires further, the orientation corrects itself.

If it's not blockstates then I'm confused as to how to solve this on my own.

I'm most definitely getting a "Not entirely fixed" vibe. I'm submitting 3 screenshots, running 14w27b. First one shows how my texture pack's stock redstone texture behaves, totally screwed up. Second shows the ones I altered (rotated 90 degrees to dodge the bug). You can see there is still something wrong... or something that still further needs explaining. As in, what to edit to make redstone going up the vertical face of a block be oriented correctly. 3rd shows the default texture pack behaving just fine as usual.

I'm still finding it unclear whether this is up to users to fix on their own or if this will be fixed for GOOD.

Is it a 'blockstate' issue? I noticed the default texture pack has a new directory with JSON files for blockstates. Is this related since legacy resource packs don't have this as a reference?

Still occurring in 14w27a