I checked it now, everything works fine, this is very cool, thanks for your time!
You're welcome.
I always create a Checker map for testing (and you use bitmaps for it) and with the checker the script does not respond to pressing the button for transluency, but then I created a regular Сoronabitmap and everything worked as it should. Very interesting what the hypothetical reason could be :D
Its designed for CoronaBitmap/Bitmap, CoronaPhysical/CoronaLegacy/Multi-Sub/Corona-Layered (so far). Its easier to add inclusions later on than the opposite, this way you dont get unintended things happening along the way - basically 'it does what its designed to do'. Then bug fixes, then add more stuff :)
All the other nodes like falloff/mix etc are just bypass nodes, so not input nodes - if you were wondering why they work.
Its Translucency button(s) are designed to look up the chain, find the bitmap, go down the chain plug it in basically. It works a lot differently to say the Diffuse - Color Correct button since it has so many variables to keep track of its easier for me to build it this way. Maybe one day ill look back and think this was a trash idea but if it works it works lol.
Edit:
Technical Explanation Rant Incoming:TLDR:
If you are interested, a more technical understanding of how the Translucency button works is that it checks that the bitmap for the diffuse is the same as the one for the translucency. This is how one button can do 4 different things (case scenarios). If the diffuse bitmap is different to the translucency bitmap then do this, if its in a color correct and is the same bitmap then do that, if its a different bitmap then do another thing, etc. The Diffuse - Color Correct button doesn't care about what's before the diffuse input on the material, it just puts that last.
The rant:
The way the Corona nodes with additional mapping works is just crazy, blew my mind for a whole week. The strange thing is that when you add an "Additional outputs" in the Corona nodes it actually switches the order of things (which is why you do this before otherwise you lose your original output connection right?). It would be much easier if Input/Default Output = Input 1, Output 1. But they are not, they are something else. So what happens when you add a new output is everything gets reordered and new things are created (so Input 1 & Additional Output 1 = Input 1, Output 1. Then your original output is removed and replaced with a new output and the whole Color Correct node changes). What compounds this even further is that what you think is your Output 1 -> Diffuse is not actually a direct connection. It now goes through another
invisible new node called "MultiOutputChannelTexmapToTexmap". This is a separate node just like Color Correct and makes things very difficult to keep track of... well at first anyway. I kind of get how it works now but it really threw a spanner in the works for awhile there since not only do you have to work out how to re-wire everything, you are also about 3 loops down and have to do it all backwards... I don't know if that makes any sense to you but yeah, it was a pretty difficult concept to wrap my head around but I think I got a solution that seems easy to follow from here on. (for any maxscripters in the future reading this, dont do it backwards - there is an easier way, just read the code its available for free here or in my
github).
I would say its due to the fact that Corona had the ColorCorrect node before they had multiple input/outputs, so re-ordering could have been a major pain and this was the next best idea... seems plausible. Since every other Corona node that uses multiple in/outputs also do this. I'm far from an advanced programmer so I would say someone smart probably created this idea and knew what they were doing so don't take my word for it. Also another pain in the neck is Bitmap works different to CoronaBitmap, so does Physical/Legacy. Not only do you need to work out all the stuff I just said, you then have multiple scenarios where you need to consider different bitmap or material types and incorporate all that into your script(s) or things get left behind.
Hence why in my opinion its better to add stuff once its stable than to remove things later since that means your code will need a lot of re-work. Funnily enough if a button doesn't do something that's usually a sign that your error handling is working correctly lol. The worst case scenario is someone pushes a button and the maxscript listener pops up with an error, breaks the UI and halts the script at that point. From an artists perspective both sound terrible, but the former is actually much better lol. The best solution is really that you inform your user with a popup of the error type, cancel the operation and then the coder/programmer knows where to look in the code since they created that error message in the first place (or continue the operation without that functionality). I was considering this when I made the Translucency button, but I put it as step 5. in the instructions instead since, well that's so much easier lol. Never thought of a checkermap situation but that's not high on my priority list at this stage as long as its works for your vegetation :D
