Suggestion: Allow UV Lightbox Threshold to be Redstone-Controlled
HipHopHuman opened this issue · 12 comments
Right now it only allows manual adjustment. Which is fine if you have just the one. But if you have 25 and want to change the threshold on all of them, it's unnecessarily tedious because you have to do it one lightbox at a time.
It would be neat if the threshold was redstone controlled, then I could use a comparator signal to control the threshold of 25 UV Lightboxes all at once and keep them in sync.
I'm just not sure what the best way to go about this is, as the UV Lightbox already accepts redstone power, which enables/disables it.
Maybe adding a new Redstone mode called "Interpolate" which changes the redstone behavior such that a signal strength of 0 is off and 15 is 100% but everything inbetween is interpolated?
I thought you might. :) The question then is what kind of interpolation. It would be convenient to be able to rest on specific values, like 50%, 70%, 80%, 90% and 100%. Something tells me a linear interpolation wouldn't be able to accomplish that. Or should the player have complete control, as with the UI offered by the advanced PCB in some tube modules? Hmm
TBH, I'd just interpolate as 0 is disabled, 15 is 100%, and 1-14 are just values between.
Okay, but I can't help but pre-empt that would be slightly inconvenient due to the way the UV Lightbox behaves, as the scale of the processing in the machine is not so linear. For e.g. the jump in speed from 79% to 80% is a lot bigger than the jump in speed from 49% to 50%, if you take a quick look at adjusting the threshold in game while a PCB is being processed, you'll see what I mean.
I took the liberty of deriving a simple reverse linear interpolation function that might help demonstrate what I'm talking about. Using the formula (v - 0) / (15 - 0) where v is the input signal strength, and then rounding to 2 decimal places, we end up with the following threshold values:
| Signal | Threshold (2 decimals place) |
|---|---|
| 0 | 0.00 |
| 1 | 0.07 |
| 2 | 0.13 |
| 3 | 0.20 |
| 4 | 0.27 |
| 5 | 0.33 |
| 6 | 0.40 |
| 7 | 0.47 |
| 8 | 0.53 |
| 9 | 0.60 |
| 10 | 0.67 |
| 11 | 0.73 |
| 12 | 0.80 |
| 13 | 0.87 |
| 14 | 0.93 |
| 15 | 1.00 |
Now, this might be fine but I think getting the player closer to increments of 10 would be more convenient for them. One simple way to do that is to round to 1 decimal place instead, but that creates a few duplicate thresholds:
| Signal | Threshold (1 decimals place) |
|---|---|
| 0 | 0.0 |
| 1 | 0.1 |
| 2 | 0.1 |
| 3 | 0.2 |
| 4 | 0.3 |
| 5 | 0.3 |
| 6 | 0.4 |
| 7 | 0.5 |
| 8 | 0.5 |
| 9 | 0.6 |
| 10 | 0.7 |
| 11 | 0.7 |
| 12 | 0.8 |
| 13 | 0.9 |
| 14 | 0.9 |
| 15 | 1.0 |
Build 255 includes interpolated thresholds using the clamp-to-10% method - give it a go and see what you think...
Tested it out and all seems to be working wonderfully, though I would caution players not to experiment with setting 25 UV lightboxes to 1% in a badly lit room 😂
Actually (and I probably need to clarify that part in the GUI) the lightbox currently won't run at a 1% threshold (0 redstone signal disables the lightbox). The minimum is 1% since that's the minimum set on the slider control.
Also, there's already code in the lightbox TE to prevent overly-rapid blockstate switching... the light won't toggle on/off more frequently than every 10 ticks. Although a roomful of toggling lightboxes could still be fairly bad for performance... :)
Oh, it definitely ran at 1% (signal strength 1). Used logistics frames to input empty PCBs via requesters configured to strict match NBT for 0%, and the whole system went really confused, spitting out and absorbing the PCBs repeatedly. 😂
I'll check into that. Another thought: what if the hard minimum was 25% (for 0 signal, which should probably also disable it), and each level of redstone went up by 5%, to a max of 100% at signal 15? Effectively then your working range would be 30% to 100%.
That works. I personally can't think of any use cases where a threshold <25% is desirable.