Here is the "fucked up" thing.

Client movement is "normalized" (vector math).

So if you mess with the sidespeed max, it affects your diagonal movement speed.

This is (probably) why that behavior in Quakespasm doesn't feel like FitzQuake, because I think Quakespasm uses the same increases "all of them" that modern ProQuake does.

Which to me doesn't feel like FitzQuake, which in turn is why I didn't do that in Mark V. 

And when I say "normalized" --- I mean that increasing the sidespeed max has the consequence of decreasing the effective forward speed max when moving diagonally.

So even slight diagonal movement feels different than original Quake/FitzQuake/Mark V in an engine that increases all the speeds like Quakespasm or modern ProQuake. 

I have used QS more frequently recently and that's due to the music not working again in mark v and also the twitch integration in one of the QS forks.

Currently using Mark V off-cam and QS on cam. So there's that I guess.

I also have a "pure" quake folder with winquake and various folders with pretty much each engine.

But I do have to re-adjust my thinking when playing in QS due to the strafe differences. It's probably not noticeable to most people but it's fairly jarring to me for some reason 

QS changed some stuff in 2013, I think it now behaves like you suggest (+speed and "always run" both affect forwardmove/sidemove/upmove, +speed with "always run" slows you back down to walking speed):
https://sourceforge.net/p/quakespasm/code/797/

(I don't understand why that "cmd->forwardmove /= cl_movespeedkey.value;" line was added though.)

Baker, I play with always run on and do use shift to walk sometimes (e.g. useful for navigating narrow ledges to get to secrets). But I can see where you're coming from regarding keeping winquake / Fitz behaviour identically.

I have a hard time noticing the difference between sidespeed 350 and 400. 

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.