What's in that quakespasm.pak file ? What are the differences if I remove it ?

The readme doesn't say much about this :

>Quakespasm content customization moved from engine-embedded
> into a new optional quakespasm.pak file. 

Maybe another feature request : a command to list all music files.

I can't remember all the music file names I placed into the music directory.

Currently, we can browse the map directory with TAB. Maybe something similar could be usefull for music ? Or at least a music list command ? 

hopefully adding support for these worldspawn keys is a step in the right direction.

Agreed, and thank you! Still, if only one engine out of a half dozen implements it, or if they all implement it different ways, it's still effectively unusable.

I really don't want to just say "this mod requires this engine" because everyone has their own choice based on personal preference, or based on what engine they can even run (because they're on a Mac or whatever), so that isn't an option either. That limits level designers and modders to the subset of features that are global enough to be effectively standard, which at this point is a _fog key and an .alpha key and not much else.

I explored using stuffcmds to switch the skybox during gameplay, so the player could go underground and emerge somewhere with a different backdrop, or to simulate lightning flashing during a storm. Research immediately revealed that not all popular engines have a console command to change the skybox, and the ones that do don't use the same command. The idea survived about five minutes.

Recent QS changes have even made me back off on stuff that would have been possible in stock Quake. I'm now greatly constrained in how I print text to the screen and how much (any more than 384 characters and apparently I'm creating a "rude mod," to quote the QS readme), and I've given up on having a custom demo or set of demos to play at the main menu because someone contributing to QS decided that the startdemos command in quake.rc should just be ignored, for no other reason than he prefers it that way. These are rather disheartening precedents.

So, yeah, _skyfog and _whateveralpha keyvalues would be nice! but unless we can convince Baker, LordHavoc, et al to implement the same things the same way, from the perspective of a mapper there's not much point. :( 

I have hundreds of nice custom maps inside my id1/maps folder. Very often, I simply don't know which one to play, and would like to be surprised.

So a "randommap" command could load some randomly selected map from the whole list. The player would then be surprised each time he calls "randommap" from the console. A keyboard shortcut could even be assigned to the command.

Wouldn't that be great ?

I'm not a programmer, so I don't know if this could be done for QS.

What do you think, Quake Gods ? 

I can't really see how people would implement _wateralpha differently, it's a much safer bet than fog ever was for being consistent. It's also one of those gracefully degrading features like skyboxes - your map doesn't stop being playable if the water is off. That means there's a nice path to adoption, you get a "recommended engine" not a "required engine".

Suggesting people should bundle it with the newer features is a bit of a risk, but hopefully the one will carry the other... 

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