Ваші коментарі

Did you completely remove 0.35 before installing 0.36?
Since this is now possible using the code node, I'm closing this :)
Is this still a problem, even after having reinstalled SF?
Hm, yeah. It sort of doesn't make sense to use directional lightmaps when you have no specularity connected, in which case it would be just like using single lightmaps, but with twice as much texture memory being used.

That being said, the shader shouldn't even compile in a directional lightmap pass when no specularity is present. Right now, it's simply because of the pretty naive dependency system I currently have implemented, which I'll have to rewrite instead of patching this up with more duct-tape :)
Did you completely remove the old Shader Forge installation before installing the new one?
Does it always happen or just with a specific shader?
It's something that would be nice to have, and may happen at some point. Anyhow, this is a duplicate of: http://shaderforge.userecho.com/topic/383480-compi...
Looks like light attenuation is the problem - it seems to output 1, even when there is no directional light at all, which is a bit of a problem. You can solve this by using the A channel of the light position node, which is 1 when point lights are currently being rendered, and 0 while a directional light is rendered:

Alright, so, here's how forward rendering works:

First, it renders a base pass, with all the things that are only supposed to be added once, and it also renders one directional light source.
Secondly, *for each light source affecting this object*, it runs a forward add pass, which is rendered *additively* to the mesh.

I would guess you have a directional light pushing pure white into the second example, and the rest of the light sources don't affect it, because it's overshooting 1 in value
It's hard to do that, because light attenuation is still per-light source. Keep in mind that light attenuation only makes thing darker, and that you're currently only reading the alpha channel of the light color