Issue type: 🐛 Bug

Short description:

Redstone writer with property 'Strong Power' set to 'true' does not output strong redstone signal.

Setup:

Two redstone lamps one atop the other. Redstone writer pointed into bottom lamp.
Redstone writer triggered by entity reader -> players -> nonempty list.

Expected behaviour:

On trigger, redstone writer emits strong signal and lights both lamps when property 'Strong Power' is true, or emits weak signal and lights only bottom lamp when property 'Strong Power' is false.

Actual behaviour:

On trigger, redstone writer emits weak signal and lights bottom lamp only, regardless of 'Strong Power' property.

Steps to reproduce the problem:

1. Battery, variable store, entity reader, redstone writer, lamps - place in world.
2. Variable card into 'players' on entity reader, then use that card with the nonempty operator to get a boolean card.
3. Players list variable into variable store, nonempty boolean card into redstone writer boolean slot.
4. Click + on redstone writer boolean slot, set 'Strong Power' to 'true' or '1', get green checkmark.
5. Step near entity detector, observe only one lamp light (wrong behavior).
6. Click + on redstone writer boolean slot, set 'Strong Power' to 'false' or '0', get green checkmark.
7. Step near entity detector, observe only one lamp light (as expected).

Alternate test:

Place cobblestone block on flat dirt.
To the north, place redstone repeater (pointed into the cobblestone), redstone dust, lever.
To the east, place redstone dust, redstone dust, lever.
To the south, place redstone dust.
To the west, place redstone writer (pointed into the cobblestone).

 Top View                 Legend
    L                  L     Lever
    |                | - .   Redstone Dust
    R                  R     Repeater
  W C - - L            W     Integrated Dynamics Redstone Writer
    .                  C     Cobblestone

Strongly powered test: Toggle north lever 'on', observe south redstone dust lights up. Toggle lever off.
Weakly powered test: Toggle east lever 'on', observe south redstone dust stays dark. Toggle lever off.
Redstone writer test (strong): Set redstone writer 'strong power' property to true, trigger writer. Observe south redstone dust stays dark (wrong behavior).
Redstone writer test (weak): Set redstone writer 'strong power' property to false, trigger writer. Observe south redstone dust stays dark.

Versions:

Exact versions of the following mods, not just latest.

• This mod: IntegratedDynamics-1.10.2-0.7.12
• CyclopsCore: CyclopsCore-1.9.4-0.10.9
• Minecraft: 1.10.2
• Forge: forge-1.10.2-12.18.3.2511

Running Age of Engineering modpack; haven't tested in isolated environment.

Log file:

https://gist.github.com/tofof/6931bf5b2e9220d27b29b6dfa4977cf7

Thanks for reporting this. This must be a recent regression, because I tested the redstone lamp case not too long ago.

EDIT: Ah, it's 1.10, that fix may not have made it to that version yet.

I have the same issue on 1.12.2 (IntegratedDynamics 1.12.2-0.9.6). My test was placing a redstone writer set strong=true with a block of cobble on top of it and a door on top of that. Expecting the door to open or shut as the signal is toggled, but it doesn't. Ditto for a lamp instead of a door. Putting the lamp directly on top of the writer does work.

I looked at this, and strong power is being provided when it's tested for. The actual problem is that we aren't triggering some kind of update notification, so it isn't being tested for. To see what I mean:

1. Place a redstone writer pointed at two lamps in a row
2. Set strong power to true
3. Turn it on (only the close lamp will light up)
4. Break and replace the far lamp (now it will light up too)
5. Turn the writer off (only the close lamp will extinguish)
6. Break and replace the far lamp (now it will extinguish too)

That makes sense, strong power probably broke when I disabled block updates on redstone value changes. So we'll probably have to force a block update (or some other notification?) when a strong redstone value is being updated.

Possibly. I do have another odd issue which I wasn't sure yet whether to blame on the door or ID: I have a Redstone Writer directly under (since the strong output isn't working) the centre block of a MalisisDoors hi-tech door. There are three copies of pretty much the exact same setup at different Y levels (it's an elevator door). Two of the three behave correctly -- the door opens and closes when it is supposed to. The third has the door on the opposite side of the shaft (don't recall if it's X or Z flipped) but this is not working; despite the same variable setup and despite the GUI in the Redstone Writer updating to True or False correctly as expected, the door never actually opens or closes. Except on a couple of occasions it has seemingly worked after a delay; I suspect that was actually a nearby block update.

I could probably make some screenshots or video if that would help.

Yeah, ok. The one that is not working is at X 109 Y 57 Z -64. With it set to strong and with two lamps on top of it, they're both off even when the Writer says true, but when I place blocks next to them they will both light up. Similarly when the Writer turns off they will stay on until they get a block update.

The ones that are sort-of working are at X 109 (Y 98, 130) Z -60. With two lamps on these, the bottom lamp updates immediately when the signal changes, while the top lamp stays stuck until a block is placed next to it.

I don't know what that means, but hopefully it helps.

I wonder if this is related to #356.

FYI in 0.10.1 things are improved (if the lamps update at all, then they both update, not just one of them). But the issue with the lamp at Y 57 remains -- it just doesn't get a block update at all. (Or at least if it does, it happens when the writer isn't on yet.)

Given that the two working ones are facing the opposite Z direction from the one that doesn't work, I wonder if maybe it's something about the order that things are processed? (eg. maybe in the working ones, it block updates the reader first and the writer second, so the writer sees the reader being true and it behaves -- while in the other case, the writer updates first and then the reader, and since the reader's signal isn't on yet, neither is the writer's and the lamps don't turn on.

The writer does eventually internally recognise the update because if you look at its GUI it correctly reports "true", but the lamps aren't on. Best guess, something thinks it has already updated so doesn't update it again even when the output redstone state changes.

These are just guesses though; I recall something similar being an issue for other mods many MC versions ago.

@uecasm Can you share a screenshot of your setup?

At the back is an elevator block with a reader and writer attached to it. The reader on the back has Redstone High linked to the writer under the lamps. The reader in the foreground (which normally has a pressure plate on it, which I've removed for this image) is linked to the writer on the elevator block.

In this shot the lamps should be off, since the elevator is at another floor. And the GUI of the writer under the lamps confirms that the signal is false. If I place blocks next to them then they will turn off as expected.

Curiously, the exact same setup (but mirrored in the Z direction) works on the next two floors above this. More curiously, when I tried re-creating this same setup (with the same orientation, though slightly different cable placement) in another chunk, it also worked as expected; so I guess my theory above isn't entirely correct, or at least there's some other trigger.

Don't know if relevant, but this is right at the edge of the chunk (the lamps and elevator are in one chunk, the foreground reader is in a different chunk). Though I tried breaking the cable linking the foreground reader to the other stuff in case chunk spanning was the culprit and it made no difference. I also tried breaking and replacing all the components in the non-working location (both with their original items and newly crafted ones) and it made no difference.

Another weird behaviour that might be new is that not all sides seem to be equal for block updates. If the lamps are on and should be off, then placing a block on any side successfully turns either lamp off. But if the lamps are off and should be on, placing or breaking a block on the +X or +Z sides does nothing, while placing or breaking a block on the -X or -Z sides updates the lamp state. (+Y also works; I couldn't check -Y because the writer is there.)

It's really tricky to debug these things as I'm not able to reproduce them myself...

@uecasm Is it ok if I send you a custom ID build that prints some debug output? That should help me track down the issue. (Will only have time at the end of next week for that though)

Sure.

Updating with more information from the report started on the Discord channel. Bug report from replica of Direwolf20's Astral Sorcery Crystal Growth setup. Won't be able to update with confirmation from episode 60 world download (est. Mon/Tues) that it isn't just my build or updates that are causing weirdness. Confirmed 0.10.1 fixed the updating issue with Actually Aditions (r126) Auto-Placer on pulse mode, but issue with not updating Thermal Dynamics (2.3.10.4) Servos still exists.

Redstone Writer is using a Boolean variable on the top, static mode with strong signal set to true. Using Hardened servos though trying to confirm if flavor of servo matters. Also, in a weirder turn, found that switching the servo from high to low signal requirement updates the signal input from the writer once. So if writer value is returning true, switching the servo from high to low will update the signal input once. Toggling again after writer returns false will update the servo from the writer again.

I am using Direwolf20's 1.7.1 build for MC 1.12.2. This release included the latest release of Integrated Dynamics and related libraries. I have been trying to build his rock crystal machine that uses redstone writers to signal to servos.
Recently I completely tore out the whole system, trashed it, and rebuilt it with all new hardware. I also added blocks with redstone on them between the writers and the servos. I figured this way the writer can signal the redstone, then the redstone can signal the servo. Since the writers seem to have issues with some things and not other since the update.
The problem now is that one of my writers is now failing to signal the redstone. I tried moving it, replacing it, replacing all the cables up to it. Still not working. I have 3 other ones that are working fine (so far), but not that one.

In the pic, it's the one on the far right (I know the setup is ugly, but it did work for a couple rounds until I tried moving something) that is facing 2 blocks with redstone on them.

@uecasm Here's a dev build that adds some debug output. Would you be willing to run this and make sure that the broken writer (Y 57) changes values a few times? (make a backup of your world!)
Be sure to send me the log files after that.

https://www.dropbox.com/s/ucdjognixa1z05s/IntegratedDynamics-1.12.2-0.10.1-DEV.jar?dl=0

Dropbox

IntegratedDynamics-1.12.2-0.10.1-DEV.jar

Shared with Dropbox

I've been thinking about my setups failing the last while. It seems to me that things worked initially each time. Setting it up never brought on the issue. I'm pretty sure in each setup, I've tried moving something. That might be something that gets it to start being buggy. For instance, in the pic I posted, the failing redstone writer worked fine initially. Then I tried to make it look at least a bit nicer and moved it. I found the move conflicted as the new position of the redstone would affect machines I didn't want getting a signal, so I moved it back. Then plop, stopped working.
Not sure that helps, but it may be helpful in reproducing the error.

https://www.dropbox.com/s/h3ut3ylu9ffu29e/IntegratedDynamicsLog3.txt?dl=1

Also, I don't know if this is significant, but I'm a little puzzled by the "side: south" that keeps popping up in the logs. As you can see in the screenshot above, the writer that's toggling is facing upwards. There is one on the side of a block at that level (I'm not sure which side) but it shouldn't be doing anything since it's connected to a reader that doesn't have any block to read.

It looks like the capability that holds the redstone level has the incorrect side...
I made a small change that might fix the problem.

@uecasm Could you try your setup with this new build? If it still doesn't work, please send me the logs again. https://www.dropbox.com/s/vgwyeaalbw1gt53/IntegratedDynamics-1.12.2-0.10.2-DEV.jar?dl=0

Dropbox

IntegratedDynamics-1.12.2-0.10.2-DEV.jar

Shared with Dropbox

Yep, that fixed it.

Logs for comparison: https://www.dropbox.com/s/t04qx7jvkdziwss/IntegratedDynamicsLog4.txt?dl=1

So, I also downloaded that dev build, cause I really want my machine to work the way it was intended. The redstone lit up. I then ripped out the redstone and placed the writer right on the servo again. Worked first try. Super Awesome.
Thanks,

Ok. I tried calling the elevator to the problematic floor (which should have turned on the lamps but didn't -- note though that the OneProbe tooltip did update to show redstone 15 on the lamp when it should have turned on, so I think the redstone APIs are doing the right thing, just not giving the lamp a block update or doing it in the wrong order or something). Then sent the elevator away again, which should turn it off. Just once of each event though -- the log's long enough even with just that. 😁

I also included (at the top) two loading errors that seem possibly related to your mod, though not relevant to the current issue, in case they might be of interest.

https://www.dropbox.com/s/q49afq20434tj6g/IntegratedDynamicsLog.txt?dl=1

I thought I might do the same. Ignore the resource pack change in the beginning. I basically went up to my machine and threw in a number of gems the system would kick out, as the faulty writer only comes on when a gem is kicked from the system. A couple of writers are supposed to fire at the same time. In reality, one works and the other doesn't. I ran it a number of times the way it's supposed to work, then near the end, I pulled the variable card from the working gem, so the gem would stay and the faulty writer would stay on for an extended time.

https://www.dropbox.com/s/87a24t2uh3gw1eg/logincludingintegrateddynamicsdevdata.zip?dl=0

Dropbox

logincludingintegrateddynamicsdevdata.zip

Shared with Dropbox

@uecasm Alright, thanks, that's what I needed! Could you do the same with this dev build? It contains some more debug output: https://www.dropbox.com/s/lnn8rvdh0mm3eci/IntegratedDynamics-1.12.2-0.10.2-DEV.jar?dl=0
(Note to self: check the sided output on this one, also opposite sides)

@haddow777 Thanks! The debug output has however been tailored to @uecasm's setup, so the output will probably not contain the data I need in your case. But thanks for the effort, good to know that I can ask you to debug some things as well :-)

Dropbox

IntegratedDynamics-1.12.2-0.10.2-DEV.jar

Shared with Dropbox

Ok. New build, same test sequence:
https://www.dropbox.com/s/sldseixds5ifkys/IntegratedDynamicsLog2.txt?dl=1

Alright, we're getting there. It looks like the redstone value that is read from the world is not the same as the one that is being stored in the tile entity. I think this may have something to do with a capability not being attached...

@uecasm Can you send the log again with this build?: https://www.dropbox.com/s/4av2uz3qu9d6y6z/IntegratedDynamics-1.12.2-0.10.2-DEV.jar?dl=0

Alright, great! Thanks @uecasm and @haddow777 for your help! Will try to release a new version asap.

@uecasm Actually, cables don't even have a rotation. But something must have gone wrong internally which made them have an incorrect rotation.

Surprised that rotation was a thing. I don't think I'd used any wrenches or anything on the cable or writer. Is it affected by which side of the adjacent block is clicked to place the original cable? (Like stairs, or machine front-facing.)