Ctype sensor and tmp sensor
-
You mean by cooling them, because molten elements are already hot. That's why they're molten. Also, STOR is the best way to sort and seperate elements, but assuming that the LAVA has a solid ctype, STOR won't be able to sort it once it's cooled. A ctype sensor would also be much faster than cooling the LAVA and then checking which element into what it turns.
-
you are supposed to get creative, not beg for an element every time.
-
I mean VIBR and METL.Also we have LSNS it must be easy to code
-
I mean this is what I'd love! This is what I've been saying in my mind! I'd love things like CSNS or TMNS and etc! I'd hope to see those elements in tpt :D they would open up tons of possibilities
-
When would you ever need a system where you need to sort through vibr? just make a system where the output is always the same via critical thinking.
-
This isn't always possible, especially not when you have one input and multiple outputs, like refineries that output more than one subtance. I also suggested a feature that would detect ctype without the need for a new element: https://powdertoy.co.uk/Discussions/Thread/View.html?Thread=28044
Edited 2 times by MachineMan. Last: 30th August -
tmp sensor is a rejected element, because we don't want to expose extra details of how elements are implemented. tmp has a totally different meaning in each element, and we occasionally shuffle properties around when new features are added. So, we don't want to break a save that relied on sensing a certain property in .tmp that now means something else.
Ctype sensor isn't rejected for the same reasons. It's a much more standard property than tmp is. But, we're still unlikely to add ctype sensor because there's an overload of sensors. Might be ok if it didn't have ctype serialization/deserialization, and only worked on elements that store type in ctype.
