ZDoom

by **Graf Zahl** » Thu Nov 01, 2018 2:43 am

Added the fake CVAR to silence these mods. Making it foolproof is sadly not doable.

by **Korell** » Fri Aug 10, 2018 2:37 pm

This was mentioned on my ModDB page for my fixed version of Pirate Doom! I wasn't able to replicate the issue as my ini file was relatively old and so had the vid_renderer=1 set within it (under the GlobalSettings.Unknown section) so the mod found the expected value even though it was doing nothing for GZDoom, and so I didn't know what the issue was for the users. Thanks to this thread I've now been able to see what the issue was and replicate it, and I'm now about to upload a new version to ModDB as the check was taking place in just two maps. It was literally checking the value of vid_renderer and if it wasn't set to 1 then it was showing some messages on screen on the first map advising the user to change to OpenGL, and then on the second map it would give some more messages before killing the player - very annoying.

by **Rachael** » Fri Aug 10, 2018 8:02 am

Graf Zahl wrote: And think we have to preemptively block vid_rendermode entirely for both ACS and ZScript because it poses the same problem if some users just cannot act responsibly.

I agree with this. I just never knew how to implement it, myself, but we should consider doing a CVAR_NOSCRIPT flag for CVars that strictly deal with user preference, which makes it impossible for scripts to access it.

Things like SSAO, MSAA, FXAA, dither, etc.

by **Rachael** » Fri Aug 10, 2018 8:00 am

drfrag wrote:Then add the CVAR_NOSET flag instead of a warning (actually there would be no need for setting it manually).

I disagree here, too. A warning is a better solution.

by **Graf Zahl** » Fri Aug 10, 2018 7:59 am

Rachael wrote:
drfrag wrote:What about setting vid_renderer to 1 for vid_rendermode 4 and 0 for the rest of them? At the same time allowing it to be set by users, it would be properly updated when rendermode changes again.
No, I absolutely DO NOT WANT this!

Me neither. It's too bad that such misguided checks can only be dealt with after the damage has been done.

Cacodemon345 wrote:Then consider all chances of this problem being getting actually solved properly finished off, at least for me.

Impossible. We can set vid_renderer to 1 by default and deal with those checking for 0 or we can set it to 0 by default and deal with those checking for 1.
There's no other alternatives here. And think we have to preemptively block vid_rendermode entirely for both ACS and ZScript because it poses the same problem if some users just cannot act responsibly.

by **drfrag** » Fri Aug 10, 2018 7:58 am

Then add the CVAR_NOSET flag instead of a warning (actually there would be no need for setting it manually).

by **Cacodemon345** » Fri Aug 10, 2018 7:56 am

Then consider all chances of this problem being getting actually solved properly finished off, at least for me.

by **Rachael** » Fri Aug 10, 2018 7:52 am

drfrag wrote:What about setting vid_renderer to 1 for vid_rendermode 4 and 0 for the rest of them? At the same time allowing it to be set by users, it would be properly updated when rendermode changes again.

No, I absolutely DO NOT WANT this!

by **drfrag** » Fri Aug 10, 2018 7:51 am

What about setting vid_renderer to 1 for vid_rendermode 4 and 0 for the rest of them? At the same time allowing it to be set by users, it would be properly updated when rendermode changes again.

by **Rachael** » Fri Aug 10, 2018 7:42 am

No one's asking for vid_renderer to represent the true state of the renderer, in any form whatsoever.

All I am saying is, I think vid_renderer should be changeable by the user, mostly on the count that we don't know how many mods out there check for it, nor do we know what they check for.

Something automatic would be helpful, yes, but ultimately nothing we create will be completely fool-proof as far as automatics go.

by **Graf Zahl** » Fri Aug 10, 2018 7:37 am

There is no way this check can be sanitized. All that can be done is spoon-feed the correct value to mods checking it so that they do not abort or print useless messages. The live switch of the renderer makes it impossible to get sane results.
My guess is that the number of mods checking for 0 is extremely low (one to be precise?)

by **Cacodemon345** » Fri Aug 10, 2018 7:24 am

I agree with Racheal here. Making the CVAR unsettable will introduce problems because changing the renderer would only change vid_rendermode and not vid_renderer, causing issues because the CVAR has the CVAR_NOSET flag. In such case, only the engine code would perform changes on the CVAR depending on what renderer the user using, and the user won't be able to actually change the CVAR permanently.

by **Graf Zahl** » Fri Aug 10, 2018 7:13 am

We only need a CVAR if 1 is supposed to be the default.

by **Rachael** » Fri Aug 10, 2018 7:02 am

Well the system we have is the best. If we must have an internal CVAR definition for this, setting CVAR_NOSET on it is a really bad idea.

by **Gez** » Fri Aug 10, 2018 5:27 am

Didn't we discuss a compatibility feature that would fake a CVAR setting for known mods?

ZDoom

this map/mod/wad requires opengl renderer

Post a reply

Expand view Topic review: this map/mod/wad requires opengl renderer

Re: this map/mod/wad requires opengl renderer

Re: this map/mod/wad requires opengl renderer

Re: this map/mod/wad requires opengl renderer

Re: this map/mod/wad requires opengl renderer

Re: this map/mod/wad requires opengl renderer

Re: this map/mod/wad requires opengl renderer

Re: this map/mod/wad requires opengl renderer

Re: this map/mod/wad requires opengl renderer

Re: this map/mod/wad requires opengl renderer

Re: this map/mod/wad requires opengl renderer

Re: this map/mod/wad requires opengl renderer

Re: this map/mod/wad requires opengl renderer

Re: this map/mod/wad requires opengl renderer

Re: this map/mod/wad requires opengl renderer

Re: this map/mod/wad requires opengl renderer

Post a reply

Expand view Topic review: this map/mod/wad requires opengl renderer

Login • Register