sure, i mean, i guess that makes sense. the problem is there's no way to know since the file is named the same thing. 

try the InspectExe tool (http://www.silurian.com/inspect/index.htm) 

My sound is lagging hard in the new build,I was just wondering if anyone else is having an issue? 

After having gotten sick of some of the issues I had with Darkplaces (stuff not spawning properly, doors not working, items floating in mid air), I made the switch to Quakespasm and have been pretty happy.
Still having some issues, not sure whether it's due to my n00biness as someone that doesn't really understand Quake tech that well, or the engine itself.
Recently tried to play the map pack, Digs01 again, which worked fine on Darkplaces.
Water and teleporter graphics wont show up at all.
I know you can get around that problem in Travail with +r_oldwater 0 +r_waterquality 32, but I have no idea if there's any command line that will fix the issue I'm having with Digs01.
I fear this may effect some other map packs too, but I haven't tried much others yet.

Also, the NightJourney map pack (http://www.quaddicted.com/reviews/nightjourney_v2.html), just wont work once you try to start a new game. Minus some errors with stuff. Says something about missing Lava/md2 model (I think that's what it said, I ended up deleting Nightjourney in frustration because it wouldn't work anymore lol), which is odd because I never encountered that issue with Darkplaces 

hate to ask a question like this, but is r_wateralpha set to 0? that'd make it not show up. 

I just tried using +r_wateralpha 1 and it works fine, so indeed just n00biness on my part.
Odd that +r_oldwater and +r_wateralpha are the same thing, damn quake and interchangeable command lines :P
The +r_oldwater command line was the suggestion made on the Travail site which makes the alphas work properly. Why that is, I don't know, but it works for Travail.
Just calling it +r_wateralpha would have made more sense.

Anyway, thanks for the help, Necros (although the help was in a rather roundabout way lol) 

r_oldwater has nothing at all to do with alpha.
r_oldwater 1 uses the original method of making the water texture warp. turning the option off uses a more expensive, but much nicer looking warping effect.
r_waterquality controls how good the warp looks, when using r_oldwater 0. 

r_oldwater 0 fixes up bad texture alignment for liquid brush seams. And too much water alpha may make a teleporter disappear. 

The problem is that sine waves don't linearly interpolate. r_oldwater 0 doesn't actually fix it correctly: what it does do is reduce the problem to an extent that it's not really as noticeable, but the tradeoff is that it imposes limits on the maximum size you can use for external textures. Doing the warp per-pixel in a shader is the only real way to definitively fix it in the general case. 

I guess there might be a situation that r_oldwater 0 makes it not as noticeable, but I've seen only perfect results so far. No complaints. 

same here. it looks fantastic and very authentic. 

It would be awesome if we could get a cmd/cvar to change the weapon models position on screen back to the vanilla placement instead of the "Darkplaces style". I think the engine is great and this is my only complaint. 

Version 0.85.5 of QuakeSpasm is released.

Merry Christmas and a happy new year to all. 

>deathmatch and coop cvar "fix" of Quakespasm 0.85.5

Although for sure that does not change the behavior of id1 progs.dat nor Quoth nor any other single player mod I know of, I am somewhat certain that change breaks the idea of cvar guided behavior in QuakeC. Cvar behavior is decided by QuakeC.

Since aguirRe is no longer around, well, his primary goal was mod compatibility and had deep knowledge of even obscure mods. Which I don't have. It may be possible that this change breaks some obscure or even not so non-obscure mods ... like ones with a lot of settings.

Then again maybe not.

DarkPlaces style weapons vs. Quake style

I conducted a deep and thorough investigation of this issue during the summer for Engine X. Engine X has an almost entirely unrestricted ability to resize the Quake window in real time like any other windows application.

I discovered some severe liabilities with DarkPlaces/FitzQuake style gun placement being hopelessly flawed with certain aspect ratios.

At the moment some of the work in DirectQ has the best current solution which has an FOV-immune gun placement possibly inspired by Qrack (which seems to have got it from possibly a Phoenix or QER tutorial).

I say best current solution because there is an additional factor involving FOV y, that is generally not a source of concern if you correct for a 4:3 aspect ratio, which for sure Qrack does (but the code is slightly less clean than applying it to FitzQuake, which simplified the FOV calculations).

At the risk of making this too wordy, the 4:3 aspect ratio is not always correct because some mods have side-mounted weapons (not center of screen) which may or may not have been designed with a 4:3 aspect ratio in mind and without taking in account the proper aspect ratio for the appearance of side mounted weapons they can disappear off-screen when not also incorporating the intended mod aspect ratio (!!).

Too much information, perhaps. But a complete and accurate description of factors into the presentation of the view weapon model. 

Are there really any mods that actually expect both to set at the same time? 

That's a better question for modders like at Inside3D. Most of the mods I've played either fall squarely into the traditional single player genre or into the deathmatch genre. There are all kinds of mods and most of them aren't really interesting to me http://www.quaketerminus.com/addon.shtml

A cursory Google search indicates that this mod is an example of a coop/deathmatch hybrid that uses both cvars

http://www.gamers.org/pub/idgames2/quakec/teamplay/sge10.txt

My only interest in raising the issue is that really Quakespasm is the closest to an "all operating systems" "proper Quake". 

I see. That "inder siege" thing is a weird one at that. I certainly would like to keep quakespasm as you descried, i.e. "all operating systems" "proper quake", however there is no universal solution to the coop/deathmatch thing as far as I can see.

The "cvar behavior is decided by quakec" argument is incorrect, because some vars are really set by quakec, however some need not be and are decided by the server admin. (And there must have been a way the quakec of that mod would be written using only one of the cvars set and not both.) Hmph... If you have a solution, I'm all ears. 

This is all theoretical at this point anyway, in practice I can't name I've ever used that used both cvars simulatenously and I checked DMSP, SuperCoop and a couple of the "bots mods".

I guess the reason I had thought of this is lately in some other engines that are not commonly used I've spotted some very mod-unfriendly optimizations and I've had compatibility on my mind lately.

Needless to say, I think some of the ideas implemented in Quakespasm have been very forward-thinking and conscientiously implemented. I loved (and adopted, heh) the Quakespasm philosophy on search path priority. Ingenious! 

Hmm, thought about this more, and I am convinced that that changed was unnecessary and reverted it in the svn as of rev.555: http://quakespasm.svn.sourceforge.net/viewvc/quakespasm?view=revision&revision=555

While messing with this, noticed another related thing: see http://www.inside3d.com/qip/home.shtml (search "Looks funny" on the page.) After this, not sure if the solution would affect anything..

As for the compliments for quakespasm: thanks! 

"Cvars "deathmatch" and "coop" not reset when loading a SinglePlayer game."

In function Host_Loadgame_f() of host_cmd.c, look for...
#ifdef QUAKE2
Cvar_SetValue ("deathmatch", 0);
Cvar_SetValue ("coop", 0);
Cvar_SetValue ("teamplay", 0);
#endif

DarkPlaces certainly doesn't have that "fix". DarkPlaces can save multiplayer games!

One of the biggest annoyances in coop ... let's say two people are playing, say, Travail or some single player deal that absolutely cannot be played non-stop in a reasonable period of time ...

How do you save and continue that game?

Well ... you don't. Because you can't. 

Well, that's not an answer but random sidetracking.

FWIW, hexen2 does reset those cvars when beginning to load because it also can save net games and it actually saves those vars along so they are restored to their intended states. Therefore hexen2 is immune to that funniness whereas quake is not. I don't know how dp handles the situation. 

I thought about bringing up that.

Quake's save game system is intended to save the state of the server.

And as you, it doesn't because it does not save the cvars. And this creates a real mess. Since server-side cvars belong to the QuakeC modder, any given one could be used or abused in a mod. Some mods use cvars in unexpected ways or use them for "inter-level storage" or for hacks and so forth.

Any attempt to "solve" the problem is likely to break something, any attempt to alter the behavior is likely to break something.

One idea is to make and/or propose a save game 1.10 format or just do it. Some people might say "your engine save game files cannot be read by <my favorite quake engine>", but that is mighty uncommon. [Can save files fail in other engines gracefully based on version? I have not checked ...]

Although I have absorbed quite a bit of information in 5 years of paying attention to these kinds of things, my level of experience on the technical aspects of these matters is way below a metlslime, FrikaC, Necros, Spike, MH, leileilol type of 15-year expert. 

One of the more fun aspects of engine development is the freedom to fix/correct/enhance/play around without regard to exact compatibility.

DarkPlaces is an example of an engine that doesn't worry about breaking things versus, say, FitzQuake which is so conservative as to require typing +mlook in the console for mouse look.

This isn't the golden heyday of Quake and most of the mods that would get broke by "fixing" stuff probably rarely get played.

JoeQuake did this by stating that the engine was intended for use with id1 Quake and the 2 mission packs.

If you want to stick with the mainstream use of engines like id1, Quoth, Warpspasm, Mission Packs and DMSP/Frikbot kind of stuff ... do it.

An engine being developed is more important than a few oddball mods from 14 years ago that no one uses. Besides, that's what bug reports are for.

I might have too much influence from aguirRe and Spirit, aguirRe was very big on compatibility and assisted me a lot when I started engine coding and more or less kept me from breaking standard behavior on accident. 

...It's quite possible that RMQ is going to require an extended save game format shortly. One issue we've definitely encountered is use of "stuffcmd" to set some cvars and other things (like v_cshift) which are not being retained across sessions (or are being retained when they shouldn't be if the player changes or reloads the map). That's probably something more appropriate for a fuller discussion on I3D but I think it would be a good idea to at least co-ordinate efforts as this is a common enough problem with mods in general. 

can get around that easily with unsaved variables which you can use to force a cshift check on loading maps.
for loading new games, just put a catch all in putClientInServer or something.
in an older mod (which i lost) i was storing cshift in a .vector and .float on the player (rgb + intensity).
this allowed me to blend multiple colour shifts together and then use normalize on the rgb vector to keep things for washing out.