gl_texture_anisotropy 16 

Do I put these commands into the autoexec.cfg file?

Currently, I use this:

r_shadows 1
gl_polyblend 0
gl_flashblend 0
r_particledesc effectinfo 

I used the following in my autoexec.cfg file:

r_shadows 1
gl_polyblend 0
gl_flashblend 0
r_particledesc effectinfo
gl_linear_mipmap_linear
gl_texture_anisotropy 16
map ivory

I also tried adding 1 after gl_linear_mipmap_linear. But the map is still rendered with huge sharp blocky pixels. 

If I remember well, I believe that Sock hardwired the blocky sharp pixels into his pak file on purpose in his old mods (I'm pretty sure of that). To make the pixels behaving in the default way (blurry rendering on close range), I think we need to add a small pak file that was published on this site, several years ago. I'm unable to find back that file.

Maybe I'm wrong and there's another way. 

gl_texturemode gl_linear_mipmap_linear 

Thanks otp. 

Mods "In The Shadow" (from Sock) and "Rubicon 3" still have large blocky pixels. I don't understand what is going on here, since these mods have the same apparent structures as other mods (a single pak0.pak file).

The previous commands are working for some other mods from Sock (ivory, mstalk, Zendar). But why not for Shadow and Rubicon 3? 

try changing the value mid-game via the console

if that doesn't work, maybe the mod is spamming the command every frame? that wouldn't be without precedent. 

Kinn, yes what you suggest is working. But then how can I make it permanent? 

read the manual

the shadows mod says "Impulse 247 - Toggle texture filtering on/off" in it's readme. 

maybe I have an older version. 

Okay, I've updated the version of Shadow. Impulse 247 works, but only once in the console from mid game. It doesn't work permanently from the autoexec.cfg file. What gives? 

It's a pack for Rubicon 2. 

Strange, the version I have is newer (2016) than the version on qquaddicted (2014):

https://www.quaddicted.com/reviews/rrp.html 

Best just go on discord and ping the modders for an answer. 

impulse 247 works from the console, but not from the autoexec file nor from the config.cfg file neither. I wonder how to make it permanent. 

I was going to say that if the mod is forcibly setting gl_texturemode via its progs.dat (which appears to be the case with In the Shadows), that you might be out of luck ... but then I thought of a cute trick to prevent mods doing this sort of thing. Barnak, try putting this in your autoexec.cfg file:

gl_texturemode GL_LINEAR_MIPMAP_LINEAR
alias gl_texturemode ""

(The second line ends with a space followed by two double-quote characters.) 

iw, this works perfectly, for both Shadow and Rubicon 3.

Yhis is black magic, man! 

More voodoo from iw! 

I love this. 

Nice - that could be used to cock with so many things. I love it.

Now, what could I alias "bf" to? 

This got my mind racing with all sorts of wonderfully horrible things which "bf" could be redefined to do! But alas, it seems it's not to be. "alias bf whatever" has no effect.

From consulting the engine source, it turns out that there are three levels of precedence for console commands:

(1) "function" commands, like "bf" or "echo" or "map";

(2) aliases defined by the user;

(3) cvars, like "gl_texturemode".

Function commands take precedence over aliases, and aliases take precedence over cvars. So we can use an alias to redefine "gl_texturemode", but not "bf". And the world is a sadder place to be as a result.

FWIW, what I wanted to do was:

alias bf "skill 3; changelevel e4m6"

I was already trying to think whehter it would still be possible to finish the game with this in effect. 

In vanilla Quake, aliases have the lowest precedence priority (they don't overwrite any internal cvars or commands). I used that to make config files that are compatible with both PC and Dreamcast ports (returning no "unknown command" messages).

Darkplaces inverted that, allowing aliases to overwrite anything. 

mankrip, for my comments about precedence in #24 I was looking at the vanilla Quake source code. I don't use DarkPlaces.

In Cmd_ExecuteString() in cmd.c, the first word of the command line is checked first against function commands, then aliases, then cvars. So it looks like aliases would override cvars even in vanilla Quake. They certainly do in QuakeSpasm 0.93.1, in which Cmd_ExecuteString() looks essentially unchanged. Unless I'm overlooking something? 

You're right, I just verified it.

I still remember it working in that other way, maybe it's a QuakeDC quirk.