WirelessFluidDetectorCover always manipulates blocks redstone output to true

[Sanduhr32]

Your GTNH Discord Username

san32

Your Pack Version

2.6.1

Your Server

private server

Java Version

Java 17

Type of Server

Don't know

Your Expectation

I tried if the wireless fluid detector cover also manipulates the block it's placed on redstone output like the non-wireless version. I expected it to output a redstone signal matching the threshold ruling.

The Reality

the cover manipulates any block it's placed on to output a redstone signal, regardless of threshold.

Your Proposal

wireless covers in addition to the wireless signal transmission also should correctly manipulate the blocks redstone output to be the same as the signal thats transmitted, like their non-wireless variants.

Final Checklist

• I have searched this issue tracker and there is nothing similar already. Posting on a closed issue saying the bug still exists will prompt us to investigate and reopen it once we confirm your report.
• I can reproduce this problem consistently by follow the exact steps I described above, or this does not need reproducing, e.g. recipe loophole.
• I have asked other people and they confirm they also have this problem by follow the exact steps I described above, or this does not need reproducing, e.g. recipe loophole.

[Sanduhr32]

if desired, i can also try to patch it to not take up the teams time.

[serenibyss]

@Sanduhr32 That would be appreciated, thanks!

[Sanduhr32]

i'll try my best to fix the bug then, that the first init of the cover on a face causes a constant redstone signal.
subsequent cover installs (and presumably inits) do not cause a constant signal.

should the cover also intentionally manipulate the faces redstone output to match the wireless signal?

[Sanduhr32]

I believe i could trace it to here: https://github.com/GTNewHorizons/GT5-Unofficial/blob/5bbee72c52ca26597c14266642aa368b0fe964c6/src/main/java/gregtech/api/metatileentity/CoverableTileEntity.java#L506

Whenever a wireless detector cover is installed with manipulatesSidedRedstoneOutputImpl() returning true, causes the block/side to pick redstone output from mSidedRedstone[side.ordinal()] being initially 15.

I believe thats the bug, redstone output being set to 15.

Any other cover emitting redstone seems to update the redstone value by it's logic being run fast enough.
Which i test in this commit for wireless detector covers

When a cover is removed this code is ran
https://github.com/GTNewHorizons/GT5-Unofficial/blob/5bbee72c52ca26597c14266642aa368b0fe964c6/src/main/java/gregtech/api/metatileentity/CoverableTileEntity.java#L419
setting the sides redstone to 0 (a sane default imo).

[Sanduhr32]

My mentioned commit in my previous comment seems to it for wireless detector covers.

However i am hesitant to PR, as i'ld like to know whether the "simple & stupid" patch shall be chosen or the default redstone output shall be adjusted to a sane 0 default for each side of coverable tiles.

[Sanduhr32]

Example images use the discord media proxy, as githubs is currently not working for me :/
Example 01:

Example 02:

[Sanduhr32]

I am closing this, as the PR got merged. Thanks everyone involved :)