What About
#1320 posted by Kinn on 2017/02/04 01:25:36
tell the mapper to put liquid brushes in a func_group and then set all the different liquid lighting options on the func_group.
#1321 posted by PRITCHARD on 2017/02/04 03:27:37
Personally, I've had enough of having to do that with _phong 1 on all my func_details...
#1321
#1322 posted by Kinn on 2017/02/04 03:39:01
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
#1323 posted by Kinn on 2017/02/04 03:53:14
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)
#1324 posted by PRITCHARD on 2017/02/04 04:00:49
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
#1325 posted by Baker on 2017/02/07 06:27:53
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
#1327 posted by mh on 2017/02/07 16:33:48
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?
#1328 posted by metlslime on 2017/02/07 18:55:57
rebind the jump button to +run
#1329 posted by Gunter on 2017/02/07 19:30:31
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]).
#1330 posted by Kinn on 2017/02/07 20:00:09
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.
#1331 posted by mh on 2017/02/07 20:39:03
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.
#1332 posted by mh on 2017/02/07 20:50:53
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
#1333 posted by mh on 2017/02/07 21:44:53
@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.
#1334 posted by Baker on 2017/02/07 23:29:26
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
#1335 posted by Baker on 2017/02/07 23:44:59
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.
#1336 posted by mh on 2017/02/08 00:07:49
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
#1338 posted by Baker on 2017/02/08 00:33:13
@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.
#1339 posted by mh on 2017/02/08 00:33:51
QuakeSpasm, Fitz and MarkV are all the exact same so far as strafing is concerned. No difference whatsoever in the code.
#1340 posted by mh on 2017/02/08 00:37:43
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.
#1341 posted by mh on 2017/02/08 00:44:49
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.
#1343 posted by Baker on 2017/02/08 00:53:03
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
#1344 posted by Baker on 2017/02/08 00:58:09
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).
|