Place a lamp and next to it place a T-FlipFlop gate. Toggle the input and notice the lamp does not turn on. Example:

Note however that if you place a piece of wire between the gate and the lamp it does turn on as expected.

Gates don't output directly like that, which is not a bug but its not the way I want it. It will be fixed.

On Jul 9, 2013, at 10:18 PM, Josh Kropf [email protected] wrote:

Place a lamp and next to it place a T-FlipFlop gate. Toggle the input and notice the lamp does not turn on. Example:

Note however that if you place a piece of wire between the gate and the lamp it does turn on as expected.

—
Reply to this email directly or view it on GitHub.

Cool.

Another observation... if you take for example a NOT gate and put it against a lamp, the lamp does turn on. And if you go back to official RP and use a toggle latch touching a lamp it will again turn on.

To be honest I'm just thrilled there is an OSS alternative to RP logic (big shout out to @immibis for his work on RedLogic) so this isn't so much a "bug report" as a "hey maybe this should be consistent" comment or whatever.

Okay, well then it's a bug. If cant figure it out let's hope immibis can. Will be looked into.

On Jul 9, 2013, at 10:36 PM, Josh Kropf [email protected] wrote:

Cool.

Another observation... if you take for example a NOT gate and put it against a lamp, the lamp does turn on. And if you go back to official RP and use a toggle latch touching a lamp it will again turn on.

To be honest I'm just thrilled there is an OSS alternative to RP logic (big shout out to @immibis for his work on RedLogic) so this isn't so much a "bug report" as a "hey maybe this should be consistent" comment or whatever.

—
Reply to this email directly or view it on GitHub.

I believe this was immibis's intent, based on comments in his logic thread, and the code itself. His logic blocks do not, as a rule, connect to blocks. They only connect to wires.

I can't reproduce your not gate scenario. Am I doing it wrongly?

I just had a look at the code, indeed, they are working as intended. It may change, like I said.

Works with my lamps:

There is definitely something odd going on here. If I connect a wire to any side of the lamp, it turns on:

Also, vanilla redstone lamps work similar to Immibis' and OFF lights act as a connection for them, which may or may not be intended:

Hmmm. Maybe they are not causing a block update? Instead of putting wire on the other side, try a stone or something, and see if it turns on.

On Jul 11, 2013, at 8:50 AM, Greg Lincoln [email protected] wrote:

There is definitely something odd going on here. If I connect a wire to any side of the lamp, it turns on:

Also, vanilla redstone lamps work similar to Immibis' and OFF lights act as a connection for them, which may or may not be intended:

—
Reply to this email directly or view it on GitHub.

Nope, that's not it. Based on some experimentation and inexperienced poking at the code, I'm starting to think it is some kind of client/server desync issue.

It works like this (I think):

1. Client side OnBlockUpdate causes updateState to fire client side, which toggles powered to true, as isBlockIndirectlyGettingPowered returns true.
2. markBlockForUpdate causes a lampupdatepacket to go out, which causes updateState to fire server side, and this sets powered to false, as server-side isBlockIndirectlyGettingPowered returns false.

Adding the wire causes isBlockIndirectlyGettingPowered to return true server-side, and so it lights up. I'm not really sure why this happens, though.

Are you implementing IRedstoneUpdatable on your lamps?

On Jul 11, 2013, at 7:54 AM, immibis [email protected] wrote:

Works with my lamps:

—
Reply to this email directly or view it on GitHub.

Yes, but onRedstoneInputChanged isn't firing in this case.

I was able to fix it by including the powered state in the packet, and ignoring isBlockIndirectlyGettingPowered in server-side state updates, but I'm not sure that is the correct solution.

It does appear to WORK, though. :)

I will clean this up and check it into my fork and you can see what you think.

I might have an idea, but for now, try it with the lanterns. I wrote those a little differently, and if they work like they should, I will just wright the lamps the same way.

If they still don't work, maybe it's not working because the lamp asks if its getting indirectly powered?

On Jul 11, 2013, at 11:07 AM, Greg Lincoln [email protected] wrote:

I was able to fix it by including the powered state in the packet, and ignoring isBlockIndirectlyGettingPowered in server-side state updates, but I'm not sure that is the correct solution.

It does appear to WORK, though. :)

I will clean this up and check it into my fork and you can see what you think.

—
Reply to this email directly or view it on GitHub.

Okay guys, see what you think of that pull request, please. There were actually two things at play here:

1. The issue I mentioned above where the server was stomping on the lamp state because it's indirectpowered state was being checked incorrectly.
2. An issue where the client didn't properly sync the Tile Entity back to the server in OnBlockAdded().

Lanterns don't work either.

Hmm. Try messing with the update state method. That may be why. Or, since immibis says his lamps work fine, try looking at his source to see if I missed something. I'm other than that, it HAS to be the update state method, or the gates themselves.

On Jul 11, 2013, at 11:33 AM, Greg Lincoln [email protected] wrote:

Lanterns don't work either.

—
Reply to this email directly or view it on GitHub.

@immibis did your gates change recently to fix this issue, or was this never an issue for you?

I did try to find Immibis' source to look at, but I can't seem to find it anywhere. It isn't on github... I fail at Google apparently.

It's included in his releases.

fixed via #9.