I do like the option to have +speed slow you to walking speed if "always run" is on -- it seems like I've encountered that behavior in one of the other engines, maybe Quakespasm or FTE. It's like, "why not?" because +speed effectively won't do anything if you are already running, so go ahead and have it toggle your speed.

FifthElephant, look on the old page ( http://www.celephais.net/board/view_thread.php?id=60831 ) at post #1154. That will explain why the strafing feels different in Quakespasm (or if you are using a +speed key instead of "always run"). I believe that's actually the correct behavior -- you SHOULD sidestep fast if you are running, so you can avoid rockets and stuff.


I really dislike my sidestep speed suffering when "always run" is on. I know Baker has resisted making an adjustment to this behavior (which I believe is a flaw or oversight in Quake's original coding -- and I would much prefer it to be consistent as mh suggests), but my plea in that case it to leave the menu option defaulted to OFF (as it was in original Quake). It ends up being more config settings for me to return to Quake default behavior:

cl_forwardspeed 200
cl_backspeed 200
+speed


And I actually have a key bound like this:

alias +slow -speed
alias -slow +speed
bind b +slow

because sometimes I do want to return to walking speed, like if I want to position myself carefully to take a screenshot, or to get just the right sniper position, or if I want to build up a massive fireball for the Mage in FvF (his Delayed Fireball attack travels at walking speed, so if you are moving forward and firing them, you get like 4 of 5 of them all piled on top of each other, heh, for a massive explosion when they hit something).


Touch-screen controls? Yikes. That would be tricky. If someone really wants to play Quake on their phone, I'd say, "get a bluetooth gamepad," heh. Like the Ipega 9055 that clamps around your device.... 

Yes, my bad, that was indeed changed.

It looks as though that line was added to prevent cl_movespeedkey from being applied twice, once from the menu code and once from the following block.

Quake II drops the side speed default to 200, then when always running it goes to 400.

I wonder how all of this behaves with values of cl_forwardspeed set in configs? 

I just checked and Quakespasm also modifies forwardspeed and backspeed. Now I'm even more confused. 

Hey, what about a sort of compromise where the "Always Run" menu option would have 3 possible values:

Off
Forward-Backward
All Directions 

Regardless, anyone who doesn't like autorun behaving exactly like +speed can just set some cvars instead of using the menu item. Being picky about EXACTLY how something behaves is experienced users' lot, and experienced users shouldn't have any problems creating an autoexec.cfg.

A reminder:

cl_forwardspeed 400
cl_backspeed 400
cl_sidespeed 350
cl_upspeed 200

Those are the values for when autorun is toggled ON from the menu in the original game. If you want to be able to walk, set cl_movespeedkey to less than 1 and use +speed to slow down.

Though you might want to set cl_upspeed to around 400 if you don't want to swim like crap. 

 

Being picky about EXACTLY how something behaves is experienced users' lot, and experienced users shouldn't have any problems creating an autoexec.cfg

When I first started engine coding I discovered "expert user bias". I was building modern ProQuake, I added a field-of-view slider that went from 90 to 110. Spirit said "I use 130 and the slider doesn't go that far".

I wasn't for or against anyone's particular settings but it didn't take long to realize that accommodating all preferences while keeping things simple for the average user.

Expert users can already do what they want.

There are engines that try to appeal to all possible settings.

ezQuake has a ridiculous settings menu with several pages and each of them scroll. Likewise, DarkPlaces has menus galore.

I think this flies in the face of the KISS rule --- "Keep it simple, stupid!"

"Keep it simple, stupid!" -- is why conservative engines rule and why advanced engines are frustrating. 

I probably shouldn't harp on this, but this is what I believe ...

Bad engine design expresses itself in the form of menus. 

Well, the thing is: an average user would probably prefer autorun to behave in a modern, convenient way. The problem here isn't even the fact that there are subtle movement angle differences. There are more jarring symptoms of hackery.

Like, turning the autorun ON doesn't invert it. In other words, you can't slow down anymore. I can't recall any game made in the last 20 years that would behave like that.

Another thing is that the strafing speed is locked at 350, which means that you can't strafe slowly at all.

Bad engine design expresses itself in the form of menus.

This I agree with. Doom source ports are a great example of what happens when you pile up engine modifications and try to be flexible about them. Though the game was always at a disadvantage when it came to extending the gameplay functionality. 

There are also certain mod concerns with how the menu always worked.

Malice is probably the only example, but I consider it fairly important. Toggling "always run" forces certain speed settings upon the player, which is fine in Quake, but what if the mod wants different values?

Having a separate variable would allow mods like Malice to have a (somewhat) working autorun toggler that wouldn't break anything.

Just my two cents. Since I'm aware of the problem, it doesn't really affect me. 

But the behavior of Quake's always run is hardcoded in menu of the Quake engine. So whether or not Malice has different settings that option in the menu changes it just the same.

Mark V is meant to be an equivalent drop-in replacement for the original Quake, except that it has Quake's definition of mouse look and always run on (instead of requiring a user to go to the menu).

Mark V does not change any of the Quake cvars from their default -- aside from the always run defaulting on. 

But the behavior of Quake's always run is hardcoded in menu of the Quake engine. So whether or not Malice has different settings that option in the menu changes it just the same.

I know. That's the problem.

I hope that at least QS will implement the Q2-like functionality (I think there were some plans for it), because what's there right now clearly isn't that. 

I actually kind of like EZQuake's menus, I remember installing it and spending a good 30 - 40 minutes messing around with all the different options to see what changed. Should totally add a 15+ page menu with every possible cvar on it to Mark V. /s 

I thought ezQuake was the possibly the greatest Quake engine ever the version before they did that with the infinite menus and the laggy mouse driven cursor.

When it was like a FuhQuake with extra features, it had a simple menu that let you do many general settings.

So at one point, ezQuake was quite a nice engine that was laid out so cleanly it was arguably the model of excellent engine design.

Then they decided to add "Cool features" or something and it got all dorkulated. 

That Baker even added the extra menus that he did. I never expected much more than standard 

I hated every second of it. I felt like I had failed.

WinQuake gun position as an option forced me to do it.

I still try to think of ways to kill the preferences menu. 

Having additional menu items is fine, as long as the menu as a whole stays concise and organized. Not adding important things that regular users might need is about as bad as adding unnecessary junk.

For example, adding "previous weapon" to the controls menu is helpful. 

It's funny that you say that cause I agree, despite using that menu myself. Unreal had a little known secret menu hidden from the casual user. I think that is a good way of having a clean look but allows power users to tinker 

The benefit of menus is that they provide the user with visible options that they otherwise won't know about (because they are hidden in obscure console variables).

Experienced users are mostly aware of these options, but Mark V has so many more options (with not-so-great documentation) that even I am uncertain I know all the options I may want to fiddle with. The "find" option in the console is certainly very helpful, but you have to know what you want to search for before you can search for it.... With a menu, it's like, "oh, that's an option? Neat, let's see what it looks like..."

I don't think being "automatically anti-menu" is really the best approach. The problem may be that you've encountered some BAD menus, but that doesn't mean all additional menus are bad.


It would be nice to have the Basic menus for the basic user, then perhaps some deeper level of Advanced menus for people who really want to tweak their settings (sounds like that secret menu FE just mentioned).


I'm against "bad menus" myself.... I don't want things to get too cluttered up when I am trying to change some basic options. But I am not against having advanced menus with tons of settings in them, as long as they are clean and easy to understand and navigate. 

I think Quake is in a unique position because a lot of it's defaults are actually no longer sensible defaults.

That's at least partially on account of it's heritage - moving from a mostly-keyboard setup with no free looking, nobody actually had a clue how the game would have been played.

It's obvious that ID had expected joysticks to be the predominant control mechanism. Just look at all the joystick setup cvars, the existence of a dedicated readme for joysticks, sample .cfg files for different models, sponsorship deals, not to mention the ganky joystick code in the engine itself.

The existence of sensible defaults means that menu options are not really such a huge necessity. In Quake you need to either change the defaults or give the player an easily discoverable way of doing so themselves. 

"I do like the option to have +speed slow you to walking speed if "always run" is on -- it seems like I've encountered that behavior in one of the other engines, maybe Quakespasm or FTE. It's like, "why not?" because +speed effectively won't do anything if you are already running, so go ahead and have it toggle your speed."

I also have this behavior in Qrack, if your speed is > 300 then it will cut your speed in half, if its less then it will double it, both forward back, side as well. I'm used to pressing shift in modern games to "sprint" so it helps. 

Your quote of gunter -- that's actually probably the strongest argument I've seen.

Not the "other games" part -- I'm indifferent about that -- but the +speed "doesn't do anything if you already running".

I somehow missed seeing that in the thread until now. Probably because where lots of comments in a short period of time. 

The core issue is that all of the cl_*speed cvars relating to movement have defaults of 200, with the exception of cl_sidespeed which is 350.

Most people are used to "always run" just doubling forward and back speed, so it becomes forward 400, back 400, side 350 and up 200 (up is rarely used).

Doubling the speed on all axes, either via +speed or a Quake II-ish method, will increase cl_sidespeed further and cause it to dominate.

Quake II changes cl_sidespeed to 200 and removes cl_backspeed. I'm not sure when cl_sidespeed was changed but I do know that cl_backspeed was removed in the last month before Quake II went gold, so that was a change made after Quake II was it's own engine rather than just an experimental branch of Quake.

Quake II also changes cl_forwardspeed to not be saved to your config. I believe saving it was just a hack in Quake 1 so that the always run setting would be saved, but have no evidence either way.

All of this is discussion points. I know which behaviour I personally prefer but I'm not trying to convince anyone else. 

So, does capturevideo only work when watching a demo? Or can it record "live" gameplay? I set my codec and FPS but it complains about them not being set when i enter the command. If it only works on demos, adding that explanation to the error text would be useful. 

You can capture in real time, but capturevideo is intense and not necessarily a good fit for real-time capture --- it's going to be an fps/cpu hit and at higher resolutions the penalty gets stiff.

bind x "capturevideo toggle"

Make sure you have the other capturevideo settings the way you want:

capturevideo_codec xvid // I'd recommend this at least at first
capturevideo_fps 15 // You can always increase it.

Smaller resolutions like 640 x 480 are going to work better than larger ones because pixel count increases drastically.

You may also wish to consider something like Bandicam which works great with DirectX which Mark V DX9 obviously is. Someone earlier in the thread said how great Bandicam is.