Nasm Nasmus

Lever:
https://gfycat.com/TenseMatureGemsbuck

Random:
https://gfycat.com/EnragedBackAustraliankestrel

Still happens in 1.9.4, but the title is kind of misleading(unintentionally of course), since entities do still despawn in the next tick, it is just the F3 screen that is not clearing its value.

If someone from Mojang is interested, this is where it happens in the code(looking at MCP1.9.2):

In WorldEntitySpawner.java there is the function func_185331_a at line 196.

This function does:

return p_185331_0_.isBlockNormalCube() ? false : (p_185331_0_.canProvidePower() ? false : (p_185331_0_.getMaterial().isLiquid() ? false : !BlockRailBase.isRailBlock(p_185331_0_)));

The p_185331_0_.canProvidePower() part is what is causing this bug. It could be fixed by changing this into:

return p_185331_0_.isBlockNormalCube() ? false : (p_185331_0_.getMaterial().isLiquid() ? false : !BlockRailBase.isRailBlock(p_185331_0_));

Ah of course, that is correct. I had assumed marker armor stands were supposed to be always invisible, unaffected by gravity, etc. I feel like they should be, but that's more of a feature request than anything.

I assume they should still not push entities/get in minecarts though, which should increase performance a lot.

This bug has been marked as Resolved, but I do not understand why.

Using the setup in the description of this bug report, the results are identical to me when using 1.9.2 versus using 16w15b. For me, the tps is still decent at 1024 armorstands(albeit noticeably lower), but becomes unplayable at 2048 armor stands.

Also, with F3 open, looking at the amount of entities, it shows them as still being "rendered". With the suggested code in my previous comment, they did not show up there anymore, just in the total entity count.

Perhaps the patch for this bugfix was not applied?

I made an incredibly simple fix for this in MCP.

I am by no means saying this is the perfect fix, but there definitely is way less lag(16k ArmorStands is decently possible for me now, instead of 1k). I added three if statements to check if an armor stand is a marker armor stand. I'm not 100% sure this has no other implications, but I don't see how it could.

All changes I made were in EntityArmorStand.

In "isInRangeToRenderDist" I simply added:

if(this.hasMarker())
		{
			return false;
		}

to the beginning of the function.

In "collideWithNearbyEntities" I put everything inside:

if(!this.hasMarker())
		{
		}

In "onUpdate" I also put everything inside:

if(!this.hasMarker())
		{
		}

I think the impact of marker ArmorStands can be decreased even further, since they seem to have even less of an impact when you are very far away(and they are in spawn chunks).

@Meri Diana

There is a bug report for lag created by huge lighting updates MC-11571, but not one specifically for 1.9.

The only source of light reaching the pistons in that video is the redstone torch, right? Does the lag disappear if you remove it(and power the pistons differently)?

There is no reason to think this has changed from 1.8 to 1.9. This isn't the place for baseless assumptions.

Not really the place for it, but that most definitely looks to be because of lag, but I see not reason to assume it's just because of the redstone. I'd think there's something else going on on that server, or they just decided to take the 10 dollar option this time. Anyway, no real point in thinking about what could be the cause on someone else's server with many other things going on.

What you have there is a lot of bugs in one picture. Lets look at it not as bugs, but as the way the game works(which is pretty much the case anyway):

Piston powering piston(via converting block 36): the second piston has a 3gtick delay before it is extended.
Player powering piston: the piston has a 2 gtick delay before it is extended.
Repeater/comparator powering piston: the piston has a 2 gtick delay before it is extended.

Piston powering repeater: the repeater has a 2 gtick delay.
Player powering repeater: the repeater has a 1 gtick delay.
Repeater/comparator powering repeater: the second repeater has a 2 gtick delay.

If something should be happening in the same gametick, it comes down to update order, which is way more complicated still.

If you want to know exactly what happens when and why, take a look at the videos in this post: https://www.reddit.com/r/technicalminecraft/comments/39d013/the_precise_timings_of_repeaters_pistons_and/

It can take a few hours to understand it though, but the basics is what I explained above.

It happens because user events are processed before the world tick is increased. The world tick is also what is used by pistons/repeaters and everything. This is also what is used if you want to create a door that can only be opened by a player standing on a pressure plate for example.

The bottom two levers act the same because they are both directly connected to the same redstone.

The one that activates a repeater, then the rest of the circuit causes the piston to be extended in 2 game ticks, and the repeaters to be extended in 2 game ticks as well.

The one that activates a repeater, then a piston, and then the rest of the circuit, causes the second piston to be extended in 3 game ticks. The repeaters are still turned on after 2 game ticks.

Therefore, I would expect the bottom piston to extend later when the left most repeater is powered first compared to when the top most repeater is powered first.

When the redstone is directly powered, the top piston should extend sooner than both of these cases, since the piston will then be extended in 2 game ticks, while the repeater will be extended in 1 game tick.

I think the explanation in this bug report is incorrect.

The difference between a user input and a repeater input is that a repeater input lets a second repeater have a 2 game-tick delay, while a user input causes it to have a 1 game-tick delay. This is because user actions are processed before anything else (including increasing the world tick count).

I wanted to add that it still happens in 15w44a, and that it is actually quite possible to lock it up using normal use as well, not just using the way described by Panda.

A very easy solution would be to refresh all trades of a villager when all trades are locked. Having villagers lock up all their trades does not seem like intended behaviour.

Can you recreate that without the other redstone dust?

In what way is this a dupe of MC-108? There is literally no quasi-connectivity going on here at all.

It's your call, but a screen full of commands of which only 2 lines are the root of the problem is daunting in my opinion. If they don't require any inspection, why would they be there at all?

Also, there's no wiring up the commands, or anything of that sort. It's literally just pasting in two command blocks next to each other, and putting a button on the first.

I have no problem with it if all the example commands are replaced by the two commands I put in this report. I think that having so many code in there will make it less likely to be fixed. If the developers see 6 commands, they first have to research what the actual problem is, here the problem is obvious.

I have no problem replacing this one with a better one, but is MC-81075 really better? There is a lot more commands in there to reproduce the same thing. What information is in that report that is not in this?