Previously, it would edit the odd numbered stateset, then regenerate
shaders for the even-numbered one, then edit the even numbered one, and
regenerate shaders for the odd numbered one (or vice versa if it
finished during an even numbered frame). This would leave one of the
shader programs still trying to use the state that had been removed.
As we don't reconfigure all shaders without shadows when we disable them
indoors (as it'd probably add a hitch to transitioning in and out) we
need to set up dummy state so the shaders don't do anything illegal.
This hadn't had symptoms for most objects as when indoors, nearly
everything would be drawn first in one of the water RTTs, which had
dummy state to disable shadows already. This wasn't true of the water
plane itself, though, yet somehow it took until just now for anyone to
report that.
This resolves vtastek's issue where the water would be invisible indoors
This should fix the issue where Windows Release builds (compiled as
/SUBSYSTEM:WINDOWS instead of /SUBSYSTEM:CONSOLE) can't have their
output redirected.
Basically, a console application creates a console if not given one, so
you get a console window behind OpenMW while it's running. It was
decided that this was ugly, so we set Release builds to be windows
applications, which don't get an automatic console and don't
automatically connect to a console if given one anyway.
Of course, we still wanted to actually be able to print to a console if
given one, so we manually attach to the parent process' console if it
exists, then reopen the standard streams connected to CON, the Windows
pseudo-file representing the current console.
This is a little like connecting a second wire into a dumb terminal in
that you're pumping characters into the display rather than onto a
pipeline, so output can't be redirected.
It turns out, though, that if a /SUBSYSTEM:WINDOWS application has its
standard streams redirected by the calling process, it still gets its
handles as normal, so everything starts off connected just how we want
it and we were clobbering this good setup with the straight-to-console
fix.
All we need to do to fix that is check if we've got valid standard
handles and that they go somewhere useful, and if so, avoid reopening
them once the console is attached. Simples.
This resolves a regression where the local openmw.cfg doesn't exist, so
we fall back to the global openmw.cfg, but because we've not loaded
anything from the local openmw.cfg, there are no variables with which to
merge.
