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. 

Joking around aside, I spent quite a bit of time studying input API on various systems and in Windows. And with system methods and SDL input methods.

Caps Lock is a real PITA in a number of the above scenarios.

I don't want the input code as a nightmare when I go to do Mac or Linux, so I don't want any differences in the keys behaviors.

An analogy:

Mark V's GL and WinQuake and Direct3D builds are a breeze to maintain because it's common code for about everything.

... Unlike what original Quake did where they were very separate.

By having unified input code (which is tough) ... when I finally do Linux, for instance, I won't have to deal with a lot of irregularities. 

Well, Grumpy Cat makes any thread better.

One last report, then I retire to my crypt for the night.

scr_sbaralpha got borked at some point.

In DX, it just doesn't make the HUD transparent at all.

In GL, it does make the HUD transparent, but if the value is below 0.7, the console background becomes invisible.



I've been looking through the "find all" list. I notice pq_fullpitch is in there as "external server hint." Is that just so you don't get errant messages like "unknown command pq_fullpitch" when you connect to a server that makes the setting?

If that's the case.... When I connect to the FvF Proquake server, I get "unknown command cl_fullpitch." So could cl_fullpitch be added in there too? Very minor issue, really.... But It looks like Proquake has both those commands. 

I noticed the external texture sbar alpha thing with the dx build when I was trying to unravel your dx8 issue. The invisible HUD below 0.7 is probably due to alpha masking test 0.666 in FitzQuake. And cl_fullpitch thing bothers me some. I'll eventually address all 3 of those small little oddities. 

In Shrak v2.0, they also fixed an issue in vanilla Quake, and I am not sure if it is fixed in Mark V. From the Shrak readme:

"id included sounds for unlocking the door as well as the normal 'door opening' sound. But because the unlocking and the opening happened at exactly the same time, you never heard the unlocking sound." 

This probably got lost in the old thread, but it's perfectly possible to do in GL 1.2 and no shaders needed.

Draw the regular 3D view.

glCopyTex(Sub)Image it to a texture.

Then draw that texture back using a grid with warps at the vertices.

This is similar to stock Fitz/QS "framebuffer water warp" but kind of in reverse. It should even be possible to reuse much of the code, maybe tweaking some parameters.

Of course the larger texture size needed for this implies a higher GL version, but that never stopped people with external textures or skyboxes.

You can also hack something up by playing around with the projection matrix. In addition to the FQ stretch & squeeze, mix in some rotation. It can look good and it has minimal performance hit, but here you need to derive the frustum properly from the view and projection matrices rather than calculating it separately. IMO you should be doing that anyway, likewise with vpn/vright/vup, which also come straight out of these matrices. It's always good to clean up Quake's "calculate the same thing in different ways and in different places" crap. 

Sounds like a QuakeC game logic fix -- so it should work in an engine. 

That was @nightfright obviously 

Could anyone confirm if stainmaps Quake default setting is OFF? 

Default Quake doesn't have stainmaps, so it is indeed OFF. 

Thanks! 

 

I fixed it in rubicon 2, the solution was to use a different channel for the second sound I think 

Created a page on the Quakewiki for external .vis and .lit packs, and put a link to that page on the Mark V page.

I separated out one (Abyss of Pandemonium) as an example and uploaded it to Quaketastic and put a link to it. See the first page in the Func "Screenshots" thread for the Quaketastic username and password.

This way new .vis and .lit content files can be added and updated. 

Video - Flames using QMB particle system

The QMB particle system is now working.

It'll be in the preferences menu and off by default. 

I have some extreme nitpickery to report.

Messing with the fullpitch stuff, I see that Mark V says these value mimic normal Quake:

cl_maxpitch -70
cl_minpitch 80

Buuut, they don't.
These values do:

cl_minpitch -69.93
cl_maxpitch 80.17

So it seems Mark V's pitch is very close to 0.17 lower than it should me.

How do I measure this? Well, start up a new multiplayer game, set gl_texturemode gl_nearest to get a nice sharp pixely look, and look all the way up or down. Looking down, set fov 30 or so and find a nice spot on the floor where you can mark your crosshair position. Do the same by looking up as far as you can with fov 10.

Repeating this (take screenshots if you like), you can see that in original Quake and Proquake, the position is identical, but in Mark V (and I think earlier Fitzqauke) it's off by a bit, unless you make the settings I posted.



Though neither of those cl_maxpitch values will be without issue when connecting to a Proquake server which disables fullpitch.

Upon connecting to FvF, for example, I find my value is altered to:

"cl_maxpitch" is "79.9969" (altered!)

Setting anything above that value causes the weirdness when you try to look all the way down and your view is jerked back to a legal value.

Though with the server sending the setting to me automatically, that's not really an issue.



On a less nitpicky note (though some will disagree!), this is one of those settings I have in the "Restore Quake Defaults" section of my MarkV.cfg file.

The Quake defaults should be respected and left as the defaults here. Fullpitch is for people who want an altered-from-default functionality.

Gosh darn it, back when I was a kid, we couldn't look all the way up and down, and WE LIKED IT THAT WAY!!



Though,

cl_minpitch -700
cl_maxpitch 800

Is pretty funny to play with! 

You are very likely correct about the original pitch numbers because of how client/server read and write those numbers and various roundings that happen (floating point imprecision and conversion to integer types of various sizes).

I remember having to do some fighting with those numbers when test against servers that require original pitch limits or they will fix your angle for you, which is an unpleasant experience.