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)

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)