_wateralpha and other worldspawn keys proposal

[frag.machine]

[LordHavoc]

The only cases where you can really count on QC being involved and having meaningful input on the situation are:
1. singleplayer
2. same engine on client and server, with an extended protocol (this includes things like stuffcmd of new cvars, that is protocol too).

In general the way I extend map capabilities is to add special parsing of worldspawn on both server and client, not making any attempt to communicate the details; if the client and server have different versions of the map - or different versions of the associated .ent file - that is not the engine's problem to solve (I am aware of the fact that .ent files are used for ctf map patching on servers, and such - this is unfortunately not a supported use case for worldspawn changes).

A couple existing examples of this are how darkplaces parses the "sky" key and the "fog" key from worldspawn, rather than networking this, let alone involving qc - the qc is often not only unaware of this functionality the level designer wanted to use, but also predates the level designer wanting to use it - id1 progs.dat being the typical example, quoth progs.dat being another example.

It's rather alarming to assume that maps were made for the qc they are running on, or that the qc was made for the maps (even less likely).

[leileilol]

also the whole "compatibility with glquake and other old engines" goosechase reason is silly since this was suggested from a mapping place where vanilla engines and their limits don't exactly apply.

[r00k]

i am going way out on a limb here, but since we are talking about custom maps and custom engines...
could the engine simply look at the first pixel of the texture and either by color or alpha value determine it's opaqueness?
I like the idea of per-texture transparency but think having texture names parsed in worldspawn, or even an .ent file with textures, would be cumbersome.

[ericw]

[ericw]

[mankrip]