I think Baker's gonna need to make the judgement call on whether or not MarkV gets it, because it's pretty much all renderer front-end work. I'm 99% certain that the current back-end will support it without modification, but I'm willing to commit to any modifications that may be required should Baker decide to go for it. 

Just various random thoughts

1. Mark V has optional stain maps (defaults on), like FTE, which uses the lightmaps.

2. I'm sure you already have this one taken into account, rotated and moved brushes.

3. Here's a more complex one --- fullbright colors in water texture + software renderer :( This isn't necessarily as annoying as it sounds and in-engine conversion of a water texture's pixels from fullbright blue to non-fullbright blue at map load is likely an option. I guess I'll need to look at the textures/palette, I hope there isn't a fullbright blue without a non-fullbright equivalent.

4. Do non-supporting engines load lit water maps ok? It is sounds like they do, which would be an advantage.

5. Would be very helpful if ericw could mark the .bsp as having transparent water somehow to avoid the "don't know" scenario you outlined. One thought is inserting a worldspawn key "litwater" "1" (is this the best way to mark the maps? I'm not saying it is. But if lit water maps can be loaded in standard engines, at least this method does not require a new map format. But there could be a better way and this is just one thought, but avoids MH's "don't know" scenario.). 

Did a quick palette conversion test of the traditional blue water to a non-fullbright palette. It's fine. Non-obstacle.

Lava will have to be fullbright because the software renderer doesn't have a choice except to use the Quake palette, and there are no non-fullbright versions of bright red. 

I don't really have an opinion on lit water.
I guess it looks ok in those screenshots.

What I really wanna see is reflective water!
But r_texprefix_mirror doesn't seem to do anything when set to a water texture.... 

About corner cases:

- Winquake.exe seems to be fine with the example lit water map I posted.. it doesn't have a problem with liquid faces missing TEX_SPECIAL.

- The qbsp options "-splitturb" (and "-splitspecial" which is older) unset TEX_SPECIAL on the affected faces.

The main problematic case I can see is a face with:

- texture = "*water"
- lightofs = -1
- styles = {255, 255, 255, 255}
- TEX_SPECIAL is unset in the texinfo

Do you render that fullbright or solid black in an engine with lit water? I think it needs to be rendered fullbright; faces with those settings will exist in the wild if anyone ever used the "-splitspecial" qbsp option. It would be worth checking how Darkplaces handles this corner case since it's the first released implementation afaik.

So to fix this case, the light tool just needs to avoid writing those "implicitly black" faces for lit liquids. IIRC, mankrip requested that a while ago but it looks like I didn't implement it yet in my light tool. I think if I do that, we don't need any other kind flag to mark the map as using lit water. (presumably the engine should support mixing lit water and non-lightmapped lava)

- Other rendering stuff: imo fullbrights should be rendered normally (for fitz engines, respecting the gl_fullbrights cvar), the lightmap should not warp (I'm imagining it as a shadow cast on floating leaves that are swirling around; the shadow shouldn't swirl).

- Light tool stuff: there is already some handling in my tool that mankrip contributed; lit water faces can receive light from either above or below, and they don't cast shadows. This part I'm not so concerned about, it's easy to tweak with features as they are needed. 

Here's a more complex one --- fullbright colors in water texture + software renderer

That didn't even occur to me, but yeah - a GL/D3D engine can just not draw a fullbright, but software doesn't even have the option.

Rather than remapping I think if it was me I'd probably do an extra colormap.

Do non-supporting engines load lit water maps ok? It is sounds like they do, which would be an advantage

Not a problem. Most of the work is actually changing various cases of "if (surf->flags & SURF_DRAWTURB)" to "if ((surf->flags & SURF_DRAWTURB) && !litwater)" at runtime, so load time is fine.

Would be very helpful if ericw could mark the .bsp as having transparent water somehow to avoid the "don't know" scenario you outlined.

I think the don't know case was me being nitpicky more than anything else. It is possible but the probabiility is so low that I don't think you'd ever actually see it.

What would be more worrying is bad tools setting surf->samples for a drawturb surface in a map that shouldn't have lightmapped water, because that's really the only way you have of checking, but I don't know if such bad tools even exist. Either way, providing an r_lightmappedwater cvar that the user can set to 0 can help with that. 

Water with garbage fullbright pixels is a texture pack problem, as it always was with garbage fullbright pixels. I don't think it should be solved engine-side. That would only complicate things. 

Although not an official texture, *tele teleporter textures should probably be fullbright (not lit). Both Mark V and Quakespasm treat *tele textures differently.

dwere: Water with garbage fullbright pixels is a texture pack problem ... I don't think it should be solved engine-side

Sounds logical. 

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... 

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. 

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... 

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). 

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)? 

@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. 

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".