Open wtfbbqhax opened 7 years ago
Pretty sure r_lightmap is a legacy vanilla cheat cvar so fixing a cheat cvar isn't exactly important.
... and the screenshots are from Tremulous, aren't they? This is was OpenGL 2 + r_lighmap 1 looks like (to me at least): ... seems to still work as in the past (btw, your screenshots look like SD Radiant for Wolfenstein ET + r_lighmap 2). http://magics-territory.com/et/et_info/level_designers_reference/etdocs/ Maybe Tremulous supports r_lighmap 2 and quake3 not (?).
EDIT: No wait! As mentioned in the SD Radiant tutorial I was referring to, try to set r_lighmap 2 before loading the map, then you will get the same results as in the past (and how it works in WET)!
Last I checked, In GL1 renderer it is not CVAR_CHEAT, but in GL2 it is (this mismatch highlights a different bug in cvar code which I'm ignoring).
@KuehnhammerTobias I thought gl1 renderer could switch r_lightmap 0
-> r_lightmap 2
without /vid_restart
(I'm probably wrong). Eitherway, A cvar that require restarting a subsystem is supposed to say so.
Changing r_lightmap
between 0 and 1 does not require vid_restart
. r_lightmap 2 changes the lightmap data when it is loaded and requires vid_restart
whenever it is switched to or from.
r_lightmap has no cvar flags in either of ioquake3 renderers.
The OpenGL2 renderer is behaving the same as the OpenGL1 renderer / vanilla Quake 3.
I don't think its plausible or warranted for 1 cvar to come up with a latch only for 1 value if even feasible to do that? The latched cvar system is already convoluted as it is.
OpenGL2 +
r_lightmap 2
Setting
r_lightmap 2
gives you standard lightmapr_lightmap 1
unless you do avid_restart
. There is no message indicating required video restart.Additionally, after doing
vid_restart
and turning lightmap off, you're left with the following trippy experience.Now some screenshots