|
Title: CVAR descriptions in console Post by: Gig on March 22, 2018, 03:16:50 AM I was just casually taking a look to a diff in Quake3e (https://github.com/ec-/Quake3e/commit/cf13b720d8f43e5ee15fccc953ddc5561b330cf4) (an ioquake3 fork with very active development at the moment), and I noticed this, where they added a new cvar:
Code: + fs_locked = Cvar_Get( "fs_locked", "0", CVAR_INIT ); PROs: - Allows players to have basic infos about what a certain cvar does (and about what specific values do) without having to search outside from the game (e.g. on the wiki - Of course, the descriptions shouldn't be as detailed as on the wiki!). - These descriptions may also work as reminders for developers, as if they were comments, in source code. - (Potentially) UI3 may show such infos about certain GUI options linked to specific cvars, when mouseovering or by clicking a small icon near the option. (Note: UI3 has already got a sort of "status line" which shows a descriptive text when mouseovering a certain option -such text is defined in a specific file, which may potentially even be language-specific-, but it's limited to a single line of text and AFAIK is not accessible through the console). CONs: - Initial "population" may be a big task (however maybe they are not necessary for every single cvar and one may copy some existing descriptions from quake3e - Note: I don't know if they added such descriptions to many existing cvars or only to their "new" ones). - A bit more stuff to maintain. - Some more lenght in source code. - A bit more resources utilization (however they are just plain text). - What would happen if using a such thing in gamecode with an engine not supporting it? A crash? A very long series or warnings?[1] I just wanted to point out this, I don't know if you will be interested. It might be useful, but PROs and CONs have to be evaluated. [1] Maybe a workaround for that would be to move cvar descriptions to standalone files, similarily to the "status line" texts in current UI3 nightly builds. That would also theoretically allow language-specific cvar descriptions. But that would lose a bit the "pro" of acting as "reminder comment" directly in source code (although the reminder would still be available by checking the apposite file). Title: Re: CVAR descriptions in console Post by: sago007 on March 22, 2018, 01:20:20 PM I am a big supporter of inline documentation. The fact that the documentation always follows the version number is a big plus in my book.
Of course the benefit must outweigh the cost (as always). Such a system will of course miss all historical mods and also dynamic cvars (like disable_* and replace_* cvars). Title: Re: CVAR descriptions in console Post by: Gig on March 22, 2018, 02:38:22 PM Such a system will of course miss all historical mods and also dynamic cvars (like disable_* and replace_* cvars). You do remind me about the "in-game" help system RMF made years ago (based upon OA 0.8.1). Of course it does not include replace_* cvars (as they did not exist back then)... I mean it had the approach of starting as a "game manual" more than telling the meaning of a specific cvar. It's years I don't try it, but IIRC you installed it and then typed "/help" and so it showed a list of topics. (DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Manual#In-game_help http://openarena.ws/board/index.php?topic=3725Of course, that one was technically just a trick... Also, maybe it may be interesting also to include some help about some commands other than cvars... maybe something like "\map /help" (or maybe "\help map")? Just brainstorming... Title: Re: CVAR descriptions in console Post by: fromhell on March 22, 2018, 04:51:37 PM The way i'd probably do it to keep the code neat and attempt to be module compatible would be a big table possibly loaded externally.
like char cvarhelp = { "cg_leienhancement", "Enhanced local entity integrated enhancement for more visual effects" "cg_bobModel", "Gun bobbing style. 0 - off, 1 - default, 2 - arc, 3 - thrust, 4 - figure 8" and then some function that attempts to match this table to all the cvars that get loaded at the client level. I wouldn't want to put walls of winding text on this, and i'd probably only have the chelp show up when a **single** cvar is tabbed so it's not a overload of text. (an ioquake3 fork a very very distant one at least. It's forked from before the disasterous SDL implementation and made its own advancements for years. It would be very disowned (and probably blocked from issue reporting/pulling etc) at this point. |