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 

Lots of these are already features. Did you read the documentation? Or do you simply mean menu options?

Also, some of these have been answered at that other forum. It is not very nice of you to ignore that and not mention that you are crossposting the exact same text. 

Lots of these are already features.
>which ones? they aren't to my knowledge

Did you read the documentation?
>yes and the fritzquake as well

Or do you simply mean menu options?
>Mainly as menu options where applicable

Also, some of these have been answered at that other forum.
>actually they haven't been (r_wateralpha 0.5 makes teleport/lava textures transparent) 

Is there a spell somewhere in the necronomicon to enable xinput for lazy single player gamers? 

SDL2 supports XInput, not sure about SDL1. Personally i'd like to add controller support to QS sometime (for playing quake on couches/beds :P). not sure how the other devs feel about it, but it requires a bit of work.

So it's something possibly on the todo list, but not available right now. 

what about my suggestion of a new console command to load a random map, so the player don't know in advance which map will be loaded.

I currently have hundreds of maps in my id1/maps folder, and very often I simply don't know which one to play.

Using a random map command, It could be great to be "surprised" each time we load a new map. I'm sure other players would appreciate that feature too. 

pasting here:

There are a couple of potential issues, one is some mods use .bsp files that are not actually levels but just prefab objects that referred to - so a �randmap� command might try to play these.

Also I�m pretty sure that a �randmap� mode where exiting a level loads a random map instead of the one specified in the trigger_changelevel is almost impossible to implement in a clean way.

So we can see if the other QS devs have a comment, but I�d say it�s probably not a good fit for quakespasm. 

About the randmap command, I was thinking about loading only maps located inside the id1/maps folder, not from the mods (I was aware of the issue you described with mods).

That command is highly desirable if you do have hundreds of custom maps.

Without that random command, many good maps will remain in your maps folder without ever being played for a VERY long time.

The randmap command would give all the maps a chance of being played at any moment you call "randmap". 

Let me elaborate on the idea of that "randmap" command :

You start QS and drop down the console to type "randmap". QS then loads an arbitrary map from your id1/maps folder (mods are all excluded).

You then play that map to the end, and use its exit. That map then loads its predefined second map. Fine. The randmap don't interfere here.

You play the second map (called from the first one), and decide you don't like it. You drop down the console and type "randmap" again. QS then loads a new randomly selected map. If you still don't like it, you could use the randmap command again, until you like the map. And so on.

If a map ends to the default start map, then no problem. You can call the randmap at any time.

This command is simply a way of picking up an arbitrary map in your id1/maps folder.

It may also happens that the command loads the same map again (random selection without memory). This is not a problem since you could call that command again. The chance that it gives you the same maps several times is low if you have hundreds of custom maps inside your id1/maps folder.

The ability to bind the randmap command to a keyboard shortcut would be extremely usefull, IMHO. 

Post #55 applies to me, except I am running Windows 8 and the latest version of Quakespasm. This is on my laptop.

Simply put, mouse movement is wildly erratic, spinning the camera at high speeds in any direction, even when mouse sensitivity is at its lowest. While spinning like crazy for a second or two, it will even cause Quakespasm to freeze for a minute.

The other problem is this: http://www.stjohninthewilderness.org/wp-content/uploads/2014/08/quakespasm.jpg

As you can see, the game resolution is bigger than what its actually supposed to be. You can imagine when attempting to change the resolution to 1920x1080 sections of the screen are completely cut off, like the status bar.

My laptop is running Windows 8.1 64-bit, AMD A8-5550M CPU, and AMD Radeon HD 8550G graphics card. Drivers are all up to date.

Anyone have any ideas or experience something similar? 

It happens to me too, it always did with all the versions of Quakespasm i used (0.85.5 to 0.85.10), but in my case it never freezes, only spins till i learn how to make it look forward again.

For now it happens in my dual core PC with Windows XP sp2. Have to check in others.

I never worried about it because i thought it was an issue with the mouse or with Windows' drivers. I also always thought that it happened too in other Quake engines and in other videogames, but now that you are saying that, Orl, i am beginning to doubt.
The more i think, the more i see that the issues i had with other videogames can be explained or are unrelated. Have to check the other Quake engines i currently use.