mojira.dev

The.Modificator

Assigned

No issues.

Reported

MC-55293 Player or entity selectors don't get turned into player or entity names in the "summon" JSON argument Invalid MC-12557 Entities that travelled through a Nether portal can not travel through a Nether portal again Duplicate MC-12555 Players get completely stuck when riding a minecart into a nether portal Duplicate MC-11360 Toggling redstone-powerable light-emitting components from more than 10 chunks away doesn't update their light emission correctly Duplicate MC-11193 The order in which powerable blocks (e.g. redstone dust blocks) along a wire are powered or de-powered is not clearly defined and causes a non-deterministic behavior for redstone contraptions Confirmed MC-10943 Minecraft doesn't use code page 437's Greek beta glyph for the German sharp s Duplicate MC-8194 Redstone signal propagates very strangely in unloaded chunks Duplicate

Comments

Okay? Just curious: Why do newer ticket "win" over older tickets as being the duplicated (not: duplicat*ing*) ticket?
I mean, this ticket is from 2013 whereas MC-93132 is from 2015. Shouldn't the status on this issue rather be tracked here in this ticket?

No. Tested the build of the YouTube video linked in the description with 16w43a.

When loading a save file, an already running clock still had that problem.
When resetting the clock however, I was not able to reproduce the problem anymore.

Updated. Please reset ticket status.

Aaron, this ticket is not about that issue. This ticket is about the issue that the order in which powerable blocks (e.g. redstone dust blocks) along a wire are powered or de-powered is not clearly defined and causes a non-deterministic behavior for redstone contraptions. Please check the title, the description and the video demonstration.

I'd like to add that /say Test, @p[]! does also not work (as discussed above). However, I'd still vote to close this ticket because whenever someone wants to accomplish something like this, he/she can easily use /tellraw now. So there is no need for changing the current behavior.

Yep, it is. Also, it might be related to MC-11193.

Well, yeah: /say @p is there. Hello, @p! @p, What's up? will still result in the chat line The.Modificator is there. Hello, @p! @p, what's up?, so the behavior is not changed.

However, since the command /tellraw was introduced a few versions ago, there is a wordaround for this now.

Problem continues to exist.

And that's exactly what this bug describes: The selector does not work for any other command but /tellraw and /title. So why should it be invalid?

Or to put it differently: Currently there is no way to refer to player names in the summon command. Which is the actual bug behind this.

Yes, it is. By the way: This bug is dependent on the orientation of the dispenser.

Whoops - sorry. This bug still exists in 1.7.2.

I just found a frozen comparator clock (as shown in screenshot "comparator-stuck.png) in a dedicated server world (version 1.5 for both client and server). I removed all chunks not related to the problem (with MCEdit) and uploaded a zipped version of the world as "comparator-stuck.zip". The frozen comparator is located at 54/58/-31

Unfortunatley I have absolutely no clue how to re-produce this. It used to occur a few times before but always happens seemingly randomly. With the comparator clock cable lying on a chunk border my guess would be that it has to do something with unloading and loading chunks - especially with multiple players moving around in the world.

I also have a feeling that this used to happen only when restarting the server. (And I also have a feeling that the chunks in which the comparator clock is located were not be loaded in the moment the server shut down.)

This problem already used to occur before the change in 13w10b. This version 1.5 occurence proves that the 13w10b change did not help in this case though.

Confirmed for 1.5 pre-release.

Yeah, that looks like it is the same bug. I haven't tested my setup on 1.5 yet but - based on your comment - will add 1.5 as an affected version now.

My suggestion is to close this ticket. Either with a "works as indended" resolution or a "won't fix" resolution.

For all people who don't want to read that long text I wrote for the description: Simply take a look at this video I made -> http://www.youtube.com/watch?v=e5hUYLC8Tms

Even when receiving redstone signal pulses they seem to only fire as long as the items still fit into the container. So I think it must have been some other change. Anyway: Problem is solved - ticket can be closed.