autodemo -- pulsar, I'll spend some time thinking about right way to handle to.

sound 44000 - bloughsburg, I remember some of the sound mixing discussions about that. I'm adding that to my list and will eventually happen.

@fifth - Not sure what you are wanting. Quake physics are still 72 fps and although fps independent physics is on my eventual to-do list. If you set 144 hz in your video card and vid_vsync 1 and host_maxfps 144 in the console, do things work as expected?

@gunter - at a higher fps, the demo files could become huge. Maybe make cl_autodemo 2 option -- record an autodemo regardless of the fps. gun fov 90 -- people love the feature, you know how to disable it.

@nightfright - at least for now, Mark V is a pure Open GL 1.2 engine for maximum hardware compatibility for any machine Windows XP or higher. MH needed a glsl for that in Remake Quake engine.

The track by mapname thing, I will think about and have an idea on a "correct solution" which would give you the same ability to control it but does not work in a way similar to what to you suggest, but I would need to put some thought into it so is more likely a future version item.

@nightfright part 2 ---

I'd recommend creating a Wiki page at https://quakewiki.org/wiki/Main_Page listing extra replacement content paks and I'll put a link to that page on the Mark V page -- that way if new content becomes available it can be updated and available to users without me continually editing the Mark V homepage.

Be sure to upload mod enhancements to Quaketastic (see Func screenshots thread for username, password if you don't already know) beause Quaketastic files are preserved forever at the Amazon/Government funded archive.org site (!!)

/I think that's most of the replies, I read Spike's thoughts on gamedir change and @snaut yeah that's cool. 

I've always thought that the engine ought to be able to cap the framerate of the demo independently of the actual client framerate -- When I recorded demos for rubicon 2 I intentionally set host_maxfps really low to get a smaller demo file, but it would be nice if it was an automatic feature.

But, I never did the research into what kind of problems would have to be dealt with to make the demo playback correctly. For example obviously the dropped frames might have important events in them, you'd need to save them and put them in the next demo frame so they are not lost. 

Spike actually has a separate thread (or similar) in FTE to ensure 72 fps even if the client goes under 72 fps.

In 2014, I made a run at acquiring DirectQ's fps independent framerate, but noticed a little jerk in DirectQ when using +turnleft and +forward at same time -- so I moved it to the back of the queue for future consideration. 

I suspect Spike might suggest that the best to get such a result might be having the "server" record the demo instead of the "client" --- in a properly client/server separated engine (like how the Quakeworld engines have complete client/server separation). 

Never knew it affected demo filesize. I always play at 144 fps and never noticed any bugs 

two things:
1) use a decent network protocol that doesn't resend everything every single packet. get AD's particles under control by harassing sock into using clientside stuff instead of network abuse.
2) screw threads, just don't send packets to the server quite so often. from what I remember the only real challenge is figuring out how to deal with impulse;wait;impulse scripts. one way is to just not wake up from waits while connected with an impulse still pending. obviously if there's any hacks internally directly linking both client+server then you'll need to fix them, otherwise independant rendering/server isn't really any different from a public server or demo. drop the server's rate to 10hz and you'll get quake2! 

Yes to all of that ;-)

Btw, offhand do you know about about the bloughsburg/zbikey sound crackle @ 44 hz. I don't touch the sound mixer often -- and such a conversation wasn't recent so I can't recall the details immediatelly. Is that the true hz is 48k issue? 

@spike also -- while I'm thinking about this -- your single port rewire of reading messages -- I haven't investigated so is probably non-issue, but in my head I was thinking "make sure that can't skip a player impulse". I think QSS queues up +jump and such.

/Again, haven't had time to focused on deep examination of that, so quite possible I'd see something obvious that I'm not thinking of at the moment. 

I have no audio crackling / distortion, everything sounds fine for me.

Those who are having glitched audio, might help track down the problem if you type 'condump', and paste this section from your id1/condump.txt:
Sound Initialization
Set primary sound buffer format: yes
Using secondary sound buffer
2 channel(s)
16 bits/sample
11025 bytes/sec
DirectSound initialized
Audio: 16 bit, stereo, 11025 Hz
Sound sampling rate: 11025

Also - congrats on the release, Baker :) 

Thanks ericw! At more than one point, didn't think it would ever happen. 

qss's single-socket stuff just switches from looping through each connection and then handling the messages to checking the socket(s - ipv4+ipv6+ipx) and then parsing them within the context of the player with the same remote address.
there's no extra buffering there that wasn't already there, certainly not in the client-side stuff. inputs are handled the same way as they always were.

if you're getting crackles mid-sound then rewrite your resampler. resampling 44->48khz will probably screw up the waveform if you have 44khz frequencies. most people can't hear those anyway.
be aware that the vanilla resampler uses 'nearest filtering', which has somewhat obvious deficiencies...
on the other hand, pops when you override another sound could be fixed with a gradual fade-out instead of suddenly dropping down to 0. 

Count me as another person who is very glad this release happened, and it happened now instead of later in 2017!


"gun fov 90 -- people love the feature"

Well, people love lots of things, but that doesn't mean Quake's default should change, heh. I mean, lots of people probably love r_viewmodel_ring 1, but it's defaulted off....

From looking at the old thread, the people who are using r_viewmodel_fov are not using your default value anyway.... They are using 110 or 130.

And of course, they are using it when setting a higher fov. It's good for that. I like it for that too. Too bad it doesn't work ONLY for that.... Lower fov's make it weird.

So yeah, I'll disable it. I have a section in my fitzquake.cfg file for "Restore Quake Defaults." The section is actually not too long (about 7 behaviors), which is a very good thing. But I'd be more happy if it was completely unnecessary to restore any Quake defaults!

Now, it's not always bad to change a default, but you have to be certain there is definitely no negative impact from the change.

For example, I couldn't see any negative impact of defaulting r_viewmodel_ring 1. It's a cool setting, and everyone should use it... but I would never actually argue for making it a default... because it's not Quake's default! Heh. But of course, I would't mind if it was made default either, unless some unforeseen negative impact arose.

Of course, sometimes the "negative impact" is simply that it doesn't look the way people are used to, and they don't like that... sooo... in the end (as you say), you gotta be really conservative about changing defaults. Err on the side of caution. 

In this engine, one thing I've tried to do is absorb as much of the feature set from other engines with great contributions that aren't developed any longer like Enhanced GLQuake/WinQuake, ProQuake, JoeQuake.

But it is currently lacking one of the most prominent features of JoeQuake as an option (will off by default), which are the optional particle effects system (QMB particle system by Dr. Labman).

It'll need some rigorous testing when it's available in a few hours. 

Rigorous is my middle name.


Well, not literally. That would require some really weird parents.... 

Here you go! This is with me changing sndspeed to 44100

Sound Initialization
Set primary sound buffer format: yes
Using secondary sound buffer
2 channel(s)
16 bits/sample
44100 bytes/sec
DirectSound initialized
Audio: 16 bit, stereo, 44100 Hz
Sound sampling rate: 44100 

Oops, and here is QS:

Sound Initialization
SDL audio spec : 44100 Hz, 1024 samples, 2 channels
SDL audio driver: dsound, 65536 bytes buffer
Audio: 16 bit, stereo, 44100 Hz 

Is there any feature left in ProQuake still that hasn't been subsumed by Mark V? 

I'm just going off current memory.

ProQuake + JoeQuake in Mark V
------------------
1) Ping in scoreboard.
2) ProQuake enhanced client
3) ProQuake enhanced server *limited* to Spiked Quakespasm levels due to acquiring QSS single port server capability.
4) ProQuake 16-bit aim available under protocol 15. (Spiked Quakespasm has this too).

ProQuake
--------
1) Mark V downloads depot http download missing maps, sounds, models when connected to ProQuake or DarkPlaces server, but not when a Mark V server or Spiked Quakespasm server.

(* because Mark V is likely to have in the future peer-to-peer TCP/IP transfer of "gamepacks" -- think "travail.zip" due to conversations with Spike on how to do download right. On a LAN in particular, transferring "travail.zip" (83 MB) happens in the blink of an eye. Since Spike has already written .pk3 support for QSS, and since .zip and .pk3 are same thing ... it is also likely in future Mark V will never decompress a Quaddicted download at all.)

And has all other ProQuake features except ..

2) Does not have ProQuake iplogging (check to see someone if someone is imposter). Not compatible with IPv6.
3) Cannot run ProQuake QCCX mods.
4) Typing matrix in console displays a Matrix movie full screen character effect.

JoeQuake
--------
1) Mark V has .dz playback built-in even on Mac, does not require any extra dzip.exe or anything. (Speed Demos Archive speed runs)
2) Mark V Has scr_showspeed - display speed on screen.
3) Will have QMB particle system tonight
4) Doesn't have cl_bobbing (items can bounce up and down)

Enhanced GLQuake/WinQuake
-------------------------
1) Mark V should be able to play Q-Rally with sv_gameplayfix_setmodelrealbox 0. Maybe other rare (Spike says poorly coded) old stuff that needs it.
2) Mark V can read protocol 10002, allowing Mark V to play Warpspasm start demos.
3) Mark V, developer 2 displays extra warnings from that engine.
4) Mark V does not support 32 or 64 player scoreboard.
5) Mark V does support sprite32, even in WinQuake version.
6) Obv, Mark V can play Nehahra.
7) Mark V, unlike other FitzQuake forks except Spiked Quakespasm, can serve protocol 15 game. 

I really like the manipulation of console variables via mul, valsave, valload....

Here are my newly Mark V-enhanced zoom aliases, for anyone who wants to try them.

The mouse wheel zoom is my favorite -- you can zoom in and out to different levels (even out to chase mode) with the mouse wheel. I've used it for a long time, but now it is better due to being able to save any fov before messing with it, and use math to change the sensitivity. If someone wanted to expand on this, you could make even more zoom steps, or even more zoom steps backward in chase mode with chase_back values.

(to use these, you'd want to paste them in a .cfg file to exec)


// mouse wheel zoom

alias zoom_out_full "mul sensitivity 2; bind mwheelup zoom_in_half; bind mwheeldown zoom_back; fov 50;wait;fov 70;wait;valload fov 1"
alias zoom_out_half "mul sensitivity 2; bind mwheelup zoom_in_full; bind mwheeldown zoom_out_full; fov 20;wait;fov 30"

alias zoom_in_half "mul sensitivity 0.5; bind mwheelup zoom_in_full; bind mwheeldown zoom_out_full; valsave fov 1;fov 70;wait;fov 50;wait;fov 30"
alias zoom_in_full "mul sensitivity 0.5; bind mwheelup wait; bind mwheeldown zoom_out_half; fov 20;wait;fov 10"

alias zoom_back "chase_active 1; bind mwheelup zoom_standard; bind mwheeldown wait"
alias zoom_standard "chase_active 0; bind mwheelup zoom_in_half; bind mwheeldown zoom_back"

zoom_standard




Here is a single-key solution that still allows different zoom levels. Sometimes you may not want to zoom in ALL the way, right up the monster's nose. With this you get an alternating zoom level each time you press the key.


// single-key multi zoom

alias rekey1 "bind r +zoom1"
alias rekey2 "bind r +zoom2"
alias +zoom1 "mul sensitivity 0.5; valsave fov 1; fov 70;wait;fov 50;wait;fov 30"
alias -zoom1 "mul sensitivity 2; fov 50;wait;fov 70;wait;valload fov 1; rekey2"
alias +zoom2 "mul sensitivity 0.25; fov 70;wait;fov 50;wait;fov 30;wait;fov 20;wait;fov 10"
alias -zoom2 "mul sensitivity 4; fov 20;wait;fov 30;wait;fov 50;wait;fov 70;wait;valload fov 1; rekey1"

rekey1





Baker, your +zoom_key alias is rather non-optimized. There is no need to change the sensitivity with each step of the zoom (it all happens so fast, only the beginning and end sensitivity matters). And actually there's no need to save and load the sensitivity value at all -- you can just use the math to change it and restore it (X * 0.1 * 10 = original value).

And there's really no need to use math on the fov for each middle step of the zoom either -- those steps are just there to provide an animation for the zoom effect, so they work fine at set values. Again, only the beginning and end values are important.

So if I may, this would be a much cleaner, optimized version of your +zoom_key:

alias +zoom_key "valsave fov 1; valsave r_viewmodel_fov 3; r_viewmodel_fov 0; mul sensitivity 0.1; fov 70; wait; fov 50; wait; fov 30; wait; fov 20; wait; fov 10"

alias -zoom_key "fov 20; wait; fov 30; wait; fov 50; wait; fov 70; wait; valload fov 1; valload r_viewmodel_fov 3; mul sensitivity 10" 

1) Mark V does have ProQuake/JoeQuake/DarkPlaces bestweapon command .. bind x "bestweapon 8 5 4 3 2 1" ... will select best gun with ammo available.

2) Does not support pq_moveup (swim up as fast +moveup).

3) No ProQuake 4.93 server browser pressing F5, but instead Spiked Quakespasm server browser.

/Shorter version: For various reasons, Mark V won't likely appeal to most ProQuake users and almost all of them would probably stick with ProQuake because they aren't playing new single player releases and most probably only play dm3 24/7/365 or the start map or e1m7 in RuneQuake. 

Malice has items that modify the player's speed. One of them allows the player to go as fast as 600. Features of this kind are realized by modifying client settings (like cl_forwardspeed) every time an item is activated or deactivated, which leads to problems with savegames.

Perhaps what's more important is the way the mod sets sv_maxspeed to 600. I don't know why, but it does that at the beginning of each level, but not at the game startup. The symptom is: starting Malice and loading a savegame gets you a standart speed cap if 320.

My limited understanding suggests that an engine-side solution to a problem of this kind won't be pretty, but I thought I'd mention these anyway. 

Yeah, that isn't related to Mark V as I think you know.

They could have benefited from some of the things Preach has Quoth do upon save/load, but Quake was new and no one developed Preach's Quoth trickeries.

/Quake's save games don't actually save enough information. And never have. 

Capslock key not bindable? ("not a valid key")

Can it be?

I guess you might have to disable its standard function so that it's not actually setting Caps Lock every time someone used it. Just do that if it's actually bound, but if not, let it be standard Caps Lock.... Or just disable it completely. Who needs Caps Lock in Quake?

Hm, looks like Proquake just disables it... but... still won't let me bind it as a key ? 

A thoughtful response 

Oh. Why is that? Is the CapsLock key just something Quake can't handle? I thought with all your extra keyboard code, it wouldn't be a problem.

It's a shame to have an unusable key right there next to WASD, where everyone's hand will be.