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. 

it's a decent idea. 

does fitz have capaibility to play mp3 music ?

My quake cd is getting old and in case it gets scratched beyond repair, I was wondering of an alternative.

Even if mp3 support is there, is it possible to load the mp3s automatically if they are named track02.mp3 etc ? 

i've had that on my list for a while. Someone said i should support oggs instead, becuase of patents or the GPL or something like that. Anyway, I haven't looked into it, but I ought to support some way of playing music off of the hard drive (either original tracks or replacement tracks that come with a mod.) 

same code as ezquake or fteqw was nice :) source is avaible for both clients to take a look! 

cool, just thought I'd check 

Nehahra has it's own music, doesn't it? Maybe you should implement whatever they use?

I comepletely agree on this one. My Quake cd is in mint condition, but I don't carry it about with me wherever I go so I tend not to have it to hand. I didn't bother to bring it to Japan, for instance. I do, however, have all the tracks ripped on my hdd :)

By the way, have you given any thought to having a different (or additional) protocol, such as the one used by Aguire's mappers GLQuake engine? 

Another vote for .wav and .ogg support in FitzQuake. If you do it, please use the same file naming system as used in Darkplaces, this will establish compatibility between engines. 

can we either have an option to toggle "wrote fitz0003.tga" or just have it print to the console.

Basically just so we don't get text in the corner of nice screenshots and don't have to wait if we want to take another shot after having just taken one.

Only a minor thing of course, but it would be nice.

Maybe there is already a command to disable printing messages to the screen and I didn't bother to find it :) .... 

You could try "con_notifytime 0", that disables the display of all messages there. A screenshot alias might look like this then (I haven't tested it): bind s "con_notifytime 0;screenshot;con_notifytime 3" (if 3 is the default) 

screen tint that is based on the average colour of a texture rather than the type of liquid.

Yeah, I've considered this one too, along with the wateralpha feature suggested earlier.

However, I've also considered an alternative to the 'average color' mechanism.

Use the color of only the first pixel of the liquid texture i.e. the pixel in the top left corner.

Why? The average method produces...well, an average, which may not actually be a representation of the overall liquid feature. It could be too bright or, more likely, too dark. Remember, liquid textures look bright because they are rendered fullbright. Whatever color is used for underwater screen tint will become darker because it is being blended with whatever else is in view. So a lava texture may appear scorchingly bright as the surface, but the average color produced from it may result in a submerged screen tint of only a muddy orange.

Using the first-pixel method would allow for the brightest color on the image to be selected as the screen tint. Any liquid texture could be modified by shifting the image across the canvas so the desired pixel was located at the upper left. This wouldn't make any difference to the appearance of the texture in-game, because liquid textures by neccessity are not affected by texture alignment.
A few variants of the same liquid texture could even be made, shifted about to place a different pixel from the same image in the top left corner and therefore each variant would result in a slightly different color of screen tint. 

slightly easier to code, and faster too ;) 

Before you get carried away, the "average color" idea isn't going to happen like that anyway, because there could be water volumes with multiple textures on their boundary, or volumes with none at all. I think if it was going to happen it would be RGB numbers that the level designer typed in (like the fog in the worldspawn.)

Oh, and liquid textures ARE affected by alignment -- at least in winquake. I can't remember if they are in fitzquake or glquake. 

-m_smooth sucks. It smooths the mouse without latency (m_filter 1 is famous for it's latency) at the cost of accuracy :(

Oh and impulse x y z requires no mod to the game code - your client is sent your .items and .ammo_blah information for the HUD. It's this info that impulse x y z uses to determine which impulse to send. 

(Is this the right thread for it?)

I often look into my /maps folder, pick some map, mark it, press F2 and Ctrl+C. This way I get the filename into my clipboard. Then I load up Fitzquake and type "map" followed by Ctrl+C and Enter. Well, Fitzquake tries to load mapname.bsp.bsp then.

Would it be possible that Fitzquake automatically recognises such .bsp extensions? Some other engines do it. 

I know this is probably wishful thinking, but would it be possible to make fitzquake available for other platforms than windows? 

Doesn't Fitz have a "maps" command that'll list maps? My memory is failing me at the moment and I don't believe I have Q1 installed. 

It would be a nontrivial amount of work, but I do appreciate that it would be "nifty." I think the best approach would be to port it to SDL. Since my girlfriend's G4 is now in the apartment, it's at least possible that I could do it and then verify that it really works. But this wouldn't happen anytime soon.

Spirit: i could probably do that, yeah. But try the "maps" command, like phait said. 

I know the "maps" command (which is pretty useless without being able to use wildcards like sm123* or blahsp* for example, because with hundreds of maps you need to scroll so much and scrolling is slow).

My request was not about finding a map ingame though. I just don't like typing complicated mapnames by hand and thus try to copy and paste them. If there were a map browser like in Joequake for example or mouse support for copy&paste in the console that would be incredible.
Quite not in Fitzquake's "realms" though I guess. Fitzquake's changes are subtle and that is great! Just sharing my ideas ;) 

I didn't know of the existence of this thread, but if possible, it would be nice in a future release if there were an NAT fix in it.

It could be borrowed out of the ProQuake source:

ftp://ftp.runequake.com/quake/engines/proquake/3.50/src/pqsrc350.zip

or out of Darkplaces. 

Having just got that visual c++ express thing to work, I had a little bash at getting fitzquake to compile, and then once I got that to work, I turned my eyes towards fiddling. First thing I tried was the model interpolation tutorial from QER(http://qer.planetquake.gamespy.com/news.html).

Fitzquake does the model drawing code a little different from standard GLQuake, so it took a bit of hacking to get it to work. Technical bit: Fitzquake eliminates the need for a variable called int lastposenum in the model drawing section, but the model interpolation code expects it and adds another one called lastposenum0. So I just added them back in, which isn't neat, but works...
It looks kinda pretty. r_int_animation and r_int_transform control the effect, default to on.

The other thing I messed about with was monster clip, people keep asking for it in their maps. Now, it would be a bit of a daunting task to put it BSP side, you'd need altered compilers and engines, and trying to do all this while keeping things compatible. So I went down the slightly easier route of adding a flag so monsterclip entities could be added.
FL_MONSTERCLIP = 8192;
Set this flag on an entity and it will only collide with entities that have FL_MONSTER set. This does exclude the world, so grenades with FL_MONSTERCLIP will fly through walls etc, it's intended for use with BSP ents.

The mod and map included demonstrate the idea. Walk through the big block of concrete in the middle of the map, it won't stop you, only the ogre. Won't stop his grenades either, beware. The block is visible for demonstration purposes, in a proper map you'd probably uncomment the line in the mod's code that hides the model. In theory you wouldn't even need a custom mod to achieve this, there's some kind of progs hack to make an invisble, solid BSP model right?

So yeah, take a look if you like, stuff can be found:
http://people.pwf.cam.ac.uk/~ajd70/fitzhack.zip