How Do I Apply These Commands?
Do I put these commands into the autoexec.cfg file?
Currently, I use this:
Doesn't Work Yet...
I used the following in my autoexec.cfg file:
I also tried adding 1 after gl_linear_mipmap_linear. But the map is still rendered with huge sharp blocky pixels.
Small Pak File To Add?
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.
Yep! Working Great Now.
It Doesn't Work For All Mods...
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?
In Those Mods
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.
It's Working From The Console While In Game...
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.
I Don't Have This In The Read Me Of Shadow...
maybe I have an older version.
Version Updated But...
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):
Best just go on discord and ping the modders for an answer.
What About Sock's Shadow And Its Textures?
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.
Preventing A Mod From Overriding A Setting
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:
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!
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.