Daylight Sensor outputting signal when encased

Confirmed wrong ticket, this one is fixed in 13w01b.

This 'bug' doesn't seem to be fixed in snapshot 13w01b.

I like this functionality, so I hesitate to call it a bug.

Confirmed in 13w01b

Either rename it to a daylight clock or fix this to a light sensor. The way it works now it is actually a daylight clock instead of a sensor, either way a sensor would work on all light sources unless it works on the UV spectrum and can tell sunlight from other light sources.

This behavior makes it possible to count time during the night. So it's a good feature and should stay.

I also agree this behaviour should remain, simply fix the time when the light detector activates and deactivates to sunrise and sunset respectively. This makes it easy and appealing to create lights that auto turn on and off.

The sensor works by multiplying the current skylight value with a wave that is more or less positive at day, negative at night. The crux is that the current skylight level of an encased sensor can drop as low as -11 at night: 0 because no daylight can reach it, minus 11 because it's night. Two negatives make a positive, and so you see an output up to 9 at night. In fact, if the skylight is something between 1 and 10 (making -10 to -1 at night), the sensor will produce some output both at day and at night.

I'd say it's definitely a bug: it's called a daylight sensor after all. Not that I would mind if it's redefined to intentional quirk, but if it's kept I'd clean it up a little to make its behavior better-defined.

here's how it needs to be fixed: instead of using sv*w=#+#=+# like jonathan said it should just read the light level of the half-block above it (it is a half-block) and then give off a redstone signal based off of that value

It isn't possible to read the light-value of half-blocks. That's done by full blocks. Perhaps use the function the beacon uses to test if it is open to the sky?

I don't agree entirely with Sam. The current behavior is pretty useful for timekeeping purposes, in that the time slots corresponding to each output level are distributed fairly evenly over the day. The light level only rises and drops sharply around sunrise and sunset, respectively. I'm not sure what I could do with that, that I couldn't do nearly as well with the current behavior. Sure, if you know the actual light level you can predict mob spawns exactly. But you can already know when e.g. light level 8 is passed to within a few seconds.

To be clear, given the current behavior and the behavior of just passing on the current light level, I'm pretty ambivalent. I believe something like the current behavior is useful, but as it is now it's just too quirky.

Anon Ymus, the light sensor is a transparent block that can simply read its own light level.

I can confirm this in 13w05b, in which I tested this 5 minutes ago. It still happens in this update.

This seems to be different in 13w06a as far as I can tell, although it's very glitchy when it has a redstone lamp below it and is surrounded by blocks.

Checked in the latest version - still produces a signal in a fully enclosed cave.

I think, no need to fix this.

Today I stated about this error, it seems to me that the work of the sensor solar lights prescribed proportions of light to the darkness. More why this error happens, I can't explain.

This causes an issue for me, as I am using the daylight sensor for its unique height as a block, and on top of a hopper. When it is out of contact with sunlight, I expect no signal to be outputted. Because it does output a signal in this situation, however, it causes the hopper to be deactivated more than half the time. I really need this bug fixed. Its functionality is useful in other ways, but please, turn it into a feature which the user must knowingly activate.

I just built one on a roof of a house for automated daylight/night lights and when I put a solid block above it so it is in complete darkness it starts blinking with 1.5 pre-release.

Yes, I've had this problem too. I was looking quite forward to making an automated wheat farm by manipulating the sunlight detectors ability's yet it seems it has a slight glitch.

MOD PLEASE UPDATE STILL AN ISSUE IN 1.6.2

Just retested in the world that I originally found this bug on and it is still present, personally I've used this several times in builds since finding it and it being unresolved for more than 2 months and I now don't view it as a bug, I just see it as one of those redstone quirks that end up making something more functional and gives more uses than was originally intended without tipping the balance in difficulty or gameplay.

To any mods viewing this would we be able to get a verdict on if this is something that's on the to do list for the devs to fix even if it's way down there at the bottom of the pile or if it's something that's going to be left as an unintended but pleasant quirk?

This is UNDOUBTABLY a bug. When you place redstone lamps DIRECTLY adjacent to daylight sensors, the lamp will ALWAYS even after the daylight sensor is encased. This is in no way a PLEASANT quirk. This is a BUG and needs to be fixed ASAP.

I have tried testing from what you have said and it doesn't seem like it's entirely the same issue as stated in this ticket I believe your problem is something with similar symptoms but is more centralized around having the lamps on the same Y co-ord level as the sensor and the sensors programming for detecting light levels. I'm getting a blinking effect on the lamps whilst they're on the same level as the sensor is that what you've been getting?

EDIT: I guess a moderator thought that the first paragraph I had originally put wasn't diplomatic enough so I'll straight out ask, Dustin Held if you're reading this what was meant to come after "ALWAYS" in your comment so I can try testing to get a screenshot of the behavior you've been getting and so the dev team has a fuller picture of the bugs to come up with a solution to the problem if posisble?

I only missed two words in my post. It wasn't I grammar mistake, it was typo. I meant to say the redstone lamp stays powered. It stays powered despite the lack of sunlight reaching the encased daylight sensor. It's that simple. I have not experienced blinking. This quirk needs to be tested with other redstone devices as well.

I have investigated this some more. There are actually two separate bugs being discussed.

One is the odd function used by the daylight sensor, which flares up at night if the sensor has limited access to skylight. This is what I'd had in mind all along. It is not very problematic—even useful—but still wrong.

Another is that blocklight and skylight can sustain each other somehow. In this case the redstone lamp essentially becomes a skylight emitter, keeping the daylight sensor activated. Even though the lamp an opaque block, skylight will enter it when it's turned on. When access to true skylight is removed, it may be that the part of the lighting system that removes skylight skips the inside of the light because it assumes (rightfully) that nothing should be there. This hypothesis is supported by the fact that it doesn't happen with a normal torch, which is transparent. Still relatively benign because the other kind of light will drown it out, but it becomes obvious when blocklight sustains the skylight of a daylight sensor.

This second bug should be reported separately, if it hasn't been already. I'll investigate it some more first, if I can be bothered.

Might be an intended feature, however, breaks the sensors' primary function, as an enclosed sensor will power at night when it should not, making it impossible to make exposed-room (during the day) traps/devices, as they will erroneously activate at night.

If this is intended, I can't help but feel there is a smarter way of making a "moonlight detector" than changing the behavior when there is no sky light. Such as stacking 2 daylight detectors creating a "24-hour clock" (well, powered day and night) that powered both during day and night, which then someone could use a regular daylight sensor to subtract from the double-tall signal to create a night-only sensor. Both the Daylight and 24-hour clock would require skylight to function.

Would probably be best if the daylight sensor were basically turned into a slab. Then a double-tall daylight sensor slab would be the thing I talked about the previous paragraph. I'm sure builders would like it to be able to blend in with slabs and also be placed flush with floors, too.

In my opinion if they had wanted to make the daylight sensor work like a clock then whey didn't they just remove clocks. Seems like the current function (bug) would be better acheived by having an actual clock in an item frame emit a signal depending on the time on the clock and would make more sense then repurposing the daylight sensor to not truely read daylight.

Fixed by adding an inverted state for daylight sensors

Daylight detectors in darkness (no access to skylight) still appear buggy. When not inverted, they produce power for a few minutes as the moon is coming up. When inverted, they produce power almost always, except when the sun is coming up. When exposed to the sky, they appear to behave correctly in either state.

Yes, not fixed. The daylight detector can still receive power when there is no skylight, which should never happen.

In 14w32c, while fully enclosed, with no light reaching the sensor, it starts producing a signal at 14341 ticks, peak at strength 9 at 17762 ticks, and drops back down to 0 at 21659 ticks. So yes, still not quite working.

I can confirm that this issue still exists in the official 1.8 release. As Torabi said between 14341 ticks and 21659 ticks the sensor still outputs a signal when it does not have access to the sky.

Confirmed for 1.8.1 pre-release 3. This issue was not solved by the addition of the inverted daylight sensor (although I do like the inverted version very much). In fact, the inverted daylight sensor suffers from the exact same issue.

The only difference is that the inverted daylight sensor signal drops from strength 15 to 6 instead of increasing as the daylight sensor does.

As described above, the issue is seen between 14241 and 21659 ticks when the sensors don't have access to the sky.

Still in 1.8.7

why was this fixed? By now this behaviour is documented on the wiki, can be used to determine the time in caves and I've used this behaviour in a redstone contraption.

This is still marked as a bug, regardless of what the wiki says the behaviour was not intentional and the wiki should be changed accordingly.

yeah, whatever. It still works in 15w46 and I hope it stays this way. This beviour does no harm and after a few years this could be seen as a feature of the daylight sensor.

This bug should be reopened as it is still present in 15w46a. To recreate dig a room out underground that is completely closed off from above. Place a lamp beside the daylight sensor. Set the time to anything between 14241 and 21659 and you'll see the lamp comes on.

Patrick, it's still based on a bug even if it's useful. It's a day*light* sensor, if there's no daylight (or 'moonlight') and it behaves rather erratically, it's clear it's not an intended feature.

Plus, does this bug even do anything now that cannot be achieved with proper skylight, daylight+inverted daylight sensors, and redstone logic? See Jeb's comment on July 30th 2014, inverted sensors were added to replace this bug. Use one of them either with a skylight, or above ground with redstone (or even piston activation) going down to your contraption.

Because honestly, if you just don't want your stuff to be reworked, that's not a reason to keep this. Daylight sensors working properly underground brings unique contraptions. Secret doors that open or close (or traps being set off!) when a room is broken into or sealed off. Jungle temples could explode if you try to bypass the puzzle (I was able to make a simple design to do this... but unfortunately it went off because the pistons moved too slowly to cover a daylight sensor before light got to it). Mapmakers could use it as a proximity sensor especially if the user can break a certain kind of block (or use TNT) to get to secrets/easter eggs. Anything close to that is currently impossible due to the false positives.

I'm sure above-ground sensors and redstone logic can replace the current buggy underground function. It seems like it currently just detects sunrise/sunset, regular gaining signal it should not have and inverted being even worse with being on almost all of the time and then dipping to 0 on sunrise/sunset. With above-ground sensors you could replicate that (or have only one if you wanted) by circuits that activate something else for a short time after they deactivate. (pistons would probably be a good way to achieve this).

Sorry, I hadn't pushed to master for this week's snapshot

One reason this is contentious is that daylight sensors aren't a simple on/off thing. They provide multiple gradations, so you can't only tell that there's light at all but also that it's roughly midday or whatever. The same goes for encased sensors at night. To replace this functionality you'd have to build an actual clock, and one that synchronizes with a daylight sensor at that to compensate for the chunk being unloaded. But the game doesn't owe this frankly crazy behavior to you. It also breaks some use cases like coverage detection as @unknown indicated.

I'm the one who originally documented the power levels on the wiki with any kind of precision, BTW. The wiki is just informal documentation by players, of variable quality. Definitely not a specification. I was also the one that calculated the exact distribution of the old broken dispensers (although I rounded them because they were fractions like 4569647174543/19203609600000, assuming a perfect RNG), before the distribution was made uniform across stacks. The distribution was heavily skewed towards the first items, rarely dispensing the last ones. Should they also have kept that just because it was documented?