InsideQC Forums

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

I second that.

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).

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.

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.

LordHavoc wrote:

ericw wrote:[*] If the player changes the “r_wateralpha” cvar while the map is running, the engine should switch to using that value until the map is reloaded. This allows for interactive tweaking by a mapper, or lets the player override the value if they don't like the mapper's choice.

Please not this one specific detail, I can support the rest of this extension in darkplaces, but I do not want to have to do latched cvars and other black magic.

I'm fine with removing that; I can see that it forces hacking the engine's cvar system. The intent was to support using quoth's trigger_command (for example) to change r_wateralpha while still using these new worldspawn keys. In hindsight, having a mod/map that changes wateralpha during a map is definitely a fringe feature, and mappers can avoid using the worldspawn keys in the 1% of cases where they really need to change r_wateralpha through qc during the map.

LordHavoc wrote:I'm a little unsettled by the distinction of _wateralpha, _slimealpha, _lavaalpha, _telealpha as this is subject to the engine's determination of what is or is not a given type of liquid (darkplaces for what it's worth also recognizes *rift as a special prefix, which is fullbright and opaque in all cases, because this is used at the end of hipnotic), furthermore it would be nicer for level designers if they can set different alpha for each water texture in their map.

It's true. I was talking to onetruepurple about this and he mentioned some teleport textures just don't start with *tele, like *starfluid in knave.wad, so if you wanted to take advantage of the "_telealpha" worldspawn key you'd have to rename the texture.

something like a worldspawn key "_wateralpha_X" "0.25" to set the alpha to 0.25 for texture "*X" is a possibility. otoh, there's more bookkeeping to do in the engine to implement that, and it's more effort to take advantage of for mappers (have to keep track of the set of liquid texture names you're using).

I think the water/slime/lava/tele is a good balance between being dead simple to implement in engine, trivial for the mapper to apply to a map, and providing enough functionality that it's useful to mappers.

LordHavoc wrote: Regarding func_illusionary - there is nothing special about the inward faces vs the outward faces, both would be affected proportionately by the entity alpha (that is to say, it would take the user cvar r_wateralpha, and then multiply it by the entity alpha).

this is sort of a tangent, but current DP doesn't seem to use r_wateralpha at all for brush entities with water textures, it just uses the entity alpha. Fitz engines only use r_wateralpha when the entity alpha is 0, otherwise they use the entity alpha. Do any engines multiply r_wateralpha by entity alpha?
the wateralpha_brush.bsp in the zip linked near the bottom of my first post is an example testcase for this.

LordHavoc wrote: P.S. Who wants to own the extension spec for this? Or am I expected to write up a suitable explanation when I add it to dpextensions.qc like many other vague proposals in the community which were never properly defined as extensions? And what name should the extension be for qc to checkextension() to detect this? QUAKESPASM_GFX_WATERALPHA ?

QUAKESPASM_GFX_WATERALPHA sounds fine. I can make a little explanation along the lines of DP_GFX_FOG and DP_GFX_SKYBOX.

And I guess _skyfog could be QUAKESPASM_GFX_SKYFOG. Btw, I just realized that fitzquake's r_skyfog is the same as the 5th value in DP's sky command (after 'density red green blue').

Spike wrote:I would say to officially advertise it as _foo but to accept both _foo and foo.

this sounds good to me. "sky" and "fog" work the same way in fitz and dp, and I assume others as well?

leileilol wrote: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.

Well, in that case, I can understand.