Three years old and still sitting here hmm. :P

Just create a "property" node, of any type (except maybe texture asset), and right click it, and click "set global". Then in your code node, in the actual text of the code that is, you can set its value to whatever you like. Just be careful, GPU's are multi threaded, so make sure you do not "use" that global node anywhere where it might get "used" prior to it's value being "set" by your code node. In other words, it needs to be used only DOWN STREAM from the same branch that the code node is on, to guarantee it doesn't get used until after the code node is finished setting its value.

PS: your "code" node has to be created AFTER you create the global property nodes, so that they will be "above" the code node in the shader file, otherwise you'll see errors. You can simply duplicate your code node (ctrl+D) after you make the global nodes.

In the last week I've seen two examples of nodes of mine that simply refused to work correctly until I deleted them, and recreated them. I do believe this bug has to do with SF not recalculating its internal data fully. Deleting a node and recreating it seems to be the only solution in such cases.

Here's example:

1) Create two texture assets

2) Give them different names

3) Make one global

4) Link them up so that they are affecting the main node (doesn't matter how).

5) Change the global one to have the same name as the local one.

6) Set the local one to also be global (now they are both global, and both have same name)

7) Observe that during all this, no errors have occurred, even though two nodes with same name

8) Change the earlier local one back to local again.

9) Change the local one back to its old name.

10) Observe that the global one no longer functions, it only passes the default color of grey, and it won't pass its color anymore. You can mess with it all you want, re-link it even, and nothing.

11) Delete the global node, recreate it with the same name, and observe that it's working now again.

This bug also occurs when recompiling occurs on the scripts in your game, if such recompilation occurs while the game is in play mode (without leaving / re-entering play mode). So in other words, if you leave the game in play mode, modify a .cs file somewhere, and while still in play mode it recompiles the game, SF will crash with this same error... and yes it does look like it happens on the second recompilation. @Christopher Hatton, I wouldn't hold your breath.

I have noticed (and you can see it in the screenshots above) that during the "crash", the "Blending" tab and all tabs below it are gone. So I'm guessing this glitch is somewhere in the code between the drawing of the "Geometry" button, and the drawing of the "Blending" button. But I really don't know for sure.

Just make sure you keep the shader forge window in a spot where you can see the inspector window's "open with shader forge" button. Because if you can get to that button, it'll get your shader forge window back operational again (it'll cure this error). But if you happen to not be able to get to that oh-so-wonderful button because the shader forge window is covering it up, you have to click the Window->Layout->Default to reset Unity to default window layout, which shuts down shader forge (and cures this error)... or you can restart Unity.

EDIT: I see it already does the "i.screenPos.y *= _ProjectionParams.x;" thing on SceneUVs. I could be mistaken but, I'm guessing the latest version of unity is now doing that itself, so this flipping on the Y axis is no longer needed by shader forge?

Either way this is affecting all my custom shaders, which is quite a few. I can fix all my shaders by un-flipping all their Y's, but I'd really appreciate a response from the dev on this one before I do all of that. Because if you're going to fix this in SF, then I'll just wait for this fix... thanks!

I don't know if issues can also come up with the vector "transform" node, but I assume it also won't work as expected when trying to transform a vector from world to local space or vise versa, if the object is batched?

If so, it could use a warning on the website as well. :)

PS. For the backstory... I spent days on an atlas shader, and was using both these nodes, before I realized these nodes weren't going to work. I can work around it but it's gonna be a lot of rethinking and rewriting. I read the website's description of every node, and a warning like this on these nodes would have saved me.

This issue still comes up in some cases:

1) Delete key while typing variable names in the CODE node, deletes the code node.

2) Delete key while typing variable name into a Utility->SET node, deletes any node you had selected prior to putting your cursor into the SET node.

Oops, sorry, I forgot to mention: select alpha channel on the component mask before you delete the vector3 node. That'll help ensure you get the pink (generating an error) part of my bug report. :)

It's still appearing from time to time, now two days later. I still haven't determined why it appears. However, I can say, it seems to appear each time slightly below and to the right of its previous location. So.. ha ha... it's inching its way further toward the right corner of my graph area. I do fear eventually it shall fall off into the abyss, and I shall not be able to scroll far enough to find them anymore to delete them anymore. That will be a very sad day indeed.

If you want the shader code, I'd be happy to private message it to you or something.