This has now been fixed in 1.26, which is now also released :)

This has now been fixed in 1.26

In which case they should rather be called something like custom functions/operators. Might be possible to do this, but it seems to have quite a slim use-case coverage.

I think the problem with allowing users to create their own nodes the same way that I do, is simply that it still doesn't cover the very common use-case of nested nodes, where you want to have a set of visuals/behaviours shared between shaders. Sure, it allows you to make custom operators, but, most of those should already be provided by SF, no?

Oh, they would always support multiple inputs, just not multiple outputs :)

The tricky part about nested nodes is that I have to add check to ensure not nesting itself, into itself, and that I have to recursively traverse and unfold all the nodes when compiling, which may be heavy. Not saying it's impossible, just not sure how important it is.

The problem with generating an include file is that nested nodes shouldn't simply be operators. I mean, I could limit it that way, in which case it would work, but what if you want to use the normal direction node in a nested node? In that case, you need all the other things a shader needs in order to read that data.

Now that SF2 has been somewhat cancelled, I may look into it for SF1.

It would however be limited in the following ways:

• Nested nodes would only have a single output
• Nested nodes would not be able to contain any properties
• Nested nodes would probably not support nested nodes in themselves
• If you changed a nested node group, you would likely have to re-open all the shaders using them to force a recompile.

Are these limitations too limiting, in a way that defeats the purpose of having nested nodes, or do you think it would still be worth it? As in, what's the primary use case for you?

Duplicate of: http://shaderforge.userecho.com/topic/1049008-compile-error-occurs-in-unity-53-v125/#

This is a known issue and will be fixed

Nasty things can happen if you duplicate a shader. You have to make sure you have no shaders using the same shader name, which I presume is too late now.

But yes, writing to Z with a transparent shader is scary stuff to be doing. It means your transparent shader will discard anything that renders behind it. So, for example, if your camera is set to render blue as a background, that's what you'd see.

In the meantime, double-check to make sure that the shader you're currently editing has a 100% unique name, and that when you make changes in SF, those changes are reflected immediately, ensuring that you do in fact have that shader open.

This should probably be exposed somehow, yeah