IfOption( Renderer ) in MenuDefs

[Pixel Eater]

Referring to the If statement section in the Wiki. Could a check be added to determine the current renderer?

There's been some debate whether the 2D Refactoring will consolidate the 'r_dynlights' and 'gl_lights' cvars but if not, this request would make future menus more intuitive.

[Major Cooke]

I think you can do something like this already with ZScript.

[Pixel Eater]

Thanks for the tip, I found this but I definitely need more sleep before I can delve deeper into it. Can you tell me though whether or not Zscript can communicate the result to MenuDefs or if I'd have to rewrite the whole menu structure in Zscript for it to work?

[Major Cooke]

It can. But it depends on what you want to do. I've honestly never worked with IfOption, so there's not a whole lot I can tell you.

Browse these forum posts to see if you can find what you're looking for, but I do know this much -- if you want to make one of those custom thing like, say, "NumberFieldCustom", it must have the name "OptionMenuItemNumberFieldCustom" and it must inherit from at least OptionMenuItem itself, if it's for an option menu. Same goes for listmenus. Bear in mind list/option menu items are not mutually compatible, so if you want to do something of that sort, you'll have to set up the classes yourself -- but at least it's now possible.

Unfortunately it's been so long since I last worked with menus so I don't remember what else needs to be considered... Something about the init function being able to set up the parameters? Something like that, involving them being read in, in that order, based on said function...

Your best bet for menus, however, is to check out the source code and see how it's set up for all inheriting items from there.

[Graf Zahl]

Menus are static, they cannot have conditionals on dynamic values. And with the next version (after the planned survey-disabling point release) the renderer will be switchable live so this makes even no sense anymore.
r_dynlights vs gl_lights is intentional. People may have different preferences based on the renderer, be it for visual style or performance. This is the main reason they weren't merged.

[Pixel Eater]

Now that's a weird and welcome curveball! Having live switching actually breaks what I had planned as it expected the restart. But this is good

[Rachael]

It should also be noted that with this new system, vid_renderer and r_polyrenderer and swtruecolor were merged into one cvar - vid_rendermode - and vid_glswfb has been removed since any other backend no longer exists anyway.

[Pixel Eater]

Browse these forum posts to see if you can find what you're looking for,

I really need to learn some basic Zscript, that mostly went over my head Thanks for directing me there though, I'll return to it when I know more!

It should also be noted that with this new system, vid_renderer and r_polyrenderer and swtruecolor were merged into one cvar - vid_rendermode - and vid_glswfb has been removed since any other backend no longer exists anyway.

Thanks, that will simplify the menus even more. I'll have to wait until the Mac developer build gets updated before I can add the changes to my proposal.