Closed johalun closed 10 months ago
Thanks for this.
We have an official texture artist
Yes please :) I couldn't make it nearly as good.
@desht Do you have a nifty way to auto join a test world when starting the client with ./gradlew runClient
? Edit: I tried https://github.com/florensie/auto-load but couldn't get it to work. Maybe out of date?..
@desht Please give it a test run now. Turned out quite ok I think. Hope I didn't miss anything obvious. Just the new 3D model missing.
Regarding the recipe. I was thinking it would be fitting if we could make one ingredient be something heat related. Maybe heat pipe or a manometer or something similar. What do you think?
Yeah something including both, perhaps?
(Didn't get the chance to test the changes over the weekend, sorry - soon, hopefully!)
I'll work on a model this weekend.
I got a chance to play with this, and it works well, although I have a fairly minor point to raise.
I got a chance to play with this, and it works well, although I have a fairly minor point to raise.
* If you set the threshold to (say) 50C, the signal doesn't switch from 0 -> 15 until the temperature is 51C. Maybe that's OK, but I think it switching on at 50C would be more intuitive. * Similarly, using the advanced interface, I set the signal to interpolate between 0C and 200C. At 200C the redstone output is 14, not 15 (at 201C the signal is 15). Again, I think it would be more intuitive to have the upper limit of the temperature range correspond to the upper range of the output signal?
Yes I agree. It's an oversight on my part.
If you set the threshold to (say) 50C, the signal doesn't switch from 0 -> 15 until the temperature is 51C. Maybe that's OK, but I think it switching on at 50C would be more intuitive.
@desht Did you test with an older commit? I changed half way through from >
to >=
for the simple case. I also noticed that the creative compressed iron block lag behind in updating neighboring blocks so when you increase the temp step by step, the thermostat is always one step behind, i.e. compressed iron 49->50, thermostat reads 49, next step from 50->51, thermostat reads 50, and so on. Could that be a factor here?
Edit: same for the advanced. I'm getting 200C -> 15 redstone. But I have to make sure that the thermostat is actually reading the current temp of the compressed iron block by forcing a block update. Could this be an issue in the thermostat code or how the compressed iron block is doing neighbor block update on changes?
It's possible, I'll check again later 🙂
Model is pretty much done, just need to create the upgraded texture and work on the render.
@Ridanisaurus That looks great!
@desht Do you think we can also get this into 1.19.2? Can't wait to start using it :)
Yeah, sorry for the delay, just been too busy... should have some time next week though. I have a nice model from Rid, but it needs some manual patching to wrangle it into the code, so I will merge this into dev and patch the model in with a separate commit.
Hopefully some time shortly after the 25th :christmas_tree:
@desht Thanks for merging! When do you think we'll have release with this included for 1.19.2? Trying to coordinate with the Valhelsia team to get this in the next mod pack update.
This week, with luck... Thu/Fri perhaps?
This change adds a thermostat tube module. It measures the temperature of the block it's facing (including air), and sends a redstone signal of 15 on the selected color channel when temperature is above set threshold for the simple version. When upgraded it can be configured with lower and higher bounds with an interpolated redstone output, similar to the pressure gauge module.
Added
AbstractTubeModule:canConnectTo
function that is used byModuleNetworkManager:computeConnections
. The default implementation is to only returns objects of same class to keep the previous behavior, but tube modules can override it to be included in for example calculation of redstone signals output by redstone modules which the thermostat module does.WidgetColorSelector.isExpanded
public getter. This is used to disable the bounds sliders when the color selector is expanded in the thermostat advanced GUI.Changed
The functionModuleNetworkManager.java:computeConnections
only returned modules of the same class. This is called by the redstone module set to output when iterating over all connected modules to get the highest redstone signal. To make it work with the new class I removed this filter (it needs to also iterate over thermostat modules now). Anywhere where this function is called, the caller also filters on class type so there's no difference in functionality, expect some performance impact since we now return more objects than before that the caller has to filter through. If this is a concern we could maybe add a function parameter for the caller to supply a list of valid class types to be returned.Todo