Menu Item Value Handling (Patreon)

Now I'm working on implementing the functionalities needed to handle more kinds of menu items.

Custom discrete values (e.g. HUD style "None", "Bar", "Overlay", etc) should be easy to implement.

However, there are some item values that requires their input and output to be treated slightly differently. For example, some options takes effect when their values are beyond a certain range, but the menu should output specific values for them inside of that range. Such options must be implemented in a way that's flexible to read while having strict outputs.

Continuous ranges should also support custom naming. Some examples:

• Zero value ("center", "off", "false", etc.)
• Negative values ("left", "down", etc.)
• Positive values ("right", "up", "on", etc.)
• Non-zero values ("on", "true", etc.)

The edges of each range should also be defined as exclusive ("lower/higher than"), inclusive ("equal or lower/higher than"), or infinite (no edge). For example, the ranges of opacity values should have an inclusive minimum edge (50% transparency starts from 0.5) and an exclusive maximum edge (they should stay below the initial value of the next range), with the first range having an infinite minimum edge (negative values should be treated as 0%) and the last range having an infinite maximum edge (anything above 100% should be treated as 100%).

I'm thinking of using these words to define the ranges' limits:

• Minimum value: min ( >= )
• Minimum value: above ( > )
• Maximum value: below ( < )
• Maximum value: max ( <= )

Some range syntax examples:

• All positive values: above 0 max infinite
• All non-negative values: min 0 max infinite
• Negative values from -100: min -100 below 0

Of course, "below infinite" and "max infinite" should be redundant statements, treated equally by the engine; same for their respective above & min counterparts. But min & max are faster to type and easier to understand when dealing with infinite limits.

Since some menu options will need multiple ranges, it will be likely better to define each range individually. Here's a tentative example:

• menu_additem_valuelist "Weapon position" scr_ofsy
• menuitem_add_range "Left" min infinite below 0
• menuitem_add_value "Center" 0
• menuitem_add_range "Right" above 0 max infinite

I could also make the infinite limits implicit by omitting them:

• menu_additem_valuelist "Weapon position" scr_ofsy
• menuitem_add_range "Left" below 0
• menuitem_add_value "Center" 0
• menuitem_add_range "Right" above 0

Of course, having both the minimum and maximum limits being infinite shouldn't be accepted.

Something else I've looked into are menu options that outputs multiple values at once. The only one in Quake's menu system is the "Always run" option, and looking into it, there are some issues. Despite outputting into two different cvars (for backward & forward speeds), it only reads from one cvar (for forward speed), which can cause issues since the backward speed may not correspond to what's displayed in the menu. Plus, modifying the forward & backward speeds is inconsistent with the behavior of the +speed command, which also affects other inputs. All things considered, menu support for modifying multiple values on a single item should not be implemented. For the "Always run" option, it's better to implement a single cvar that behaves identically to the +speed command when enabled. And I'll split the "Aim assistance" option in two menu items, one for vertical aim assistance and another for horizontal aim assistance.

Another thing that should inevitably be implemented are some sort of conditional expressions. I haven't looked enough into this yet, but there are some options that should be disabled or hidden under certain conditions.

The disabled ones should have their values labeled as "unavailable", because "disabled" could be mistaken for "turned off" (i.e. a "disabled item" can have either an "enabled value" or a "disabled value", but an "unavailable item" will always have an "unavailable value"). For example, "Slope look" is unavailable when "Auto-center view" is disabled.

As for hiding menu items, I'm not entirely sure about this because it would complicate the browsing & scrolling of the menus, but I'll look into that to see if it's really needed.

There's also some other kinds of menu items to be worked on later, such as items with images (crosshairs, player colors, etc.), music playback selector, and so on.