...like a base that belongs to us. 

recommend "wateralpha" instead of "_wateralpha" since keys with an underscore are intended for the compile tools, not the engine (engine is supposed to ignore them) 

thanks for the pointer metl.

Thinking a bit more on it, these worldspawn keys should really behave the same as the existing "fog" and "sky" ones, not persisting beyond the map they're used in.

so maybe something like this:

Worldspawn keys:
wateralpha
slimealpha, etc.
skyfog

If set, the provided value is used for the duration of the map instead of the r_ cvar. Does not change the values of the corresponding r_ cvars.

Cvars:
r_wateralpha
r_slimealpha, etc.
r_skyfog

Gets/sets the fallback values used in maps that don't specify a value in worldspawn (i.e. unchanged from current behaviour). If the current map is overriding "wateralpha" with a worldspawn key, and you query "r_wateralpha" from the console, you get the fallback value, not the current map's worldspawn value.


The only missing use case here is: you've overridden some of these values in worldspawn, are playing the map, and want to check / tweak the values in the console. The cvars won't work because they get/set the fallback value that would be used if you weren't using the worldspawn key.

Idea: a set of commands:
wateralpha
slimealpha, etc.
skyfog

These print the current settings (whether coming from the cvars or worldspawn keys), and let you change the settings for the duration of the current map. They never change the corresponding cvars. i.e. same principle as the "sky" and "fog" commands. 

I can't really see how people would implement _wateralpha differently

Heh.

FQmkV exempts liquids beginning with *tele from wateralpha, and provides the unique keyword "r_texprefix_tele" to override or disable it.

There's the inconsistency brought up for Barnak earlier, where some engines will apply wateralpha to bmodels with liquid textures on them and some won't, making it harder to use the func_illusionary trick to get around undesirable wateralpha settings in the first place.

To make sure that engines which "fixed" the behavior still give you the desired original-quake behavior, you have to forcibly set alpha 1 on those func_illusionaries, which causes back to front sorting issues in all engines. (This is visible on the lava in my jam2 map.)

If there are cvars I can poke from progs.dat, do I have to worry about them being archived in the cfg, or not? Does the player's cvar setting override the worldspawn key or vice versa? How are the infamous not-water liquids found and handled?

If you don't see how the quake community can implement something inconsistently, you're underestimating their ingenuity. :) 

How about a fix for flickering entity as well?

Its where large bmodels end up spread across multiple leafs and go invisible depending on where the player is stood.

The bmodel doesn't even have to be that big - just an oddly shaped leaf or bmodel can do it. 

recommend "wateralpha" instead of "_wateralpha" since keys with an underscore are intended for the compile tools, not the engine (engine is supposed to ignore them)

The intent here was to make it so that it doesn't throw up errors in engines that don't support the key, since they're already trained to ignore it : - ). I know the original intent was for tools, but it can serve a second purpose for things the engine understands but is hiding from the QC and third for hiding QC fields from those pesky mappers 

Coders: the bug in #965 is fixed by increasing MAX_ENT_LEAFS in progs.h 

hexen2 ignores r_wateralpha on lava.
but it uses r_wateralpha as a general transparency value on other things like transparent projectiles etc..

when you have refraction/defraction effects, wateralpha is a nasty kludge that is often best ignored completely.

leading underscore means that mods can't see it, but that other engines won't spam like crazy leading you to think the map is buggy.
no underscore is an actual entity field. probably not desirable but at least qc can see it. and then someone thinks that changing it in code should work too. and then we get people complaining that it doesn't work and all the programmers bitch about it.
really, engines should probably support both, and mappers should use an underscore.

tweaking cvars randomly from gamecode for anything except menus is evil, and WILL glitch one day, one time... AND THEN THE USERS COMPUTER WILL BLOW UP AND THEY'LL SUE YOU! so don't poke cvars, mmkay?

I've taken to making empty cvars mean 'default setting'. if r_lavaalpha is empty, FTE uses r_wateralpha instead. I'd say if r_wateralpha is empty, use the map's _wateralpha key instead, or 1 if not present. or something. Meh, I dunno. Lots of ways to try to get it to be automatic and most of them will conflict with what you think should be the standard. And all of them useful in some way where the others are not.
All I can say is that in an engine with shaders, you can ignore the cvars completely and live in bliss because of it. Cvars have their place, but generally its better to just make the content define how it looks instead of the user tweaking random things because the map's readme says to do so, and breaking other things in the process. Yay shaders. And needing extensions (over q3 compat) to actually get the water looking reasonable. Bah. There's a flaw to everything.

The great thing about standards is that there are so many to choose from.

K, I'll shut up now.

maybe. 

Fitz 0.85 was a standard. QS as a fork should adhere to it. 

if r_lavaalpha is empty, FTE uses r_wateralpha instead.
This sounds like the best thing to do

I'd say if r_wateralpha is empty, use the map's _wateralpha key instead, or 1 if not present. or something.
This sounds okay too, so long as you don't archive r_wateralpha. I suppose there are three ways to treat the interaction between prior values of r_wateralpha and the _wateralpha key

1. Any prior setting of r_wateralpha wins - bad if you archive or if people set r_wateralpha in autoexec.cfg, but ok for people running the map fresh otherwise.

2. _wateralpha is a temporary override of r_wateralpha, effective just for the duration of that map. Removes the ability for players to adjust the wateralpha once they load the map - which might be good or bad I guess

3. _wateralpha effectively sets r_wateralpha, so the value persists. By far the easiest way to do it, and consistent with how QC mod-based wateralpha works, but when compared to the alternatives seems quite disruptive... 

4. at map load, check for _wateralpha and use it, otherwise use r_wateralpha. But do not update the value of r_wateralpha. If user changes r_wateralpha while the map is running, override the map's value. When user quits the game, r_wateralpha will be saved, but since it was never set by the map value, it retains the last user-specified value. 

and a bit more elegant than my idea in #963

Spike, I agree the content should dictate looks. I understand in q3 the water alpha would in the shader, so basically a property of the texture itself. So from that point of view, _wateralpha in worldspawn could be seen as a workaround for lack of shaders in vanilla q1 bsp. 

in fte I have some cvar latching feature. if the server tries changing a cvar, the client tracks the user's desired setting and resets it to that at map end (it also reverts to it if the server tries to set the default, so fov works with sniper scopes).
hurrah for strategies to ignore mods, while not ignoring them at the same time.
configs _never_ get the server's value, they only get the desired value written.

for other engines, you can probably get away with just changing r_wateralpha.value directly if the key is present, and unconditionally reparse the cvar's string for the next map.
its probably just 3 lines of code (assuming fog/sky parsing already). doesn't really help with mods that try to take control of it though... so nothing new is broken by it, hurrah, but also not fixed.
cheesy hacks rock... 

(I know the discussion's moved on to agreeing on an implementation, which is <3, but I want to justify my rants. there's generally two classes of engine, from a mapper's point of view:

> the fitz/baker/spasm quakes for people who want the game to look mostly like Quake always did, but run well on modern systems and be generally improved from a functional standpoint, and which add only simple/graceful features that don't detract from a 'classic' feel when mappers use them well (skybox, fog, colored lightmaps)
> the fte/dp/fuh/etc quakes for players who want to override as much of the original content as possible with normal/specular high-res content packs, new water and chrome shaders, and dynamic disco lights, such that I'm never going to get them to look at a map I made the way I made it anyway

obviously it's only the first category that I'm interested in supporting because it's only users of the first category that are fully interested in what I'm making, and because I can't account for all of said disco shaders anyway I couldn't support them consistently if I tried.

that's why my hackles go up when the anything-goes, a-programmer-thought-this-would-be-fun-to-add mentality of the second group begins to leak into the first, because it threatens the reliable consistency fitzquake has provided for so long.

intermission over) 

That you didn't lead that post with "And Now, The Intermission" so I could imagine crackly phonograph music while reading it. 

Neither do engines...

FTE/DP are actually pretty nice to play Quake in, it's just that a lot of players are not blessed with taste and restraint. That is not the fault of the engine... even Fitzquake allows the loading of external textures, thus letting users plaster your level with images of Goofy if they so desire.

Both DP and FTE can look pretty decent for standard Quake (I guess someone will scream "PARTICLES!" now, well, go and make a faithful particlefont then) if you leave the realtime lighting disabled. These engines are perfectly capable of displaying lightmaps and not much else, you know.

They can be even nicer for modding. Why not create a fancy menu (with all the OMGbling removed) for your next map pack? Doesn't affect the faithfulness of the level one bit. How about pretty loading screens for your humungous masterpiece map that give people a foretaste of what's to come? Same. And no player will ever know how many engine extensions you use in your QC, because things like tracebox() are 100% behind-the-scenes.

Bigger maps? Rotating entities with proper collision? Terrain with texture blending? Mesh collision? Rotating dynamic lights? Stereo sound? Scriptable particle system? True type fonts? Splitscreen?

Doesn't sound like evil incarnate to me, but what do I know. I'm just a poor sinner. 

i never develop mods for dp because the engine always breaks my code. 

i need to remember to log in..... :P 

These engines are perfectly capable of displaying lightmaps and not much else, you know.

every engine claims that it degrades to a perfect simulacrum of vanilla Quake, but they all look a little queer when they do, and more importantly, they're all inconsistent about how they do it. try exploiting any small quirk in Quake engine behavior for a positive effect and you'll quickly find most engines have either broken it or "fixed" it.

And no player will ever know how many engine extensions you use in your QC

They will if they use an engine that doesn't support them. To take advantage of any of them, or any of the rest of these silly features, I'd have to require one engine over another. There is no quicker way to make people upset and stop them from playing your mod in the first place.

Bigger maps? Rotating entities with proper collision? Terrain with texture blending? Mesh collision? Rotating dynamic lights? Stereo sound? Scriptable particle system? True type fonts? Splitscreen?

Because if I felt like I needed any of that stuff, I wouldn't be mapping for Quake. Not everyone thinks that Quake is "missing" next-gen features. When engines do add them, the collective effect both on their own codebases and on the community is that it makes it harder to create content that doesn't use them.

Doesn't sound like evil incarnate to me, but what do I know. I'm just a poor sinner.

Please re-read my earlier examples until you understand that I'm not trying to take your eye candy away from you, I'm just trying to prevent collective action on the part of seemingly deaf engine hobbyists, and the broken inconsistent 'standards' they unintentionally push on users, from taking far simpler little things away from the people who are actually still trying to make content for this game. 

What exactly is your beef here? Your posts read like you're trying to defend something, but it seems like you're arguing everything you can in order to do so, obscuring the point that you're actually trying to make.

Fact of the matter is that 'perfect simulacrum of vanilla Quake' is a really really wooly definition.
In terms of visuals, this generally means software rendering. except they use linear filtering...
In terms of networking+gamecode, this generally means OMGYOUGOTOWNED.
In terms of console commands, this generally means: what do you mean I have to set port BEFORE connect? why does reconnect not work? argh!
I'd be curious what you think looks a little queer with fte's 'fps_preset normal' setting, maybe I can improve it for you (and any other potential users that don't use some other setting instead).

The great thing about QC extensions is that they stop modders from going insane. strcat will greatly reduce the complexity of certain things for instance...
The fact that there are still engines that do not support this basic feature is completely absurd. It is really no wonder that you have to resort to the hacks that depend on those bugs that got fixed.
Oh noes! it won't work in dos/win/glquake! Who even still uses those anyway?

'next'-gen features are often fun, but yes, they're not quake. however, bigger maps is more quake!
rotating bsps were used in hipnotic, was that not quake? the fact that the code is much simpler to produce and doesn't require hacks is surely a good thing?

who, exactly, do you consider deaf? why do you believe this to be the case?
considering this part is an engine topic, would you mind creating a rant topic on inside3d where there tends to be more modders around that might actually *see* your point of view?
The fact of the matter is that a few posts in the middle of a topic on a specific engine can _EASILY_ be overlooked by pretty much everyone (except maybe that engine's author). Help out and give everyone xray specs, and maybe the 'blindness' issue will deminish slightly! :)
In other news, baker was asking for some test mods (to see if things are broken, I assume) on inside3d. You may wish to help out and give him some suggestions, or perhaps some specific testcases for the things that irk you. 

Any chance to get any of the features I requested back on 2014/02/05 (see above) implemented?

I'd at least like to see support for .vis files added since all my downloaded mods have been optimized for utilizing this feature from Fitzquake Mk V. Much better than having the original non-vised maps and improved vised maps in the same directories. 

I posted a proposal for the worldspawn keys, which is borrowing metl's idea in #971, on inside3d, along with a prototype implementation in QS (w/ win32 binary):

http://forums.inside3d.com/viewtopic.php?f=3&t=5532 

I'll add whatever gets decided upon after it runs the course of the normal feedback loop and a map release by a veteran mapper uses it. 

suggestions
-
option to enable bloom
option to disable transparent water
option to disable crosshair
option to enable vertex lighting
optional lighting gun beam dynamic lighting (like directQ)
optional shalrath, scrag and death knight projectile dynamic lighting
adjustable particle transparency & density
adjustable liquid transparency
selectable individual liquid transparency (r_telealpha etc)
defaulting to 44khz sound mode

bugs
-
teleport textures are transparent
e2m3 nail trap doesn't work
with 'r_novis 1', explosion sprites don't appear underwater
water in Malice is not see-through anymore 

suggestions
-
anisotropic filter option
point sampling filter option (for classic 'blocky texture' quake look)

bugs
-
water surface is bugged; has visible gaps on the surface