short of not inventing a time machine, a stasis chamber, and a chemical harmone inhibiter that prevents girls from turning ditzy at the age of thirteen, I don't see how it is my fault. 

It is not your fault.. it's teenagers in general

I also have to agree it's sometimes very difficult to keep girls to go away when they decided to... *sigh*... 

When pressing tab for autocomplete, how about pressing it again to cycle through the list of returned entries?

I am always typing no.. for notarget and getting noclip and having to delete clip and at a t. The same thing happens when dealing with r_show/draw type commands. I suck, fair enough, but it would be a nice feature to add, no? 

FTEQW is awesome in that particular function. 

Since Than started this recently, I'm gonna stick my oar in too:

Liquid Textures And Wateralpha

Pardon me if this has already been consdiered or I'm ignorant of some engine limitation, but I hereby submit a useful feature request:

*lava~ and *teleport ( and, if you're feeling charitable, *starfluid :P ) are always rendered opaque, irrespective of r_wateralpha value.

*slime~, *water~ and *~ are affected by the r_wateralpha command as normal.

Additionally, would it be possible to have the key "r_wateralpha" or "_wateralpha" or "wateralpha" read from the worldspawn, in the same way as "sky" and "fog"? That way, the wateralpha will be as the mapper intends when a map is loaded, though the player can still change it via the console if they prefer, again as with sky and fog. 

Doesn't fitzquake already do this? When I type "no" and then press tab multiple times, it cycles through all the commands that begin with no. Unless I've misunderstood what you're requesting... 

yes, fitzquake already has tab cycling.

no, *lava and *teleport are inluenced by r_wateralpha just as any other liquid (if the map was compiled to support transparent water, that is). 

than: it should already cycle, unless there's a bug. You can also do shift-tab to cycle the other direction.

kell: that specific implementation would be sort of hacky, but not hugely difficult, however, i'm worried about all the exceptions that i might need to make down the line for various maps where 1. water texture names are nonstandard, 2. mappers intended lava or teleport to be transparent for effect. There's no way to consistently know the intent of mappers in this case, as existing maps were built assuming all liquids were opaque or all liquids were transparent. This is the sort of hack, incidentally, that people get so mad at other engines for -- a "feature" that assumes too much about the content.

A worldspawn key sounds pretty good, though. 

ok, nevermind my post. i misunderstood what you meant... 

about the wateralpha key, can you make that seperate from the cvar wateralpha?

ie: your cvar for wateralpha is set to 1 (for opaque) but you load a map with 0.3 set in the worldspawn. that map has it set to 0.3, but when you load another map that doesn't have any key in the worldspawn, have it set back to the default cvar value.

is this possible? 

1. water texture names are nonstandard

You mean anything other than *water~ ? Doesn't matter, anything other than *lava and *teleport would be the same as it is now: affected by r_wateralpha.

2. mappers intended lava or teleport to be transparent for effect

Well *teleport isn't a problem, since a mapper can always use any texture they want for their teleporters and just give it a name other than *teleport.

Lava is an issue because *lava also has the hardcoded hazard effects. So, yes, if a mapper wanted a lava hazard but also wanted the texture to be rendered translucent they'd be shit outta luck.
But I don't think that's a major drawback because the number of maps I've encountered where the mapper intended translucent *lava ( or, for that matter, translucent *teleport ) I can count on the fingers of no hands.

Conversely, there are plenty of maps where translucent lava and/or teleporters looks cack and can make features harder to see.

A worldspawn key sounds pretty good, though.

Indeed. 

Why don't you just bind keys:-

bind "a" "r_showtris 2"
bind "b" "r_showbboxes 1"
bind "c" "r_drawflat 0"
bind "d" "r_drawflat 1"
bind "f" "r_fullbright 1"
bind "g" "god"
bind "j" "r_drawviewmodel 0"
bind "m" "r_drawviewmodel 1"
bind "n" "noclip"
bind "o" "r_fullbright 0"
bind "t" "notarget"
bind "v" "r_showbboxes 0"
bind "z" "r_showtris 0"

or such like? 

alias m "exec mapdev.cfg"
and put those above in the mapdev.cfg config.

then just type m in the console when mapdevving. 

didn't realise it worked already. I am sure I tried and it didn't work. Guess I will try again and if it doesn't work, then it must be a bug. 

try using the commands "toggle" and "cycle" to reduce the number of keys you have to bind.

bind r "toggle r_speeds"
bind f "toggle r_fullbright" 

Thanks metlslime. 

kell: i'm primarily talking about breaking old maps, in which case the mapper already chose the texture names.

necros: I'd want to keep it seperate from the cvar, but on the other hand, the player could want to override it the alpha during play, and in that case suddenly the cvar has to be able to cancel out the worldspawn key. 

did you ever get the second email I sent when you were on vacation ? 

yeah... i just haven't done any fitzquake stuff since then. 

just wondering 

How about having textures always render opaquely if they are prefixed with _forceopaque (or whatever)? That way you get control over teleport transparency without messing about with r_wateralpha at all.

You could even pass transparency values in the texture name (_opacity100), although that has the downside of potentially requiring a map to be played in FitzQuake x.xx to appear as intended. 

But whatever. 

-disabled screensaver and windows-key(s)
-model interpolation
-cosmetic: better crosshair(s) and I have always liked the v_models for projectiles in Tomazquake 

From the Masque of the Red Death thread:

Aguire: It won't run in any engine that doesn't use a modified Q1 protocol. It's not the amount of entities as such, it's the amount of unique models that are >256. But even if that was fixed you'll need bigger packets as well, otherwise you'll just end up with SZ_GetSpace errors and massive packet overflows. And there are other limits that need to be extended too ...

So, is it possible more limits could get bumped up in Fitzquake? Fitzquake is the only super-prime Quake engine available, and I want to be able to play all maps - even stupidly huge ones with it. My currently in development map may possibly also require such limits to be extended*, but I don't know yet. I don't want to have to run it in a regular GL engine with crap waterwarp and no overbrights.

There are other good maps that have errors (but run) in FQ. I think Marcher has some minor issues in the massive combats near the end, and there are some errors at the start of moonlite before business as usual.


*it's not a huge horde map in case you are wondering. 

I was just wondering if it would be possible to implement screen tint that is based on the average colour of a texture rather than the type of liquid. This is so that if you have blood, custard or whatever as water in your map, it will look more natural when underwater.

This could be a cvar, or worldspawn option.