I regularly get a bug report to the effect that r_wateralpha doesn't get saved in DirectQ. This is actually intentional and there are some very good reasons for it.
The first reason is that GLQuake doesn't save it either. Now that's a fairly weak reason, and there are occasions where I've changed this behaviour from GLQuake (and have even gone so far as to change a default from GLQuake) where I've felt that the original way was either stupid or obsolete.
The second reason is the important one.
Not every map has translucent water. In particular, if you do a fresh install of Quake from CD and use standard ID1 content, your ID1 maps won't have translucent water. Now, if DirectQ saved your value of r_wateralpha this would break on standard default ID1 content.
Here's where priorities come into play, and priority number one with no exceptions or arguments is that if a decision involves breaking on default ID1 in order to support a new(er) feature in some way, then it's not a decision. It just doesn't happen. Supporting default ID1 correctly is the single most overriding priority and nothing else comes even close.
Unfortunately r_wateralpha is one of those features - fog is another - that got added to GLQuake without much in the way of thought going into how to handle it in any kind of robust or consistent manner, and now we're stuck with the consequences. With r_wateralpha it was never meant to be a robust feature - check your your GLQuake readme - so it's kinda forgivable and understandable. (Fog is different but that's going off-topic.)
Yes, this situation sucks, but this is one of those cases where it's just not possible to be all things to all people, and a lowest common denominator that's going to work in a predictable manner needs to be chosen instead. And in cases like this the only reasonable thing is to do what ID Quake did.
So if you want your chosen value of r_wateralpha to persist, put it in your autoexec.cfg instead.
(As a postscript: the inevitable question is "how about detecting if a map has translucency or not?" and the inevitable answer is "I tried that before, it didn't work.")
Thursday, June 23, 2011
Why some things are the way they are part 1 - r_wateralpha
Subscribe to:
Post Comments (Atom)
3 comments:
Could there be someway in-game for it to tell you which variables won't be saved? Maybe a console message when a variable like that is set?
Below is a lil' script that when added to your autoexec.cfg and bound to somekey, will cycle through 3 options for water when pressing that key in-game:
1 - fully opaque
2 - translucent (for supported maps)
3 - translucent (for unsupported maps)
Note that option 3 is only required for maps that are not compiled with translucent water in mind.. meaning that to compensate for that, r_novis 1 is set, which might mean a substantial performance hit on huge maps, or old hardware ;)
-----[copy the lines below]-----
alias op "r_wateralpha 1.0"
alias tr "r_wateralpha 0.3"
alias hi "r_novis 0"
alias lo "r_novis 1"
alias fb1 "echo opaque water"
alias fb2 "echo trans water (hi fps)"
alias fb3 "echo trans water (lo fps)"
alias wa1 "alias cw wa2;hi;op;fb1"
alias wa2 "alias cw wa3;hi;tr;fb2"
alias wa3 "alias cw wa1;lo;tr;fb3"
alias cw wa1 //initial setting
bind "somekey" "cw"
"Could there be someway in-game for it to tell you which variables won't be saved? Maybe a console message when a variable like that is set?"
That's a great idea; I'll do that.
I've just implemented "seta" from Q3A by the way, but right now it has stability issues with the video mode cvars during startup so it's going to need further work before I'd consider making it the default behaviour for the cfg file saving.
Post a Comment