I'm posting my feedback list for Mark V here in my forum, because it's really long, and things tend to get swallowed up over on the Mark V thread (
http://www.celephais.net/board/view_thread.php?id=61375 ). (When I refer to a number like #2123, that's a reference to a post on that page). Plus here I can edit it and make alterations and remove any issues that get addressed.
And keep in mind I love the Mark V engine, heh (
http://quakeone.com/markv/ ). My intense ammount of niticking is because I'm a perfectionist, and my intent is to push Mark V even closer to "perfect!"
If anyone reading this agrees with any of the issues I've brought up, you have to let Baker know! I make so many suggestions that many of them will get written off as just me being picky, heh (at least Baker reads every suggestion, because he wants to make Mark V as perfect as possible too). But I know I speak for a lot of other people on many of these issues... so make your preferences heard.
Defaults should be defaulted to the default.
---------------------------------------------
I'll start with a statement: Defaults should be left alone unless there is some problem with them, or if there is absolutely no negative impact to making the change. Changing a default merely out of personal taste is not something an engine coder should ever do. The end user should expect Quake to behave in the standard way it always has, as a starting point, and be allowed to tweak it to their tastes from there.
So here are a list of Defaults that I always end up having to reset in Mark V:
Crosshair? Well, it was never on by default, but it really should be. Everyone uses it. This is a good example of a minor default that has no problems associated with changing it -- as long as you are only activating Quake's standard crosshair and not some gaudy custom crosshair graphic, heh.
Weapon Draw - should be Quake default. Why use Fitzquake default? It just hides too much of the weapon model. I see it also eliminates the animation of shifting your weapon position when you look up and down.... That makes it seem more stiff, like you're sitting in a fixed turret rather than holding a weapon in your hands. Fitzquake is a great engine to base Mark V on, but you should still be aiming to emulate Quake defaults rather than any Fitzquake ones that changed standard Quake look/feel/function.
The Invisibility Weapon Draw is another one that's fine with the new transparency effect. I can't see any negative impact with this change from default (of just not drawing your gun?), as it's a pretty simple enhancement that looks neat.
View Blends - Should be default.... Ya know, I think it's mainly the ring blend that's too strong by default - maybe an individual setting to adjust individual blends would be nice. And I think your "Lite" setting is way, way too weak for all the blends. I jump in the lava and it looks like there is NO lava color on my screen at all ? Or so little I can't notice it.... And View Blends = "None" disables water warp effects? Is that intentional? Anyway, this Default change is just too great to slip by as inconsequential....
Status Bar - Centered, should be Default, as I mentioned before. This makes a visual change which may or may not even be preferred as an aesthetic choice, but it removes information that the Default position allowed for (online player names). A default should not be changed if there is any negative impact. Let players tweak their settings to their own preference, but start them out at the Defaults.
Hm, you know what I think should be set by default? WASD movement keys.... That's pretty universal, whereas some of the actual Quake default key assignments (A/Z look up/look down) are pretty... universally ditched by players.
Mirrors are pretty, but bad for FPS. Default off. A player actually ran into this problem and didn't know why his FPS was bad: #1460 ... Mirrors are probably a good candidate for their own menu setting.
gl_overbright_models looks bad, really. Way too bright. It just completely washes out some colors in the same way that Contrast affects fullbright textures. Use chase_active and stand in a bright location and compare how your player's colors on his back lose their subtle shading and just become one solid blotch of brightness. Gl_quake didn't have this, did it? I don't think everything should try to "look like winquake," which is, I think, what this hack was trying to accomplish? Glquake looked better than winquake. Emulate that, in this case.
scr_originalquake2d 1 should be the default. This was a change that nobody asked for -- a problem that didn't need fixed. And altering standard Quake centerprint positioning changes the expected behavior for modders using centerprints. There wasn't much control over centerprint positioning, but there was some, and we could use the "more than 4 lines of text" behavior that was standard in Quake to make sure certain centerprints would be up near the top of the screen.
sv_altnoclip -- again should be left at default: off. If you are hovering above something and looking down, you want to be able to move all around and follow it without changing altitude. +moveup and +movedown can do that.
r_viewmodel_fov -- should default off. OR, should only apply when zooming OUT. It's very unnatural to still see your unchanging gun when you zoom in (your +zoom_key alias even has to specifically disable this!). It's fine when zooming out to high FOVs to keep your gun from looking borked.... So either use default Quake behavior and allow FOV tweakers to adjust this manually along with their FOV, or make the behavior a bit better and only prevent it from zooming out weirdly. (see #94 for a better fix suggestion of using 2 different settings, r_viewmodel_fov_max and _min, but really you only need one setting -- a max weapon FOV clamp -- to prevent the zooming out effect; everyone would want that, but nobody wants the opposite). This is one of those examples where changing a default behavior to fix one problem causes another problem; such a change from default should not be made.
Speaking of your +zoom_key..... It just bugs me on a mathematical and programming level, heh.
MATH AND PROGRAMMING ANALYSIS TIME!
There's no need to keep multiplying sensitivity at each step along the way, since the animation for the zoom happens virtually instantly (or in like 4 frames). You only need to decrease it once, before the fov zooming, and then restore it once at the end of the un-zoom. The repeated multiplications end up at 0.0625 * sensitivity which seems a bit too slow/insensitive. I think a plain * 0.1 would be better (and just cleaner, mathematically)
Additionally, there is no "wait" after your final multiplication before you hard set/reset the end values at the final step in the aliases, so that last multiplication would never really have its own frame, so would be completely pointless (never seen). Like if you set x=1; x=2; in the same frame.... So there should be another "wait" in there, which means there should really be 5 steps to the animation.
If you want multiplications for FOV that mathematically work 5-steps in each direction, the multiplication values should be more like 0.646 and 1.546 (with no real need to hard set "10" for the final zoom in -- even starting with higher FOVs would zoom almost all the way in).
To illustrate, if you start at the default 90 fov, your 0.7 multiplication would step down like this:
90 (start), 63, 44, 30, 21 (this one never shows - no "wait"), 10 (hard set at the end).
The 30 and (nullified) 21 would be good steps for that part of the zoom, but the sudden jump from 90 to 63 is not good as an animation.
Then going back up starting from 10 with your 1.43 multiplier makes it:
10 (start), 14, 20, 29, 41 (skipped - no "wait"), then hard set back to 90.
Tiny jumps at the start, then a huge jump from 29 back to 90.... Not a good animation.
For comparison, using the multipliers I suggested would give:
90 58 37 24 15 10 (don't hard set at 10 -- the actual decimal value works better for the reverse math)
10 15 24 37 58 89 (you would still hard re-set the saved FOV value here)
Which is still not great as an animation, but is more mathematically correct.
BUT, since the fov multiplications are only there to provide a zoom animation, they are not even necessary or ideal, and it would be cleaner just to have fixed values that produce a good animation (the math steps don't necessarily do that well).....
So these would be much more clean, optimal, and better-animated aliases:
alias +zoom_key2 "valsave fov 1; valsave sensitivity 2; valsave r_viewmodel_fov 3; mul sensitivity 0.1; r_viewmodel_fov 0; fov 70; wait; fov 50; wait; fov 30; wait; fov 20; wait; fov 10"
alias -zoom_key2 "fov 20; wait; fov 30; wait; fov 50; wait; fov 70; wait; valload fov 1; valload sensitivity 2; valload r_viewmodel_fov 3"
Yeah, maybe most people don't notice such subtleties in animations... but I do! heh.
And even so, there is just way too much unnecessary (and non optimal) math in the current aliases.
And it would be even cleaner if you ditched the r_viewmodel_fov as it currently works, and only go with clamping the max FOV for a viewmodel (which is the real problem you were trying to fix). Then you wouldn't need to save and load that setting as part of a zoom in.
END MATH AND PROGRAMMING DISCUSSION
Honoring new cfg files automatically when you switch to a gamedir. Should be a thing. Those cfg files are there for a reason.... If you're concerned that a mod author might put bad settings in a cfg file inside a pak file (which would still take effect if you run a mod the standard way), then give unpacked files preference (another past issue we've discussed -- some other engines do this), which gives the user more control, since he can edit or replace those files himself. Gamedir switching is supposed to make things easier for changing your -game, but if it doesn't load your cfg files that you have set up for that -game, it's not as easy. Both these things (gamedir cfg loading and unpacked file preference) are good candidates for menu settings to let the user enable/disable them. Or a console variable at the very least (accepting that it may need a "this setting requires a restart before it takes effect" warning).
And yep, I gotta mention the "map guessing" feature, which it seems nobody even uses (because of the superior Levels menu), which causes me real, non-hypothetical problems -- please get rid of it or add an option to disable the annoying thing.....
And as noted in the past, the Levels menu should appear no matter if custom menu graphics are used or not. The whole purpose of a menu to change options is "ease of functionality." Function is more important than beauty here.
Always Run. Arrrrggghh. It's flawed, and defaulted on, heh. I did an analysis of why it's flawed:
viewtopic.php?f=12&t=3776 . Quakespasm fixes the flawed behavior, and also makes it so the +speed key (which would otherwise be completely useless when Always Run is on) acts as +slow (or it may be Qrack I'm thinking of which does this). I think an ideal solution would be to have 3 menu settings for it: Off, Forward-Backward (the old flawed Quake setting, for people who are used to it), and All Directions (which includes sidestepping and don't forget swimming up/down, which were all overlooked in Quake's flawed Always Run setting). My own preference would be to have it ON with the correct behavior of doubling your speed in all directions (not just forward-backward). "Running" is another behavior that is pretty universally used in Quake, but some people may be used to the flawed behavior's motion, so probably the most correct option would be to honor Quake's default of OFF and give 3 settings to choose from in the menu (Off, Forward-Backward, All Directions)-- this would be ideal because the user would then have to use the menu to activate it, and he would then see that there are multiple options, which he could test to really see which he preferrs, instead of just being forced into one mode. What would be the worst behavior? Sticking it ON by default with the flawed functionaloty! heh. Hey, when both me and mh agree strongly on something, it should be so! #1333
And altering the +speed key so that it halves your speed when Always Run is on is just a good idea.
EDIT [left this one out]:
During the "congratulations" screens, pressing TAB causes the text to disappear, but not the "congratulations" banner (this is in "DM mode" that FvF Quest runs in, when normally TAB should show the scoreboard). It doesn't actually show the scoreboard, it just makes the text vanish. Proquake didn't do this.
Ideas for Enhancements:
r_waterripple could be improved. Mainly it just needs to be slower motion.
transparent quake clouds in front of skybox, like with r_skyalpha
FTE has a nice feature when you are in the menu and the focus in on either the "brightness" or "contrast" slider, the "menu background darkening" of your game screen goes away. It's much easier to adjust your screen values when you can see the results as you adjust, instead of having to adjust, then exit the menu to see the actual results. Seriously, this is a really good feature.
FTE puts the FPS in the lower right corner. That is probably a much better place for it... along with the POS digits. And then it would make even more sense for FOV to be the size of the status bar clock digits (or make it separately scalable, as I've previously suggested -- such informational numbers should be smaller on the screen, again, like the clock).
I'm posting my feedback list for Mark V here in my forum, because it's really long, and things tend to get swallowed up over on the Mark V thread ( http://www.celephais.net/board/view_thread.php?id=61375 ). (When I refer to a number like #2123, that's a reference to a post on that page). Plus here I can edit it and make alterations and remove any issues that get addressed.
And keep in mind I love the Mark V engine, heh ( http://quakeone.com/markv/ ). My intense ammount of niticking is because I'm a perfectionist, and my intent is to push Mark V even closer to "perfect!"
If anyone reading this agrees with any of the issues I've brought up, you have to let Baker know! I make so many suggestions that many of them will get written off as just me being picky, heh (at least Baker reads every suggestion, because he wants to make Mark V as perfect as possible too). But I know I speak for a lot of other people on many of these issues... so make your preferences heard.
Defaults should be defaulted to the default.
---------------------------------------------
I'll start with a statement: Defaults should be left alone unless there is some problem with them, or if there is absolutely no negative impact to making the change. Changing a default merely out of personal taste is not something an engine coder should ever do. The end user should expect Quake to behave in the standard way it always has, as a starting point, and be allowed to tweak it to their tastes from there.
So here are a list of Defaults that I always end up having to reset in Mark V:
Crosshair? Well, it was never on by default, but it really should be. Everyone uses it. This is a good example of a minor default that has no problems associated with changing it -- as long as you are only activating Quake's standard crosshair and not some gaudy custom crosshair graphic, heh.
Weapon Draw - should be Quake default. Why use Fitzquake default? It just hides too much of the weapon model. I see it also eliminates the animation of shifting your weapon position when you look up and down.... That makes it seem more stiff, like you're sitting in a fixed turret rather than holding a weapon in your hands. Fitzquake is a great engine to base Mark V on, but you should still be aiming to emulate Quake defaults rather than any Fitzquake ones that changed standard Quake look/feel/function.
The Invisibility Weapon Draw is another one that's fine with the new transparency effect. I can't see any negative impact with this change from default (of just not drawing your gun?), as it's a pretty simple enhancement that looks neat.
View Blends - Should be default.... Ya know, I think it's mainly the ring blend that's too strong by default - maybe an individual setting to adjust individual blends would be nice. And I think your "Lite" setting is way, way too weak for all the blends. I jump in the lava and it looks like there is NO lava color on my screen at all ? Or so little I can't notice it.... And View Blends = "None" disables water warp effects? Is that intentional? Anyway, this Default change is just too great to slip by as inconsequential....
Status Bar - Centered, should be Default, as I mentioned before. This makes a visual change which may or may not even be preferred as an aesthetic choice, but it removes information that the Default position allowed for (online player names). A default should not be changed if there is any negative impact. Let players tweak their settings to their own preference, but start them out at the Defaults.
Hm, you know what I think should be set by default? WASD movement keys.... That's pretty universal, whereas some of the actual Quake default key assignments (A/Z look up/look down) are pretty... universally ditched by players.
Mirrors are pretty, but bad for FPS. Default off. A player actually ran into this problem and didn't know why his FPS was bad: #1460 ... Mirrors are probably a good candidate for their own menu setting.
gl_overbright_models looks bad, really. Way too bright. It just completely washes out some colors in the same way that Contrast affects fullbright textures. Use chase_active and stand in a bright location and compare how your player's colors on his back lose their subtle shading and just become one solid blotch of brightness. Gl_quake didn't have this, did it? I don't think everything should try to "look like winquake," which is, I think, what this hack was trying to accomplish? Glquake looked better than winquake. Emulate that, in this case.
scr_originalquake2d 1 should be the default. This was a change that nobody asked for -- a problem that didn't need fixed. And altering standard Quake centerprint positioning changes the expected behavior for modders using centerprints. There wasn't much control over centerprint positioning, but there was some, and we could use the "more than 4 lines of text" behavior that was standard in Quake to make sure certain centerprints would be up near the top of the screen.
sv_altnoclip -- again should be left at default: off. If you are hovering above something and looking down, you want to be able to move all around and follow it without changing altitude. +moveup and +movedown can do that.
r_viewmodel_fov -- should default off. OR, should only apply when zooming OUT. It's very unnatural to still see your unchanging gun when you zoom in (your +zoom_key alias even has to specifically disable this!). It's fine when zooming out to high FOVs to keep your gun from looking borked.... So either use default Quake behavior and allow FOV tweakers to adjust this manually along with their FOV, or make the behavior a bit better and only prevent it from zooming out weirdly. (see #94 for a better fix suggestion of using 2 different settings, r_viewmodel_fov_max and _min, but really you only need one setting -- a max weapon FOV clamp -- to prevent the zooming out effect; everyone would want that, but nobody wants the opposite). This is one of those examples where changing a default behavior to fix one problem causes another problem; such a change from default should not be made.
Speaking of your +zoom_key..... It just bugs me on a mathematical and programming level, heh.
MATH AND PROGRAMMING ANALYSIS TIME!
There's no need to keep multiplying sensitivity at each step along the way, since the animation for the zoom happens virtually instantly (or in like 4 frames). You only need to decrease it once, before the fov zooming, and then restore it once at the end of the un-zoom. The repeated multiplications end up at 0.0625 * sensitivity which seems a bit too slow/insensitive. I think a plain * 0.1 would be better (and just cleaner, mathematically)
Additionally, there is no "wait" after your final multiplication before you hard set/reset the end values at the final step in the aliases, so that last multiplication would never really have its own frame, so would be completely pointless (never seen). Like if you set x=1; x=2; in the same frame.... So there should be another "wait" in there, which means there should really be 5 steps to the animation.
If you want multiplications for FOV that mathematically work 5-steps in each direction, the multiplication values should be more like 0.646 and 1.546 (with no real need to hard set "10" for the final zoom in -- even starting with higher FOVs would zoom almost all the way in).
To illustrate, if you start at the default 90 fov, your 0.7 multiplication would step down like this:
90 (start), 63, 44, 30, 21 (this one never shows - no "wait"), 10 (hard set at the end).
The 30 and (nullified) 21 would be good steps for that part of the zoom, but the sudden jump from 90 to 63 is not good as an animation.
Then going back up starting from 10 with your 1.43 multiplier makes it:
10 (start), 14, 20, 29, 41 (skipped - no "wait"), then hard set back to 90.
Tiny jumps at the start, then a huge jump from 29 back to 90.... Not a good animation.
For comparison, using the multipliers I suggested would give:
90 58 37 24 15 10 (don't hard set at 10 -- the actual decimal value works better for the reverse math)
10 15 24 37 58 89 (you would still hard re-set the saved FOV value here)
Which is still not great as an animation, but is more mathematically correct.
BUT, since the fov multiplications are only there to provide a zoom animation, they are not even necessary or ideal, and it would be cleaner just to have fixed values that produce a good animation (the math steps don't necessarily do that well).....
So these would be much more clean, optimal, and better-animated aliases:
alias +zoom_key2 "valsave fov 1; valsave sensitivity 2; valsave r_viewmodel_fov 3; mul sensitivity 0.1; r_viewmodel_fov 0; fov 70; wait; fov 50; wait; fov 30; wait; fov 20; wait; fov 10"
alias -zoom_key2 "fov 20; wait; fov 30; wait; fov 50; wait; fov 70; wait; valload fov 1; valload sensitivity 2; valload r_viewmodel_fov 3"
Yeah, maybe most people don't notice such subtleties in animations... but I do! heh.
And even so, there is just way too much unnecessary (and non optimal) math in the current aliases.
And it would be even cleaner if you ditched the r_viewmodel_fov as it currently works, and only go with clamping the max FOV for a viewmodel (which is the real problem you were trying to fix). Then you wouldn't need to save and load that setting as part of a zoom in.
END MATH AND PROGRAMMING DISCUSSION
Honoring new cfg files automatically when you switch to a gamedir. Should be a thing. Those cfg files are there for a reason.... If you're concerned that a mod author might put bad settings in a cfg file inside a pak file (which would still take effect if you run a mod the standard way), then give unpacked files preference (another past issue we've discussed -- some other engines do this), which gives the user more control, since he can edit or replace those files himself. Gamedir switching is supposed to make things easier for changing your -game, but if it doesn't load your cfg files that you have set up for that -game, it's not as easy. Both these things (gamedir cfg loading and unpacked file preference) are good candidates for menu settings to let the user enable/disable them. Or a console variable at the very least (accepting that it may need a "this setting requires a restart before it takes effect" warning).
And yep, I gotta mention the "map guessing" feature, which it seems nobody even uses (because of the superior Levels menu), which causes me real, non-hypothetical problems -- please get rid of it or add an option to disable the annoying thing.....
And as noted in the past, the Levels menu should appear no matter if custom menu graphics are used or not. The whole purpose of a menu to change options is "ease of functionality." Function is more important than beauty here.
Always Run. Arrrrggghh. It's flawed, and defaulted on, heh. I did an analysis of why it's flawed: http://www.fvfonline.com/forum/viewtopic.php?f=12&t=3776 . Quakespasm fixes the flawed behavior, and also makes it so the +speed key (which would otherwise be completely useless when Always Run is on) acts as +slow (or it may be Qrack I'm thinking of which does this). I think an ideal solution would be to have 3 menu settings for it: Off, Forward-Backward (the old flawed Quake setting, for people who are used to it), and All Directions (which includes sidestepping and don't forget swimming up/down, which were all overlooked in Quake's flawed Always Run setting). My own preference would be to have it ON with the correct behavior of doubling your speed in all directions (not just forward-backward). "Running" is another behavior that is pretty universally used in Quake, but some people may be used to the flawed behavior's motion, so probably the most correct option would be to honor Quake's default of OFF and give 3 settings to choose from in the menu (Off, Forward-Backward, All Directions)-- this would be ideal because the user would then have to use the menu to activate it, and he would then see that there are multiple options, which he could test to really see which he preferrs, instead of just being forced into one mode. What would be the worst behavior? Sticking it ON by default with the flawed functionaloty! heh. Hey, when both me and mh agree strongly on something, it should be so! #1333
And altering the +speed key so that it halves your speed when Always Run is on is just a good idea.
EDIT [left this one out]:
During the "congratulations" screens, pressing TAB causes the text to disappear, but not the "congratulations" banner (this is in "DM mode" that FvF Quest runs in, when normally TAB should show the scoreboard). It doesn't actually show the scoreboard, it just makes the text vanish. Proquake didn't do this.
Ideas for Enhancements:
r_waterripple could be improved. Mainly it just needs to be slower motion.
transparent quake clouds in front of skybox, like with r_skyalpha
FTE has a nice feature when you are in the menu and the focus in on either the "brightness" or "contrast" slider, the "menu background darkening" of your game screen goes away. It's much easier to adjust your screen values when you can see the results as you adjust, instead of having to adjust, then exit the menu to see the actual results. Seriously, this is a really good feature.
FTE puts the FPS in the lower right corner. That is probably a much better place for it... along with the POS digits. And then it would make even more sense for FOV to be the size of the status bar clock digits (or make it separately scalable, as I've previously suggested -- such informational numbers should be smaller on the screen, again, like the clock).