I don't have Quake3 :-( 

lots of nice, and smooth flames in duke3d. 

try that out: http://www.planetquake.com/necros/temp/d3dflame.spr 

the flames in marcher? or was it bastion? those were big and looked good. 

sprites, nevermind. 

Good stuff, thanks necros. 

there are a few other varieties, btw. i think at least 1 more, but it is thinner/smaller.

also: the size of the flame in d3dflame.spr has been modified so each from has a ^2 size, so it works with glquake without looking bad from resampling. if you find other flames, i'd advise resizing them like that too.
and make sure you have it so that it is aligned at the bottom of the frame, and not the top. one of the frames is 64x64 instead of 64x128, so if they are aligned from the top, the flame will jump around. 

What's the inverse function of func_pwn? Does it return the input value of the original post?

Original post should have been: Nearly-black-and-white- but-with-some-yellow-and-green Quake. 

I know where RPG is coming from, and I'll say it's partially intentional, but on close inspection it could do with some fixing as well. The idea was to make the palette by changing the hue of each colour while fixing the saturation and luminocity of each colour. But just doing that uniformly might end up merging colours together frequently, so I added a bit of noise to the hue, so it varied. That was the plan anyway, and I stick by it that much.

However, some of the variations were a bit extreme, there were a few rows that preserved their original colour too much, so I've now changed that. Another problem was that some of the darker entries were altered with...less care than the brighter ones. It's not very obvious in the palette editor, but if you have the brightness high enough in quake then you can notice these pixels. These have been fixed too, so there's a version with these changes at
http://www.btinternet.com/~chapterhonour/noir.zip
I've also had a go at doing one where the palette is all one hue, and it doesn't look as bad as I expected. However, if you look carefully there are still visible colour differences, because the palette is stored as RGB not HSL. Anyway, you can also try that out and see if you prefer it:
http://www.btinternet.com/~chapterhonour/noiralt.zip 

i go to place a monster (the first entity i've placed since i started the map) and as soon as i deselect it, it disappears...

i go to check in game, and the guy is indeed still there, but he doesn't appear in the map editor in any of the views, 3d preview or 3d realtime preview...

func_s appear still, and toggling the 'show entities' will make the func_s disappear, but doesn't seem to make the other entities like monsters, items and mapobjects appear at all...

i went to check in other maps i've done with entities in them, and in those maps too, monsters, items and mapobjects don't appear at all...

to make matters even wierder, in OTHER maps BESIDES the current one i'm working on, if i toggle 'show entities', func_s and lights disappear, but monsters, items and mapobjects appear! and toggling 'show entities' again, will reverse the effect!! BUT, in the current map, toggling 'show entities' does nothing except make func_s and lights disappear and reappear... o.0

anyone working on d3 maps ever encounter this? did i just hit some button or something--? because this is just wierd... and a little annoying. :P 

does he reappear if you turn off realtime lighting preview? 

Using D3Editor? Toggle CTRL+M (hide / unhide models) 

Which will kill your settings, but you should see models again. Until the next time they disappear.

Don't ask me what's going on there, I have no idea. 

it was ctrl+m ^_^ thanks, friction. :) 

That seems to be about the same as before. Turning the brightness all the way up made it more like shades of gray, but of course that made everything really bright and not very noir like. 

Yeah, the sepia colour is intentional, to make it look like old film rather than strict black and white. Proper black and white would be easy to achieve, and wouldn't have the problems of slight dithering/off colour pixels. You'd just have to desaturate all the entries in the palette. 

With some luck I have found an easy solution today. I can't remember to ever see it in this thread so I want to share. The "Remove Brites" functionality in TexMex is buggy and it doesn't work even if you uncheck the "Use Full Brites" option in the preferences/workspace tab. But you still can remove fullbright pixels in TexMex easily. Here is what I did. I unchecked the "Use Full Brites" option, opened the wad file with fullbright pixels, opened a new wad, copied all textures to the new wad. That's all. Fullbright pixels are gone :). I hope I could help anyone. I had many many problems with this issue and couldn't find any easy solution for a long time. 

does have a lot of issues, but it's pretty easy to work with for the things it actually can do.

I just recently managed to figure out why TexMex often seem to have problems loading the conchars texture in gfx.wad. Ugh, what a mess ... this also explained why several modern engines (e.g. DP) have problems playing the OUM pak. 

As all the textures in a set are not polluted by "fullbrites", I guess correcting fullbrite pixels in a texture can be done as describe below:

- Load the wad file in TexMex
- Select the polluted texture
- Use remove fullbrites command (fullbrights appear then as red-purple pixels)
- Export it to a bmp file
- Remove it from the wad
- Open the exported texture with an image editor, and change the fullbright pixels in whatever color you want (normal pixels is prefered !)
- Import the corrected texture in the wad
- Save the stuff and validate the changes by a test in-game

I've done this many times, and even if it seems very long, it works fine.. and you really manage what happened...

Nevertheless, thanks a lot for your tips, it might help for massive fullbrites removing ;) 

Try it out my way. It takes 5s to remove all fullbrights. You can also copy affected textures only to new wad but it will take more time since you have to look up the old wad for them. The whole export and edit part is skipped. 

I beleive you man, don't worry...
I started a map (1 month ago, in paralell with other tasks..) using DKT2 texture sets, and most of them are white, so here I will need massive conversion... So I guess I will try first your method... :) 

I've searched Mapping Help (via the Google sitecelephais.net-board idea) but can't find the answer:

what are the max verts allowed on a static (no animation) model?

I've probably asked this before but as I keep reminding myself, time dulls the... the... er... um... hazelnuts, Bob. 

1000 to be compatible with every engine. Strangely enough it was originally 2000 in dosquake/winquake, but glquake only support 1000 - maybe back in the early days of 3d cards 2000 a model was considered just too taxing. It's possible that the released source codes reverted back to 2000, but if you want to be compatible with everything that doesn't help. 

it's 1024 to be exact. But I think pretty many engines have raised that limit to at least 2000 (same as WinQuake); Fitz, DP, my engines, Joe, Tomaz ...

Shouldn't be a big problem.