*sometimes the player gets stuck/stopped going down ramps/slopes

Do you have host_maxfps above 72?

Frames per second above 72 will cause physics problems in most Quake engines in single player.

[Main exceptions: DarkPlaces and the last couple of version of DirectQ because they have framerate independent server and therefore physics. No Quakeworld engine (like FTEQW) would have this issue either.] 

I'm not presuming to speak on behalf of the QS devs but I do feel that this needs to be said.

You really shouldn't be reporting many of these things as bugs. If you actually read the text, you'll see that most of them are just simple notifications that standard Quake map limits are exceeded (which is OK because QS can support the higher limits) or that MP3 music is unavailable for the map you're loading.

These are not bugs.

Now, it could be argued (and I have done so in the past) that they shouldn't be displayed to players, but that aside, reporting them as bugs is just wasting people's time.

Regarding z-fighting, it was already dealt with before, and z-fighting is a content bug, not an engine bug. Again, bringing up an issue that's already been dealt with, and doing so without adding anything new to the discussion, is also wasting people's time.

I could add something here about one of the reasons why I bailed out of engine development being terminal annoyance at constant badgering of this nature, but - oh wait, I already have. 

>Bugs
*Not sure if it's a bug or a limitation, but models with an internal skin taller than 480 cause qs to crash... because qme allows models to have skins with a max height of 512

@mh
Actually it is a bug: the maps, esp the second map, lag in qs as well as interfere with the player's weapon anim lerp (due to the lag/overflow etc)

I don't know enough about zfighting but i believed that it could be solved via modifications to the renderer?

@baker
my host_maxfps is 72 

Skins with max height of 480 is an original limitation of the engine. Width (as far as I know) has no limit though. 

why would a too-tall skin cause a crash? YOu'd think it would at least give an error message and quit to console, or even better, load it correctly but with a warning. 

Now, it could be argued (and I have done so in the past) that they shouldn't be displayed to players, but that aside, reporting them as bugs is just wasting people's time.

I see your perspective, but I felt that the warnings would be useless if they required Developer 1, since i don't think many mappers use that setting. 

Quakespasm 0.90 has worked great and I've lately enjoyed playing jam3_mfx among other cool maps. However, I came across a minor issue, which I think is a visual glitch.

There is a room in the said map with four bloodfalls and a gib fountain dropping gibs into the center of the room. Two of the bloodfalls show the other bloodfalls when viewed through them, but since they are not otherwise transparent this seems a little off. The other two are not seethru at all.

http://imgur.com/Cy8wvUT

Here is a reduced-size screenshot which shows four images in one. The top and bottom ones show this effect, and the middle two ones do not. These four pics are all from different sides of the room.

As usual, I'm asking whether this happens to other QS users. I am using QS 0.90 compiled on Linux64 using SDL2 from the source release. The cmd-line options were -game jam3 and -heapsize 70000 (because I don't like typing numbers with five significant figures...) 

I think that's the lack of depth-sorting transparent surfaces (FitzQuake does the same.) It's on my list of stuff to fix in qs at some point :-)

the same glitch is visible in the Rubicon pack in a few places (the entrance slipgate of telefragged, the exit of the credits map). 

Good example why fog should reset after each map: Jam 3 pack, playing Tronyn's level last. 

The issue of fog is that getting the right balance between what players expect and what mappers want isn't easy.

If a player sets fog from the console and if it's cleared on a map transition they will probably report it as a bug.

If a map doesn't include a fog key in it's worldspawn as a way of indicating "no fog here, please", but if fog persists between maps, then it's also a reportable bug.

Mix in mods that send svc_fog messages (or stuffcmd it - bleagh) during gameplay and you've a mess.

This is a classic case of a feature that fights itself. As an engine coder you just can't win, and no matter what you do (or if you just say "what a clusterfuck" and don't implement fog at all) you'll have someone pissed at you. 

fog should never have been a console option. wateralpha either, now I think about it.

But the feature was added before any mappers used it, so it didn't make sense at the time to make a feature that no one would see. I get it... but now players have a bizarre expectancy to be able to modify the way the map looks.

You wouldn't play Mass Effect and pull down the console so you could tweak the fog colour. 

Agreed. The map should dictate the fog settings. No other option really makes sense. If the player wants to change the fog AFTER the map sets it the way it wants it, then that's fine. But the map should dictate what it starts at. 

The bug was that on map changes, only the fog density was reset to 0. Now the rgb values are also reset to their defaults (0.3).

It's probably best to always specify all four density/r/g/b components in the worldspawn key; I just checked Darkplaces and jam3_tronyn.bsp gets black fog vs. gray in FitzQuake/QS. 

In principle I agree, but the doubt I have is that this is exactly what a mapper would say. Meantime a player can come along and make an equally forceful argument in favour of user control of everything. The trick is to take off your mapper hat and try to view it from the other perspective.

I need to clarify that I'm not necessarily arguing in favour of the other perspective here: like I said, in principle I agree.

In practice what would be nicer to see is an agreed way out of this that involves both parties being able to have what they want; a way that lets mappers set their preferred fog settings (which could be no fog), that also lets players (and I'm primarily thinking of those who like to sex-up their Quake here, not that I necessarily agree with that mindset) set a fog that will persist over map changes, but that has a mapper-specified fog override a player-specified fog.

The major stumbling block here seems to be the convention of "no fog key in worldspawn = no fog". 

Meantime a player can come along and make an equally forceful argument in favour of user control of everything. The trick is to take off your mapper hat and try to view it from the other perspective.

I'd be interested in hearing that equally forceful argument, because so far I'm pretty sure it doesn't exist. 

In principle I agree, but the doubt I have is that this is exactly what a mapper would say. Meantime a player can come along and make an equally forceful argument in favour of user control of everything. The trick is to take off your mapper hat and try to view it from the other perspective.

To this, I only ask what other game lets you go in and change things like skyboxes and fog that are integral to the look of the game.

If I ever release another map, I'll stuffcmd the fog and skybox every frame just to be a dick. :P 

A compromise proposal:

Fog has a "background state" which is only ever set by direct use of the fog cvar. The fog key in worldspawn is treated as a temporary override of the background state - once the map ends the background state is restored before the next map loads. Background state can be "no fog". If a fog command is issued during the map, this will not only produce an instantaneous change, but also update the background state to the given settings.

Result: on load, maps with fog keys look like the author intended. Maps without a fog key appear as the player sets fog by default (sober people: none, eyecandy freaks: lots).

Of course, info_command entities changing fog throw a spanner in the works. I can think of two unpleasant ways to work round that, but I will practice restraint and post neither... 

Does Requiem support BSP2? 

If you do what Preach suggests for fog, you should consider doing it for skyboxes as well. 

Cousin to the EULA, all maps and mods will be released from this point forward with "End User Mapper's Agreement".

Any player who changes a graphical or gameplay setting, config file or other game enhancing feature, excluding and limited to key bindings, will void said EUMA and have said map/mod removed!

Now we just need the Mappers to DRM their creations to enforce it... 

I always thought the fog and sky commands in Fitz/QS were a good balance between mapper control and player tweakability. Yes, they're reset on every map load to the worldspawn values (or if not set, the engine defaults). I like this because I can mess with fog and not have to worry about restoring it to the original value.

If there is really a demand for a way to control the fog of maps with none set in the worldspawn, maybe a dedicated "r_defaultfog" cvar would be the cleanest. But I have to say, I'm not a big fan of the idea, e.g. my jam3 map has no fog setting in the worldspawn; it's really intended to be played with no fog, not "whatever fog". 

"To this, I only ask what other game lets you go in and change things like skyboxes and fog that are integral to the look of the game."

Yeah, I agree. We don't allow anything else to be customized ... what's so special about fog? 

Is there anybody who seriously goes and changes the density and color of fog, just for the sake of extra eyecandy? 

Absolutely, checkout the stuff at quakeone.com and the various HD packs. 

Yes, but should that override the mappers intentions? I mean, fog isn't chosen for a map at random.