Talk: Observer

To do list[]

• update {{BlockSprite}}
• add a discussion of what it detects, including any differences from a PC BUD
• duration of the redstone signal
• numeric ID
• data values
• block entity data (or at least, does it use a block entity?)

–Preceding unsigned comment was added by Sealbudsman (talk • contribs) at 20:24, 05 June 2016 (UTC). Please sign your posts with ~~~~

Answers to some of the bullets in your To-Do list:

• It detects any changes to a block; more specifically, it detects anything that would change a block's ID or data value.
• It always outputs a 1 tick pulse.
• ID is 251
• The data values appear to be:

DV	Description
0	Facing Down
1	Facing Up
2	Facing South
3	Facing North
4	Facing East
5	Facing West

• It doesn't appear to be block entity (there isn't any game code indicating it is).

Jocopa3 (talk) 04:10, 6 June 2016 (UTC)

It sounds like it detects more than what a BUD detects; from what I recall, a BUD wouldn't detect data value changes

Can I ask, I'm curious, how does a person look into the game code of pocket edition? – Sealbudsman ^talk/_contr 12:12, 6 June 2016 (UTC)

Piston BUDs can detect data value changes, for example, increasing the number of ticks on a repeater or change the signal strength of redstone dust. I haven't found any differences between the two contraptions yet, but I still have quite a few configurations to test.

Pocket Edition and Win10 Edition are compiled into machine code (assembly), so a disassembler like IDA or Hopper would work. However, you can't decompile the game back into working C++ code, only assembly. The Android version of the game is the most useful version to disassemble as almost all of the game's classes and functions are named and labeled. Here is an example of what the assembly code generated by IDA looks like: http://i.imgur.com/4ddRRgm.png

Jocopa3 (talk) 23:38, 6 June 2016 (UTC)

That's cool, thanks for pointing me in the direction of some good disassemblers. – Sealbudsman ^talk/_contr 20:53, 10 June 2016 (UTC)

Hi! It seems it also detects redlight power changes coming from a daylight sensor. So for every light change by 1 it sends a redstone signal because it detected the change. The redstone coming from the daylight sensor has to end at the "face" side of the Observer, also works from top to bottom: daylight sensor, redstone, observer-face. –Preceding unsigned comment was added by 62.227.205.230 (talk) at 19:47, 05 December 2016 (UTC). Please sign your posts with ~~~~

What IS an observer[]

How can we characterize the difference between PE observers and PC observers, besides listing the specific things they do / do not detect? Are they detecting different classes of things? "Block updates" versus "block state changes"? – Sealbudsman ^talk/_contr 17:45, 9 November 2016 (UTC)

I just made a large edit to the page to clarify the differences between the 2 editions. How clear is it?

SuperGeniusZeb (talk) 01:27, 1 January 2017 (UTC)

It's certainly in depth, and yes it's clear; I think it could stand to be broken into subsections due to its length, maybe having a concise intro under Behavior for whatever is common to PC/PE, if it lends itself to it. I can't remember if this wiki has pages which talk about strong power, Pocket edition vs PC block updates, extended block state, or activation power - if so, those could be linked. If not, there is an opportunity. Pretty cool overall! – Sealbudsman ^talk/_contr 06:43, 1 January 2017 (UTC)

I think there are some problems with some of the information added for PE. For one, the output pulse is usually only 1 redstone tick, though I have seen 2-tick (4 game tick) pulses associated with piston head extensions. Also, the question of strongly or weakly powering blocks doesn't apply to an Observer, does it? Isn't that only an attribute of transmission components, that defines whether opaque blocks powered by them will in turn power redstone dust? And finally, "Observers in the Pocket Edition do detect block updates, so they function just like any other block update detector would function in that edition." As far as I know, the only "block update detector" prior to the Observer depended on quasi-connectivity, which never existed in PE, so isn't this saying they function just like something that never existed?

I've studied inconsistencies in the behavior of Observers in PE but I've been reluctant to make any changes to the wiki because I haven't known how to tell what's by design and what's just a bug. Auldrick (talk) 10:02, 1 January 2017 (UTC)

Are you sure about that 1 redstone tick thing? The rule that redstone torches can only be inverted by a pulse of 3 game ticks (2.5 redstone ticks) still applies in MCPE, and I've tried pulling and pushing observers into place, and they always invert the torches, so they're definitely never outputting 2 game tick (1 redstone tick) pulses. Unless that redstone torch thing DOESN'T apply in MCPE... :S

I'm not understanding that about pulling/pushing observers, but try this (all measurements in redstone ticks, hereinafter 'rticks'): Build a trivial repeater/torch clock. It cycles 2.5 times/second (4-rtick cycle, 2-on/2-off). Drop an observer next to it, facing any redstone wire in the circuit, and hook a wire to the observer's output. That output wire is clearly flashing twice as fast as the clock circuit, so 2-rtick cycle, 1-on/1-off. (Hunh--I just realized you could use this as a frequency doubler!) Feed the observer output into a solid block with a torch attached to it; the torch flashes at the same rate. So in Win 10 Edition (and I assume all MCPE) torches can respond to 1-rtick (2 game tick) input changes. Does that address your question?

I actually discovered this soon after MCPE got redstone, but I thought the wiki rule might just be wrong. That was back before I knew the wiki could be trusted. (BTW, you have a typo; 3 game ticks is 1.5 rticks, not 2.5.) Auldrick (talk) 06:40, 10 January 2017 (UTC)

Ok, it's been quite some time since I discussed this, but since then I've done a lot of thorough testing, and discovered that some of my previous information was in fact incorrect. After some talking with some bugtesters and devs at Mojang/Microsoft, as well as some careful creative world testing, I can confirm the following: redstone torches in MCPE DO respond to 1 redstone tick (2 game ticks) pulses; observers output 1 rs tick pulses just like in Java Edition, and observers output a 1 rs tick pulse, like repeaters. However, the DELAY of observers is a bit of an interesting story, and the reason is this bug:

https://bugs.mojang.com/browse/MCPE-15793

This bug causes the delays of repeaters, comparaotrs, & redstone torches to be 1 tick shorter than they should be, when they are activated by a world change (lever, piston modifying a circuit, pressure plates, buttons, etc.), but the delays are correct when activated by a pure redstone component ticking. Observers, since they are activated ONLY by world changes, are always affected by MCPE-15793, and so they always have a 2 rs tick delay, even though they SHOULD have a 1 rs tick delay, like in Java Edition. I'll correct the information on the page to reflect this... hopefully MCPE's redstone system will be fixed in the future, so figuring out stuff like this is easier. SuperGeniusZeb (talk) 19:37, 15 April 2017 (UTC)

Hmmm... just tested a piston head extending/retracting into an observer's detection zone, and pushing/pulling blocks into it. The piston head extension & block retraction caused the observer to emit a single 2 game tick pulse like everything else, but a piston head retraction and pushing a block into place caused the observer to emit TWO pulses, though both were still 2 game ticks each. They seemed to be separated by either 1 or 2 game ticks... I couldn't tell for sure. The weird thing is, that trying to repeat the double pulse by detecting the output wire connected to the first observer by using another observer didn't work. The second observer was activated by both pulses, but the output wire simply stayed on for one long 4 game tick (2 redstone tick) pulse. I confirmed this using repeater lines. The 1st observer, when connected to repeaters, showed an ON-OFF-ON pattern, but the 2nd showed an ON-ON-ON-ON pattern and... ugh. I'm a bit confused now.

The double pulses are separated by 1 rtick according to my oscilloscope, but who knows how it would behave if presented with a 1-game-tick signal? But I tested again and it appears that you're right, the pulse durations are only 1 rtick. I was probably thinking about their delay, which is 2 rticks after the rising edge of the pulse that activates the piston. (I use the latter measurement since I don't know any way to detect when the piston head begins to move, but I can measure when it gets its activation pulse. I'd rather rely on what I can measure.)

The reason your second observer had the puzzling behavior is that observers take 2 rticks to detect changes in redstone dust power levels. That's the only thing I've discovered they're slow to respond to (other than piston extensions/retractions the way I measure them), so it might be a bug. In any case, it doesn't have time to turn off its output before it's time to turn it on again.

If you're interested, I have a very reliable device I'd be willing to share with you, for measuring the relative timing of two pulses. It detects rising edges as little as 1 rtick apart and is insensitive to pulse durations. You can measure the exact number of rticks between two signals by using repeaters to retard the earlier edge until they're synchronized, and you can detect a falling edge by using a torch to invert an input, compensating for the torch delay on the other input. It's also bilaterally symmetric, so any version specifics (including timing bugs) should cancel out. For example, to measure the observer's redstone dust delay I set it up with an unpowered wire hooked to input A, and an observer measuring a low-powered wire hooked to input B; then I placed a torch where it would power input A and change the power level seen by the observer. They synchronized when I delayed input A by 2 rticks, so the observer must have taken 2 rticks to detect the change, QED. Auldrick (talk) 06:40, 10 January 2017 (UTC)

One thing I am sure of, though, is that the observer acts identical to a BUD in MCPE. I know this, because during 0.15, the ice-melts-into-floating-water bug was still a thing in MCPE, and this floating water acted as a block update detector. I compared several cases where certain things wouldn't activate an observer in MCPE, and they also wouldn't update the water, either. The ice-melting-bug is fixed now, though I think there are still a couple other bugs that can work as BUDs in MCPE right now. (Try pushing the top of a sugar cane plant with a piston, for example.)

I'll have to do more research and ask the devs to know for certain about the other Observer stuff, though. I'm fairly certain that the behavior listed for MCPE is at least the INTENDED behavior...

SuperGeniusZeb (talk) 15:50, 5 January 2017 (UTC)

I confess I still don't understand what you're trying to say. Are you just saying "the Observer can do anything in MCPE that a BUD switch can do in MCPC"? While I think that might be slightly too bold a claim, I wouldn't have a big problem with that. Or are you saying "the Observer detects the same kinds of block updates as a BUD"? I wouldn't presume to challenge that since I've never played the PC version, but I can't help wondering if it's really 100% true. But I have a serious problem with "the observer acts identical to a BUD in MCPE". That sounds like I should be able to just plug an observer into a Panda/Etho/Mumbo Jumbo circuit design and I'm done. I've followed lots of YouTube redstone build tutorials, and I can tell you without a doubt it's rarely that simple. As far as "other bugs that can work as BUDs in MCPE right now" — uh, yeah, well, not that I think you were actually suggesting it, but the last thing I want us to do is create a new quasi-connectivity fiasco. Auldrick (talk) 06:40, 10 January 2017 (UTC)

I'm saying that the functionality of a BUD, that is, to detect block updates, is exactly how the observer in MCPE behaves. It detects anything that causes a block update on the spot it is observing. Anything that doesn't cause a block update will not trigger an observer. This is in contrast to the current Java edition observer, which detects changes in the basic blockstate of the location it is observing, regardless of whether or not it causes a block update. This also has the effect of Java edition observers not detecting things that an actual BUD would be able to.

And as for the BUD bugs, I was just using them as an example to prove that MCPE observer behavior is, in fact, that of a block which detects block updates. (Something which may seem implied, but is actually not the case with Java observers, as mentioned before.) I don't want those bugs to stay any more than you do. (And actually, the one I used was fixed back in 0.16 anyway. :P)

I'm rather busy, and I'm still looking into the whole torch-inversion-min-time & observer stuff, so I can't reply to your other replies, but I'll try to get to them later. :) SuperGeniusZeb (talk) 05:24, 21 January 2017 (UTC)

[edited] I understand now. You're using "BUD" simply to mean something that detects block updates. That was opaque to me because having never had the Java version (I don't have a GPU), I only have a vague idea what a "block update" is in terms of what happens internally, which is my default way of mentally modeling software. Thus, "block update" doesn't have a technical meaning to me, whereas "BUD" does—but only in the Java version where it denotes one of several circuit configurations. Thanks for helping me understand. – Auldrick (talk · contribs) 06:10, 21 January 2017 (UTC)

Adding more information[]

Hi, I'm not all that fluent with formatting Wikis but I thought of trying to add more clear information regarding how to use the Observer block. There's a brief mention of which end is which (input/output) but no accompanying screenshots and seems rather unclear. I could make something to add but would an administrator just remove it again? Tends to happen. --SwordofGold (talk) 13:17, 28 November 2016 (UTC)

I see what you mean. Go for it! Someone will improve it with wiki formatting and conformance to the style guide. An administrator here wouldn't just remove your edit, if you're editing in good faith; we've got pretty good admins here. – Sealbudsman ^talk/_contr 16:43, 28 November 2016 (UTC)

A sprite of the first Java edition observer model is needed[]

From 16w39a to 16w43a, the observer texture in the Java Edition was messed up. (It was facing the opposite direction it should have been.) However, there are only icons for the 16w43a/MCPE observer & the current 1.11 observer. If anyone knows how, could someone make an icon that is essentially the same as the MCPE observer icon, except with the arrow texture rotated 180 degrees?

SuperGeniusZeb (talk) 01:24, 1 January 2017 (UTC)

Behavior oddities[]

After some pretty extensive testing of what an Observer can and can't detect in Windows 10 Edition, I've found several asymmetries in behavior that seem unintuitive or just plain odd to me:

• The Observer detects any change done via the UI to the inventory of a Chest or Trapped Chest (i.e. add items to/remove items from a stack, replace an item/stack with a different item/stack, put something in an empty slot, or empty a slot). It also detects insertion of an item into an empty slot by a Hopper, but nothing else a Hopper might do, not even pulling the last item out of a slot or emptying the entire chest.
• The Observer detects the enlargement of a Chest or Trapped Chest into a double chest, but not the inverse (reduction of a double chest to a single one).
• The Observer detects breakage of Redstone Dust, but not placement of it. As far as I know this is the only block placement it doesn't detect. If the dust is placed somewhere where it will be powered, the Observer does detect its change of power level, which happens 1 redstone tick after placement.
• The Observer detects an attempt to add water to a Cauldron from a Water Bucket, Water Bottle, Splash Water Bottle, or Lingering Water Bottle, even if the Cauldron is already full. It also detects removal of water by the same items, but only if the Cauldron isn't empty.
• The Observer detects the opening or closing of a Door or Trapdoor whether done manually or via redstone activation, but it only detects opening or closing of a Fence if it's done manually.
• The Observer detects a change to the delay setting of a Redstone Repeater or the mode setting of a Redstone Comparator, but not to the mode setting of a Daylight Sensor.

Some of these results make me suspect they're bugs, but before I go make a bug report I'd like to invite others to test my findings on other editions, especially Pocket Edition, and to comment on which ones they agree seem like bugs. I'd also like to invite comments on whether and how much we should add to the article as documentation of what can and can't be detected by an Observer, bearing in mind that we would need to have separate lists for PC, Console, and Pocket editions. Thanks in advance for any assistance and comments. – Auldrick (talk · contribs) 20:32, 7 February 2017 (UTC)

Changing the contents of a container or cauldron makes sense. However, anything you described that is not detected is probably a bug and should be reported. Failed attempts to put water in a cauldron getting detected is also a bug because the block is not actually changing. The Blobs 23:16, 7 February 2017 (UTC)

In 1.13 I can attest that several of these behaviors have changed. Namely, reduction of a double chest is detected, placing redstone dust is detected, attempting to fill a cauldron but failing is not, opening and closing a fence gate with redstone is detected, and changing the setting on on a daylight sensor is detected. It seems the only thing not detected is when items pass through a hopper. I wonder if this is intentional. --Pizza2004 (talk) 21:24, 18 August 2018 (UTC)

It's intentional, observers on Java Edition only detect block state changes, and items moving through hoppers doesn't cause block state changed. Opening a fence gate, changing the daylight detector setting, reducing a double chest etc. all cause block state updates. On Bedrock, observers detect block updates which are not the same as block state changes (also because block states haven't been implemented in Bedrock (yet?)).--185.138.216.202 08:53, 19 August 2018 (UTC)

LCE[]

Why is this still documenting LCE? I will remove it and if someone objects, I can restore it. I removed LCE from Piston, so I will to this page as well. -FezEmerald (Talk to me|See what I've been up to) 17:38, 19 April 2020 (UTC)