Would it be possible to add a mode to LDTC that inverts it's outout so if it dosn't detect it's ctype it sparks, and if it does detect it's ctype it dosen't spark?

It would allow for smaller circuits, and easier fluid level control devices.

Why should logic be required to invert the output of the LDTC? the TSNS and PSNS does not requre logic to invert because it has a mode to do so already, and LDTC has a mode that makes it spark if it detects a pixel that is not it's ctype, DTEC being updated with a invert mode would be fine as well, but I can already guess that you are not intrested in updating an old element, and adding a new function to LDTC(the new one) is to much to ask for too. I hope my guess is wrong and I am just being pesimestic.

Seriously why do I even bother to provide feedback, let alone anyone else when obviosly their are no plans to implement them at all? It doesn't seem to matter how it is justified, explained, coded, or even it's age and development status. As long as it is beloved by devs it will be done, hell or high water. The fact that you needed to add a function to warn of missing mods tell me that their is a high demand for elements people are suggesting that it was becoming a problem that needed to be addressed, and the current approach is not going work long term because you are refusing to update currently used elements with new modes(which would not break any saves) and instead are making new ones every time you want to add anything new which only makes it harder on yourselves in both the long and short term.

Just keep the defaults the same for a given element, and just tack on a new mode at the end like you have been doing for FLIT for awhile now, and boom code mainteince time saved, and no one will notice except for those who want to try somthing new and use the wiki, or ask a question.

@MachineMan

@Cracker1000

I have egg on my face, I found the mode I had tried to set before but I guess I goofed up the settings, I thought when I read the description that it would spark if it did not detect it's ctype and that it would keep sparking even if it's ctype was their becasue a different ctype was also detected, beyond that I tried to try the mode and mixed it up several times and just asumed it was another FLIT situation, and the tutorial save and the comment wording actually confused me more then the wiki, which actually is kind of weird.

However I do maintain between FLITs documention being pretty weak, and how offten it seems to happen were the code already exists for a usefull element and yet it is stated their is no plan to add them because it is "too hard" yet they can add them as a april fools joke such as sounds, and It really paints a bad picture of how much anyone in charge cares about improving this game, which some people(like me who really enjoys games like this) and as someone who has seen multiple favorite phyics and simulation building games fall to ruin because devs made boneheaded decision, does not want the same thing to happen to powdertoy, maybe if the devs let up a bit on their pickyness and opened the door more to new enthusiastic programers and players, and a bit less "no we will not add that, unless you spend time learning to code it and then maybe will add it" or "the work has already been done, but we can't do/add what some random person did last year" and just maybe their would be less hesitaion to do more then request and complain about missing features, and seeing thier hard work, testing, and love for the game be rewarded a bit more would turn much more of the players making mods into game devs allowing more hands to do less work. I also hope that I am wrong here to and the devs are not just being stuburn, and are actually being very open and welcoming to new talent and blood into powdertoy.