Do any other Quake engines allow fancy binding of key combos?
FTE allows you to bind alt+m "echo ALT+M was pressed"
(ctrl+alt+shift modifiers and variations thereof are supported. Note that if you use a key as a modifier then you should probably not bind it to something else at the same time - it'll work, you'll just get unwanted binds.)

A workaround for DP would be to write some csqc that looks for modifier keys and then reconfigures DP's bindmaps, which isn't user friendly for multiple reasons. 

Yes, confirmed that MarkV has Alt-M hard-coded to toggling mute on/off.

Other hard-coded key combos:

Alt-Enter: switch between fullscreen and windows.

Alt-Tab: switch between different applications on the OS.

Ctrl-C: Copy.

Ctrl-V: Paste. 

That FTE functionality wold be something really (really) good to import.


I hadn't thought about those other hard-coded combos, since they are standardized Windows behaviors.... so they behave as most people would already expect.

I suppose you don't need to have CTRL+C and CTRL+V function when the console isn't down though. Those would be the only other combos I would think that might potentially interfere with something someone might bind. Few people are going to mess with the TAB or ENTER key, since they already have commonly-used functions in Quake (scoreboard and entering messages or menu navigation).


On the subject of Mute, if I use my media keys on my keyboard to change system volume or mute, it causes a little display window to pop up on screen notifying me of whatever I changed, and that causes Quake to minimize. I wonder if there's a way for Quake to ... not be forced to minimize in this situation.... 

Huh, well, I'm testing it again today and my media keys aren't forcing Quake to minimize.... Well, not consistently. The first time I tried it, Quake minimized but then it restored itself. After that (even after closing and restarting Quake) it doesn't minimize at all, and the overlay flickers in front or Quake for a moment.

So I don't know. It's inconsistent. Probably a Windows thing. 

On the subject of Copy/Paste, I guess even if the console isn't down, you'd want CTRL+V to function if someone was entering a chat message too.

I have often wanted to Copy test from the console, but you can only select text from the line you are currently typing on (by using shift + left/right), but that's never what I want to do. There should be some way to select text that has already been printed in the console, either with mouse select or by pressing shift+up to select previous console lines.

I end up having to use the "copy" command, which copies the entire console contents. 

Source code only contains project files for building on Windows. No makefile, cmake, etc. 

There's a project file for codeblocks. 

Would there be a way to have more that just three cycling autodemos? I test a lot of maps for newbs and like to use Mark V's cl_autodemo. But much of the time I die a lot! Which obv overwrites the dems.

I know I asked for the map name to be added before, I figured heck why not ask for this too. 

Hey guys!

Animations of Weapons and Super nailgun in particular still look choppy when firing, though these cvars are enabled :

r_lerpmodels "1"
r_lerpmove "1"

How to make 'em smooth like in DirectQ, for instance? 

Animations of Weapons and Super nailgun in particular still look choppy when firing ... How to make 'em smooth like in DirectQ, for instance?

This is a content issue.

FitzQuake (which both Quakespasm and MArkV are derived from) works around it in one way, DirectQ works around it in a different way, and both ways have their pros, cons and trade-offs.

First of all, the issue.

The Quake weapon models have polygons for the muzzle flash animation embedded in them, and when the gun fires the flash polygons are moved into the correct position.

When interpolation is switched on, what this causes is for these polygons to move with interpolation, which causes them to swim into view, and dance back-and-forth across the space between the nailgun barrels.

FitzQuake and derivatives work around this by temporarily switching off interpolation if the gun is in a muzzle flash state.

DirectQ works around it by measuring the delta between vertices in the two frames to be interpolated, and if the delta is sufficiently large (above some arbitrary value that was tweaked until it gave the correct result) assume a muzzle flash motion and don't lerp, on a per-vertex basis.

DirectQ used vertex shaders for everything so it could do this quickly and easily, and it really wasn't much more than an extension of the same kind of thinking as the "assume a teleport and don't lerp" check elsewhere in the engine. It should be obvious that this approach is vulnerable to both false positives and false negatives, however.

The correct way to fix this is new content. A set of weapon models that don't include the flash polygons, a separate generic muzzle-flash model, and the QC code to stitch them together.

Meanwhile, FitzQuake allowed disabling it's behaviour by setting r_lerpmodels to 2 - not sure if MarkV and QS do likewise. 

Big thanks for an explanation MH !

"r_lerpmodels 2" works just as intended in Mark V either :)

I've actually wanted to ask you a DirectQ related question since 2013 but was unable to contact you.

You've probably been informed about "sinking into ground" bug that occurs after about an hour of playing in DirectQ. Most of the corpses around the map blow up and the player starts sinking into ground. The only way to solve an issue (temporarily) was to save a game, restart the engine and load it again. I've wondered since then, has there ever been a solution found for eleminating this nasty issue or not? As it is the only major problem I found while playing DirectQ. That source port satisfied me in every aspect of gameplay and gave a really nice old-fashioned feeling of quake experience.

I was running v1.9.0 

You've probably been informed about "sinking into ground" bug that occurs after about an hour of playing in DirectQ...

I fucked-up the physics code somewhere, but never was able to determine where. 

Yeah... it's a pity.

Apart from that terrible bug, DirectQ is still great

:) 

startdemos demo1 demo2 demo3 demo3 etc up to 32 demos
or edit your autoexec.cfg and add :

demos demo1 demo2 demo3 demo4 demo5 demo6 demo7 etc.. 

startdemos assigns the order demos is the console command to skip to the next one in sequence.
so just use startdemos either in the .cfg or console 

I wasn't too clear in my request.

Currently Mark V records 3 autodemos per session: autodemo_0, 1 & 2. If I die a 4th time (happens too often!) autodemo_0 will start from that point in the game, erasing my prior demos. What I'd like is to just keep recording demos 3, 4, 5 and so on.

And would love to have the demo be named the same as the mapname. So e1m3_0, e1m3_1 and so on. 

@Andrew,

I have a set of view models that someone fixed to work better with interpolation, by hiding the muzzle flash under the gun between the frames where it should appear, so it don't look as weird when fully interpolated. This doesn't make it look perfect (there is still some small movements visible), but it is a definite improvement (most notably for the standard nailgun).

I have no idea where I got these.... I've had them for many years.

http://fvfonline.com/vmodels.zip


Uhh, to use those in Mark V, you'll have to make a mod folder and put them in a "progs" folder in there, and run that game folder (but then they'll only work when you run using that game folder), or go to the hassle of sticking them in an extra pak file to drop in your id1 folder so they will always be used... which I'm sure is what you want.

This is a overly-difficult because Baker doesn't have Mark V (like the other advanced Quake engines) give preference to user-inserted drop-in content outside of pak files. But it really should do that, for reasons such as this! ;) 

Qrack has cl_autodemo which names demos automatically.
using mapname_date_time as the filename.
cl_autodemo 1 starts recording at mapload and stops at intermission.
Qrack also has bsp2 support with protocol 666 so it will load any map that markv can load.
http://quakeone.com/qrack if that helps for the time being 

Downloaded - will play with it for sure. Looks like you are still updating this regularly. I wasn't aware. 

let me know if there are any config issues i can
help you set it up. 

Version 1.2 of his pack here: https://drive.google.com/open?id=0B9DxOfPvG2G1YmNPUmRFMDV4YU0 

Thank you, mate :)

I will surely give it a try. 

MH wrote a nifty ‘hack’ to remove muzzle flash polygons
from the original models.
look for gl_clip_muzzleflash here in gl_mesh
https://github.com/sputnikutah/Qrack/blob/master/gl_mesh.c 

This hack, IIRC, is pretty much what I described above. It's a good few years ago so I don't remember details, but I'm pretty certain it uses the same logic.