This has been reported several times before, and it's a known issue, which is of course planned to be fixed.

http://shaderforge.userecho.com/topic/271439-panning-or-time-relatet-stuff-only-works-with-shaderforge-window-open/

http://shaderforge.userecho.com/topic/249187-shaders-using-the-time-node-doesnt-animate-in-game/

It's already reported, but yes, it's planned :)

Edit: This is now fixed in alpha 0.14

I see!

Ideally, the user shouldn't have to know about the whole Y/W thing, which is why I would prefer a DeriveNormalZ style node, which has a Vector2 input and a Vector3 normal. (Packed normals without Z goes in, unpacked normals with Z goes out)

Normal unpacking takes the Y and W channels of the texture, unpacks it to XYZ, calculating Z in the process.

A normal unpack node will most likely make things tricker for new users, as I don't think anyone would set up their nodes to generate an unpacked normal on the Green and Alpha channels. 

How about simply having a DeriveNormalZ node, as in UDK?

http://udn.epicgames.com/Three/MaterialsCompendium.html#DeriveNormalZ

The main difference being that it works on X and Y instead of Y and W

I'm a bit torn, what are your thoughts?

Got an example case where it would simplify things a lot?

The instruction counter has been broken for a long time; but it is now fixed in Alpha 0.14 :)

Not really, and it's most likely too expensive to calculate something like that in real-time in a shader, sadly. You'll have to do that offline/pre-render

The reflection node already acts that way, and there's another request already for real-time reflections, closing this :)

I'm not sure how the second shader was done! Seems quite advanced

Right - The reflection vector in UDK is the camera->normal reflection, which there is a node for in SF already :)

Have a look:

I'm a bit curious though - What exactly is the "Reflection texture" node in the center?