News | Forum | People | FAQ | Links | Search | Register | Log in
Mark V - Release 1.00
http://quakeone.com/markv/

* Nehahra support -- better and deeper link
* Mirror support, "mirror_" textures. video
* Quaddicted install via console (i.e. "install travail")
* Full external texture support DP naming convention
* Enhanced dev tools texturepointer video inspector video
* IPv6 support, enhanced server capabilities
* Enhance co-operative play (excels at this!)
* Software renderer version (WinQuake)
* "Find" information command (ex. type "find sky")

Thanks to the beta testers! NightFright, fifth, spy, gunter, pulsar, johnny law, dwere, qmaster, mfx, icaro, kinn, adib, onetruepurple, railmccoy

And thanks to the other developers who actively provided advice or assistance: Spike (!), mh, ericw, metlslime and the sw guys: mankrip and qbism.

/Mac version is not current yet ...; Linux will happen sometime in 2017
First | Previous | Next | Last
What About 
tell the mapper to put liquid brushes in a func_group and then set all the different liquid lighting options on the func_group. 
 
Personally, I've had enough of having to do that with _phong 1 on all my func_details... 
#1321 
The idea isn't to annoy the mapper by making him manually set the rules up on each func_group - I assume there would be default liquid lighting settings that are used if nothing is specified, but...if you want custom light behaviour on a certain liquid body then you can func_group the liquid and set some options...

Beats having hardcoded arbitrary rules for teleport textures and whatnot imo. 
Or Even Better 
Do it like surface lights - have an entity whose sole purpose is to specify the light properties (aka override the defaults) of a particular texture, which then applies to all instances of that texture in the map. No need to use func_groups.

I only thought of this because with custom liquid textures used for random things like teleporters or energy fields, the texture names can be unpredictable (I think Knave has a *starfluid texture or something) 
 
I think the special entity could work, although I don't think it's ever been done before - with surface lights, it's a single key that specifies that the light it's on should be duplicated and spread across all instances of that texture. It's not specifically a custom entity that does anything different to a normal light.

This is quite offtopic, anyway... 
(Maybe) Simplified Navigation For Non-Traditional Platforms 
I'm slightly tempted to add an (optional) auto-jump feature where a player at an edge will automatically jump *only* if they can make the jump at the current speed *and* they are running.

If they can't make the jump and are running, the option would work like "edgefriction 999999" (if you don't know what it is, you might try it) and make it very difficult to fall off an edge.

And perhaps have the option have an "automatic jump up" if forward progress requires a upwards jump that can be made.

(Because pressing "jump" seems to be an annoying burden if you aren't using a mouse + keyboard). 
Not Sure I Understand 
But is it similar to quake 3's awesome stair clipping. I hate q1's momentum loss around short floor variances 
 
I can understand that this might seem attractive on accessibility grounds, but (and unless I'm seriously missing something) wouldn't it totally fuck with your game if you were playing with "always run" enabled? 
 
rebind the jump button to +run 
 
I don't fully get it, but it sounds like a terrible idea.

Why don't you just make it a full bot so the player doesn't have to press "attack" in addition to not having to press "jump?" Because "aiming" is an annoying burden if you aren't using mouse + keyboard... or, you know, if you just suck at Quake :p heh. I know you're probably thinking about Gamepad controls, but still, meh.


mh, the "always run" menu option already fucks with my game by borking up my sidestep speed... AND Mark V changes it to default ON (that's an old complaint of mine, heh. [oldpage #1154]). 
 
I know you're probably thinking about Gamepad controls, but still, meh.

I think he's talking about things like phones and tablets. Gamepad users don't have a problem with jumping. 
 
Touch screens is exactly what I thought it was too, where you might have left thumb to move, right thumb to look, tap to shoot, and ideally you'd like to be able to jump while moving and shoot while jumping but you're out of options for how to handle it. 
 
mh, the "always run" menu option already fucks with my game by borking up my sidestep speed... AND Mark V changes it to default ON (that's an old complaint of mine, heh. [oldpage #1154]).

I'm not sure about the details of how MarkV implements this.

I like the Quake 2 method which maintains a separate cl_run cvar and just multiplies the speeds by 2 if it's set. Seems less messy to me that Quake's faffing around with cl_forwardspeed. Any reasons why that hasn't been adopted (aside from "iiiiit's nottttt Quaaaaaakkkkkkkke", that is)? 
Triple Post 
@Gunter - found your discussion of "always run" in the other thread; repeating here for info:

This is not a good setting to default ON. It's weird. It doesn't actually do what you'd think (make it like you're holding down the +speed run button) -- it just messes with your normal "walking" forward and back speed, but not your sidestepping speed, exactly. So you end up being able to run forward fast, BUT when doing so you sidestep slowly... EVEN AFTER you press the run button or use +speed in the console. Always Run must be switched off to get proper sidestep speed when running, even when using the +speed option (unless you make other settings, I guess?). Please default it back to off. A better fix would be to change the "Always Run" menu option to actually lock +speed on instead of whatever weird thing it currently does.

This is basically what Quake II does.

It's "always run" option, via the cl_run cvar, is exactly the same behaviour as the +speed key. In addition it has the following nice behaviour.

If "always run" is off, pressing the +speed key will speed you up.

If "always run" is on, pressing the +speed key will slow you down.

Even nicer, it's basically (aside from cvar declarations and removing the old cl_forwardspeed behaviour) a one-liner: https://github.com/id-Software/Quake-2/blob/master/client/cl_input.c#L304

I'm coming more and more strongly in favour of this being something that should be standardized across Quake engines. 
 
Thus far, I've only seen one control scheme for touchscreen that was "ok" (Minecraft) but have some thoughts for improvement.

The difficulty of "getting it right" somehow increases the appeal to me. 
@mh 
Mark V merely defaults always run on. Like what happens in the original Quake if you toggle it.

Gunter is arguing it should do more than that because turning on "Always run" in original Quake didn't also increase backspeed or sidespeed.

Which I didn't do in Mark V because in my opinion it should use the FitzQuake definition of always run.

So Gunter is arguing against the original Quake behavior, saying Mark V's "always run" should do more (ProQuake's always run sets all 3, for instance).

+speed - I myself have never found a scenario where I would want to walk instead of run in Quake. Not in any of hundreds of single player maps. Not in any of countless of multiplayer games/maps. But I can describe scenarios where changing it to Quake 2 style is a behavior change in original Quake.

I might be a bit of bad person in that I find both of the above kind of topics on the "boring side" of the spectrum. 
 
OK, I suspected that didn't come across as clearly as intended.

Just to summarize:

Quake has two run behaviours, and they're both different.

"Always run On" via the menus just bumps the values of cl_forwardspeed and cl_backspeed.

+speed applies the value of cl_movespeedkey uniformly to all axes of movement.

Quake II's behaviour is identical to +speed in Quake 1. Let's not get the idea that anybody is advocating for porting "Quake II movement" to Quake 1, because that's not happening.

What Gunter is arguing, and I am supporting him in this, is that the Quake behaviours should be consistent.

This is a simple matter of player expectation and principle of least surprise. If you have a "+speed" key, you expect it to have the same behaviour as "Always run On". 
 
I prefer the mark_v and fitz implementation of always run. I find quakespasm is too quick to judge when you strafe 
 
@fifth - Agreed. And because Mark V is intended to preserve the feel of FitzQuake. Modern ProQuake does what Gunter advocates and it doesn't feel exactly the same to me. So I stuck with the FitzQuake way.

@mh - The behavior of +speed is described here .... http://www.quakewiki.net/archives/console/commands/quake.html#c-+speed

Devil's advocate: Why mess with a defined behavior? Couldn't someone who wanted +speed to slow them down instead set cl_movespeedkey 0.5 in their autoexec.cfg?

My thought is this is already available to a user if they decided to do so. So it is not necessary to break defined and known Quake functionality like what, say, Quakespasm does. 
 
QuakeSpasm, Fitz and MarkV are all the exact same so far as strafing is concerned. No difference whatsoever in the code. 
 
Devil's advocate: Why mess with a defined behavior? Couldn't someone who wanted +speed to slow them down instead set cl_movespeedkey 0.5 in their autoexec.cfg?

Sigh.

That's not what I'm saying. That's a side effect, not the main thing. The main thing is an "Always run" option that's the same as +speed.

You don't have to have +speed slow you down. Just change the "^" to "||" in the one line of code and it won't.

Again: the main issue is that "Always run" and "+speed" behave differently. I am saying that they should behave the same. That is all. 
 
And incidentally, the Quake wiki is wrong. That's not what +speed does; all you have to do is look at the code to see that.

https://github.com/id-Software/Quake/blob/master/WinQuake/cl_input.c#L313

What +speed does, in the original Quake code, is adjust all 3 axes of the final movement. It doesn't modify cl_forwardspeed or cl_backspeed. What's described in the wiki is what "Always run" in the menus does (with the exception of the cl_movespeedkey part).

You see - two different behaviours. One modifies all 3 axes: forward/back, up/down, left/right; the other only modifies forward/back. One modified after the full movement is calculated; the other modifies before. One applies the value of cl_movespeedkey; the other just doubles. 
Hhmmm 
if that's the case why does QS feel a bit twitchier on the strafing than Mark v?

I feel like I hit strafe in QS and I feel I have less control cause I shoot off so fast.

I'm not trying to be an ass about it, genuinely feels different to me. 
 
I think I'm seeing where you are coming from now. Quake has a number of inconsistencies in that department.

Like how +jump is slower in water than +moveup.

Quake is crazy like that :( 
@mh 
I almost inserted the word "allegedly" when describing the +speed entry.

(As an engine coder, I don't trust a non-engine coder's description of what something does because they didn't use the code as reference. Although that page was made pre-source code release). 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.