_wateralpha and other worldspawn keys proposal

[Spike]

when mappers are using trigger_stuffcmd or whatever in thier mods, those stuffcmds are NOT saved.
more a limitation of the mod than anything else, but hey, this stuff is about as widespread as the engines.
tbh, the real problem here is maps that try to target vanilla id1 and thus have no specific mod to hack cvars for them, as well as mods that do it in a buggy way.

tbh it might just be better to have some sort of
"_cvar_r_wateralpha" "0.5"
key instead. such a mechanism would allow the map to override any client cvar they want, not just water alpha, and in a generic way.
of course, you'll definitely need some kind of latching mechanism thus rewriting the cvar code fairly significantly, but that can be used to handle stuffcmded cvar changes too (with quite a few complications with the cbuf in order to get that working), which should handle both existing mods (still with the savedgame bugs though) and new maps that use it alike.
this is how I intend to implement _wateralpha in fte, anyway.
naturally this won't help with per-texture stuff, but hey, it solves a load of other things (anyone who uses "_cvar_r_novis" "1" should be shot).

[ericw]

@mankrip, yeah, also relevant are some posts on Preach's blog:
http://tomeofpreach.wordpress.com/quoth ... variables/
http://tomeofpreach.wordpress.com/2014/ ... detection/

Sounds like Quoth implements a trick like you describe with info_command_spawn, it was designed for executing "r_wateralpha XYZ" at map load OR when a save is loaded.
http://tomeofpreach.wordpress.com/quoth ... and_spawn/

But, yeah, I think there is value in having the _wateralpha support in engine too.

[ericw]

[ericw]

Also I made a few updates to the first post, there's a download with some sample maps, and the bugs I mentioned in my patched Quakespasm are fixed.

[LordHavoc]

[mankrip]

What I don't like about "_wateralpha" is that the QC code can't read it. Thus, such a standard would be restricted to the engines that supports it.

For example, let's say that only DP and FitzQuake implements it. If the mapper's engine of choice is FTE, there wouldn't be much reason for him to add the _wateralpha field to the worldspawn, and this would make the _wateralpha field support in the other engines pointless for his map.

But fields with names that can be read by the QC code, such as e.g. cvar_wateralpha, allows the mapper to implement custom map configs to any engine. Sure, it would generate a warning when both the engine and the progs.dat doesn't support it, but that's an innocuous problem.

My point is: if the target audience of the feature are the mappers, it should give as much flexibility as possible for them to implement, instead of restricting them to specific engines.

The more flexible a standard is to implement, the more mappers should adopt it. At least, that's my impression.

[Baker]

From a design standpoint, the presentation of a map, it's textures and it's sky and other presentation parameters belong to the map.

Not to QuakeC. A map should not be at the mercy of QuakeC.

And there are countless progs.dat:
1) id1/progs.dat "Standard Quake". The idea of QuakeC controlling this means that a mapper could not target standard Quake progs.dat (highly undesirable), and would mean all maps with these keys would need to be a -game <gamedir> map of some sort --- which is quite undesirable too.
2) DMSP mod -- the single player mod that spawns monsters in deathmatch.
3) Capture The Flag, various coop mods, Clan Arena, Team Fortress, Rocket Arena, Slide, RuneQuake
4) Single player mods like Quoth or Drake.
5) A large body older maps/mods, which the engine-based method allows very easy use of an external .ent file to "correct". These old maps/mods do not always have the QuakeC source files available.
6) You don't have to know QuakeC to have a map use a skybox or fog, it would be undesirable to require a mapper learn QuakeC just to use a wateralpha key. Mappers don't necessarily know QuakeC.

This spec is actually easy to implement, even for a software engine. In fact, I have added r_lavaalpha and r_slimealpha to a software renderer engine.

Just want to highlight some of background reasons why the engine-based way is, in my opinion, the right way to go.

[Spike]

I would say to officially advertise it as _foo but to accept both _foo and foo. the form without a leading underscore can be used by mods that do support it, and if you target such a mod then you can get the mod to decide.
this would imply that the server should also mute any warnings generated about these known unknown fields when spawning entities, of course, for mods that don't implement it. there's already a few engines that just silence ALL warnings about unknown fields, I'm not saying ignoring all errors is a good thing, but if they're known by the client then they should be considered known by the server too.
actually, omitting the underscore in engines that don't support it may help serve to tell users that they're doing something wrong - like using an engine that doesn't support it - in a non-fatal way. so mapper's choice either way: completely silent; or warnings in some engines and potential for mods to work around it.

the problem with flexibility in general is that it means that there are more possible ways to use something. and more possible ways to use something makes it harder to give a definitive reference implementation that does everything 'correctly' (a flexible interface is an over-complicated monstrosity). in many ways, flexibility is the bane of compatibility - see csqc as an example of that.
remember that for each additional boolean option, you need to double your number of test cases. flexibility is complexity, and complexity is a nightmare to debug and test.
I still think it should support both.

[mankrip]

[Spike]

[Baker]

[mankrip]

[Spike]

the importance of sanitising your inputs:
"cvar_wateralpha" "1;unbindall;alias bind \"echo oops\";alias \"quit\" \"echo ahahaha\";alias alias \"its dead, jim\""

> therefore not changing the current value of the cvar
actually your code snippet will instead tell the user the current value of their cvar, which is probably not very desirable... so make sure its not empty.
but mostly I just hate strings.

@baker, yes, *this* is just r_wateralpha (an extension not supported by software rendering, resulting in warnings about unknown commands), the problem is one of both precedence and consistency. and paranoia. and dead horses. and flogging.

[mankrip]

[leileilol]

I still don't think this kind of thing needs any QuakeC-based intervention at all.