Template talk:KeyValue

Key Value definitions incomplete

Key value definitions should include both the "Friendly Name" for the keyvalue and the name used in the code, if only for the sake of completeness. A field should be added to this template along with a statement to that effect. Kp.2012 20:57, 4 May 2012 (PDT)

Output and input values

Inputs and outputs can have values, this should be standardized.--Henke37 09:40, 1 September 2012 (PDT)

Default engine values?

Apart from FGD definitions (which can be modified), keyvalues can have in-engine defaults which would be useful to know for the various ways in which entities can be created. So should something like that be added here, or maybe done in some other way, or even at all? I found myself needing to know default values a few times but I couldn't rely on the FGD since it may not always reflect the true defaults, especially for custom FGDs. It would of course affect a lot of pages and require a lot of work to add to all the entities (which can be done slowly over time), but I think it would be a useful addition to consider, if not purely just for completeness. --BetweenReality (talk) 20:56, 25 August 2025 (PDT)

I've drafted the proposal in Template:KeyValue/sandbox, and the relevant draft doc in Template:KeyValue/sandbox/doc for testing. I essentially just copied the existing code for default values used in Template:MatParamDef since that's an existing standard, and I fixed the formatting to work with this template, though I also moved it to be after KV Type instead of at the end since it's more relevant to the keyvalue itself than the game availability parameters are.

I'll wait a few days before merging these into the real template in case anyone has any reservations about this proposal. Once implemented it shouldn't affect any pages until people start using it. --BetweenReality (talk) 12:44, 28 August 2025 (PDT)

Usually engine default value is always 0 or empty string if the key is not specified. Wouldn't this be something that might differ between various fgds ? Though I guess it's fine to add as a parameter with consistent formatting. And maybe different param for fgd default vs engine default ? --Nescius (talk) 19:37, 28 August 2025 (PDT)

I'm not sure of the extent of it but when default fgd declarations don't match the engine defaults it could be useful to know both, as someone using such an fgd will effectively have different defaults for entities created in hammer, yet entities created in other ways such as ent_create are not bound by that fgd and would use the engine default. In that case the usefulness of an additional fgd-specific parameter comes down to just how many differences there are from engine defaults vs official fgd defaults (and only official fgds matter since custom ones can change anything unpredictably). Otherwise the single parameter would be enough to correctly work for both the majority of the time.

Since most of the time the default would be some kind of null value like 0 or an empty string, those wouldn't be as important to add as keyvalues with non-standard defaults would be, but it would still be useful to know if any given keyvalue indeed does default to some null value.

For the case that different games have different defaults in engine, fgd, or both, those can be specified by using the game templates (so something like {{KeyValue|Example|intn=example|integer|value=1 {{HL2}}, 2 {{portal}}}} ). The same thing can be done if engine and fgd were separate parameters. --BetweenReality (talk) 20:49, 28 August 2025 (PDT)

If this is for the purposes of using the info when creating entities not in Hammer, how do you explain that to the reader (so they don't assume the "default value" means the FGD default - that's what I first thought) without going overly wordy about it? This should be as brief and efficient as possible. Personally I think the template already leans into looking bloated.

For those entities where there's such difference (FGD default and source code default) and where it has an impact, I'd just use a traditional note on the pages. Cvoxalury (talk) 02:30, 29 August 2025 (PDT)

I concur; the way it's handled currently is sufficient.
— SirYodaJedi (talk) 06:08, 29 August 2025 (PDT)

I suppose the distinction between FGD and engine defaults isn't the point as much as having some kind of default value documented at all (my initial question mainly about engine defaults since those are hardcoded and not easily knowable like the FGD ones are, even if identical most of the time). If we have internal keyvalue names and types and their descriptions, why should the default be excluded? The documentation here serves some kind of purpose additional to FGDs, otherwise in most cases someone could go and look at those FGDs themselves to get all that information anyway. It's the last missing piece for keyvalues that hasn't been documented here, the one thing that requires looking into the FGD to find (which isn't even possible for non-FGD keyvalues). Every other FGD parameter is documented, why not this one?

The simplest most efficient way would be to have the one parameter catch both cases and use regular notes for any important differences between the two, most of the time they would be the same anyway, but the idea was mostly just to have that documentation present. The bloated nature of the template and what to do about it is not limited to this proposal, this is just the current main thing to use for keyvalue documentation so I proposed it here. --BetweenReality (talk) 12:06, 29 August 2025 (PDT)