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. 

"Quake II changes cl_sidespeed to 200 and"

no wonder i always though sidespeed was weird in quake 1.
I played Quake1 freeware version all the way through, then later played Quake II extensively. Then came back to Quake 1.

//R00k: i didnt want +/-speed with 'always run on' to eventually STOP the player, but instead toggle the speed from walk to run, or run to walk.

if (cl_basespeedkey.value && cl_movespeedkey.value)
{
if ((cl_forwardspeed.value > 200) && (in_speed.state & 1))
{
if (!(in_klook.state & 1))
{
cmd->forwardmove += 200 * CL_KeyState (&in_forward);
cmd->forwardmove -= 200 * CL_KeyState (&in_back);
}
}
else
{
if (!(in_klook.state & 1))
{
cmd->forwardmove += cl_forwardspeed.value * CL_KeyState (&in_forward);
cmd->forwardmove -= cl_backspeed.value * CL_KeyState (&in_back);
}

if (in_speed.state & 1)
{
cmd->forwardmove *= cl_movespeedkey.value;
cmd->sidemove *= cl_movespeedkey.value;
cmd->upmove *= cl_movespeedkey.value;
}
}
}
else
{
if (!(in_klook.state & 1))
{
cmd->forwardmove += cl_forwardspeed.value * CL_KeyState (&in_forward);
cmd->forwardmove -= cl_backspeed.value * CL_KeyState (&in_back);
}

if (in_speed.state & 1)
{
cmd->forwardmove *= cl_movespeedkey.value;
cmd->sidemove *= cl_movespeedkey.value;
cmd->upmove *= cl_movespeedkey.value;
}
}//Phew!


only issue i have with above code is when you set your speed cvars to something like 180 then you will go in the opposite direction with +speed :P 

no wonder i always though sidespeed was weird in quake 1.

Probably to make dodging easier for keyboard-only players. Once again, only somewhat relevant in 1996.

Useless trivia: Chasm made itself look like even more of a Quake clone by copying this behavior.

only issue i have with above code is when you set your speed cvars to something like 180 then you will go in the opposite direction with +speed :P

Uhhhh, I have them at 160... 

So is that "reloading the level dead" bug specific to Mark V? I've been getting it a lot lately. Don't remember ever seeing it with QS. 

<p>if (scr_center_lines <= 4)
y = vid.height*0.35;
else
y = 48;</p>

This code always puzzled me. At modes larger than 320x200 the result is that centerprints more than 4 lines (including the e2 entrance message in start.bsp) will be rammed up near the top of the screen, whereas centerprints of 4 lines or less will be more accurately centered. This looks awful.

There was some kerfuffle over the whole thing in the old thread.

I believe I know the reason why.

It's for the slow finale printing at the end of an episode.

The give away is the positioning of the gfx/finale.lmp banner in Sbar_FinaleOverlay - it's at a y of 16, and when we add the banner height of 24 we get 40; 8 more pixels for a blank line between the banner and the centerprint and there's the 48.

Why did Carmack do it this way rather than checking for cl.intermission == 2? Probably the same reason he did a lot of other crazy-seeming things in the Quake code - a rush to get things done and get the game shipped. 

Some further evidence: Carmack's .plan for 17th June 1996 gives us the exact date that the centerprint change was made.

https://github.com/ESWAT/john-carmack-plan-archive/blob/master/by_year/johnc_plan_1996.txt#L3436

Interestingly he was also working on items relating to level transitions and boss/finale stuff on that day. "end of e4 text crash" was an item. So the evidence definitely correlates this change with work on finale messages. 

Well, like you said, he could have easily made it only apply to the "Congratulations" messages and not other Centerprints if he wanted, but he just notes in the changelog:

"changed center print position for very long text messages"

And I'm sure he would have noticed the E2 entrance message being affected by this, since it's right on the Start map, so it's no accident.

It just makes sense to me that any "very long" message would be moved up, out of the direct center of your view.

I actually didn't know that the Congratulations messages were considered Centerprints -- they use different functions in QuakeC, but I guess the engine funnels them through the same printing method. I tested it and, indeed, an end level message of only 4 lines will be centered lower on the screen. Weird.

If he were just trying to position those end-level messages only, counting the number of lines would be a very hacky way to do it. that sounds like something *I* would do! 

Picked up a couple of new Mark V users last night -- some old returning FvF players (I'm talking old players from the 90s).

They said Mark V works much better for them than GLquake (obv!), but they were still having some connection problems -- and I've seen another player who has this issue on the server too (I think it's Mr. Burns who has this issue, maybe):

When the level changes, they get stuck in the console and never reconnect to the server. We still see their names as connected players, but their frags are shown as "0." I believe we told Mr. Burns to try typing "ping" in the console when this happens, and that sometimes allows him to connect and get back in without having to totally reconnect and lose all his frags.

I don't have any control over the server (Polarite does that), but it appears to be running "Magic ProQuake Server Version 3.90" in linux.

I really can't provide much more information about this issue.... I assume it's one of those things where it gets stuck doing the "keepalive" messages in the console. I'll ask more specifically the next time someone encounters this -- it's only a few players, but it affects them consistently.



Also, one of the returning players asked about mirrors -- he wanted to be able to see his reflection (mentioning that it was a pretty big deal/cool feature back in the day), and I told him mirrors only worked when running plain ID1... but I realized that it really SHOULDN'T be this way, as it violates what I think should be a pretty important aspect of Quake engine design: you shouldn't take away user control and force your own preference on the end user (even with good intentions).

I mean, there are already various mirror variables that the user can set if he wants mirrors to be on or off (and actually, they should probably be off by default). If the user wants to turn them on, even in a mod or map where it might not work well, he should be able to do so.

Also, for those users that want to play with mirrors, how about an easy way to set a mirror texture. Specifically, something like (probably used in conjunction with tool_texturepointer, but not necessarily): if you input "set_mirror" in the console, it will assign the mirror effect to whatever texture you are pointing at (manually typing in those texture names for the mirror texture prefix is a chore and prone to typos, heh).

Of course, there's the issue of having to restart a map before it takes affect, but it would still be handy for people that want to play around with mirrors.

I suppose it would be handy to be able to feed the pointed-at texture into any of the tex prefix variables, actually.... Not sure how that could be implemented, other than copying the selected texture name into the console and allowing tab to autocomplete the various things you might want to apply it to.

Ah, yeah, it would work if you just had it stick "r_tex [copied texture name]" in the console and positioned the cursor right after r_tex, then tab will autocomplete all the various r_texprefix things with the selected texture already filled in. 

I want to see a Quake ingame video of this effect 

If he were just trying to position those end-level messages only, counting the number of lines would be a very hacky way to do it. that sounds like something *I* would do!

This is actually exactly the way Carmack coded a lot of things in Quake.

How did he test to see if you were connected to a server and therefore the status bar should be drawn? By checking the number of console lines drawn. How did he test to see if a map was running? By checking if the console was fullscreen. Quake is full of crap like this. 

Holy shit. I would love to read a compilation of "quake code nightmares" like this.