Talk:Observer

To do list
–Preceding unsigned comment was added by Sealbudsman (talk • contribs) at 20:24, 05 June 2016 (UTC). Please sign your posts with
 * 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?)


 * 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:
 * {| class="wikitable"

! 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)
 * 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)
 * 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)


 * 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 &middot; 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)