is your autoexec.cfg in your id1 folder?

Yes it is. It exec's it but no change...

It might be worth checking to ensure that there are no competing config/autoexec files in different parts of your quake file structure. Sometimes if you run with a -game xyz, to play/activate a mod for example, you can sometimes find that there can be more than one config.cfg (e.g. in id1 and in the game folder) which can produce unexpected results similar to those you have described

Conversely, to try keep your config files seperate you could create a folder called something like proquake, put your desired config in it, and run quake with -game proquake in the command line. It's not always desirable but it works well for me

It may also be that the autoexec and config files might be competing with each other so it's worth checking one against the other.

Another thought, I know some mods such as FVF changed bindings without permission on my system. And there may also be a slim possibility of unscrupulous server admins changing bindings on your client.

Just a few thoughts, hope one or more help you out

Kind regards

Monty

There is only glquake.exe and there is only id1 folder and only once config.cfg. I added autoexec later since config.cfg wasn't working by itself. However, there are configs in missionpacks. I'll try to remove every possible cfg except one in id1.

Is there any way to force -no8bit with config so I could launch the game thru exe itself?

OK, removing all other configs (dunno which one was the culprit) from missionpacks and running the game with only -no8bit -width 1920 -bpp 32 loads the config normally.

Thanks for pointing me into the right direction, although it was a config in NOT id1 folder obviously that caused trouble...

I'm glad it helped you out

Glad you got it squared away. But just in case the cfg file structure is still unclear, here's a brief explanation of what I had to learn when building a mod. Let's pretend our base directory is this:

C:\GLQuake

Within the GLQuake folder, we have the game executable, an id1 folder, and a folder for a mission pack ("armagon" for example). Keep in mind that a mission pack is simply a mod made by a "professional" company (there are a few fan-made mods that greatly exceed the quality of the mission packs).

The config and autoexec files within your id1 folder will ALWAYS compile, unless they are non-existant. In these files, you should input commands/bindings that you never plan to change. These are your base files. Any exec files after these will overwrite the commands in these ones.

Often, a mod will come packaged with its own config.cfg and autoexec.cfg (and maybe even a few other .cfg files, they don't have to be called config and autoexec if the mod is coded to exec them). The mission packs likely do. These cfg files will likely contain commands/bindings that the mod creator found convenient and improved gameplay on his/her mod. As a modder, they are responsible for providing documentation in their readme about their custom bindings and cvars. As a player, it is your responsibility to read the readme and decide whether or not you like the settings the mod creator has placed in his custom cfg files. Any cfg files within the mod directory will overwrite previous bindings/cvars set within the id1 folder cfg files. This includes the mission packs, which seems to have been your problem.

To wrap it up, you don't need to delete cfg files within mods. It can be convenient having bindings/settings for your favorite mods that are meant for that respective mod alone. You just need to make sure to edit them so that they don't conflict.

There should only be conflicting cfg files, however, if you are running the mod. Otherwise, only the cfg files in id1 are being read, so there should be no problem. Are your cfg files for the mission packs located within the mission pack folders? So, for example, the cfg files for "armagon" should be within this directory:

C:\GLQuake\Armagon

and not simply in the GLQuake folder or the id1 folder.

I hope this helps a bit. Having multiple cfg files that are called on for different mods/mission packs is very convenient, but you have to make sure they are all properly placed within their respective directories, or else you will get unpredictable results.

Each cfg was in it's respective folder, and I was running glquake from main Quake directory (no configs there), not id1 directory (where it's config is stored.)

Why the game chose one of the other configs from mission packs is unknown to me. I have every other config now as config.cfg.bak, so when I go play a mission pack I'll just .bak the id1 config and edit mission pack's config to my liking.

Thanks.

Sounds like you had it. That's really weird it still didn't work. I would have to really dig into it to figure it out at this point, but it sounds like you have it running smoothly now so I wouldn't touch it!

use a modern client/engine ; 99% of your problems get solved.

Frankly, I want it old school as much as possible.

Only ones that fit under that definition is Enhanced Quake and ProQuake (which contains Enhanced AFAIK), but both of them come optimized for multi player (shadows off, interpolation off, water off - they behave like winquake, not glquake) etc. Others seem way too "new".

Plus, it's no hassle to play pure glquake

It was because you were using the -game switch.That one makes it look for a mod folder OTHER than ID.No idea why it chose another cfg but it did.
For a no8 try -width -height -16bpp or -32bpp.Good luck.

That was going to be my next guess.

I'm not gonna try to replicate now, but later I think was running glquake.exe width bpp no8bit without -game...

But I solved it, thanks guys.