Does anyone know of textures for any game which fit the following criteria?

-Dark
-Mostly grey, black, white, not much color, but NOT brown or grimy (no steampunk or the like)
-must by tech, scifi oriented
-pipes and tubing a plus. ;) 

sort of like the stuff you see in startrek firstcontact with the borg. 

elite force, err elite force 2 :D 

avp, avp2 

i don't know how to get the textures out of avp2, tbh...

and i do have the demo of elite force. heh, never occured to me. :P 

never watcher startrek
bu check http://www.planetquake.com/speedy/textures.htm
maybe you could use them 

sounds like the Imperial aesthetic from Star Wars:
http://image.reserve.co.uk/www/public/images/ss00/big/jl/jediknight2-b.gif 

http://www.ravengames.com/jediknight2/screenshots3.php

The only color tends to be on the consoles and that's either red panels or blue text. 

hm... well, i might grab a couple of the textures from your set speedy, but i don't think i'll use the whole thing... it's a little too bright without enough pipes and techy stuff.

i think i'll stay away from starwars textures... they look like they only really work in the sw universe, and i don't want my map to become a starwars map... :)

what's the texture set that Killazontherun used for this unfinished map?
http://pipeline.fov120.com/shots/85_l3.jpg 

Is this them? http://www.ravengames.com/images/eliteforce/screenshots/eliteforce_shot-03.jpg 

majestic: http://shaderlab.com/slrl/?p=textures/sci-fi/majestic&o=1

some of evil lair's textures might match what you were looking for too, not that I really remember your description of what it was yuo wanted.... 

distrans: yep! i'm mapping a bit more dark then the guys who did the borg maps though...

cybear: thanks a lot! those textures look like they'll work well. 

...you might want to check out these as well http://www.q-fraggel.de/textures/textures.html

Hopefully not too much colour or grime, cheers 

but those won't go with the ones i've already chosen. 

those are ewww distrans 

So why does a tyrlite -extra compile take twice as long after a -level 4 VIS than after a -fast VIS? 

kthxdie 

The only reason I can think of is that you've exceeded TyrLite's vis capacity of 1.5 MB and therefore its behaviour becomes unpredictable.

This is most likely to happen after a fast vis since the vis data is less compressed then.

How big is the vis data after fast/full ? Is the behaviour repeatable ?

AFAIK vis and light are two completely separate things that can be done in any order without affecting each other. 

I just recompiled it (in the name of SCIENCE!) and here are the results:

VIS -fast:
visdatasize: 182827 compressed from 258120
Elapsed time: 0:27
TyrLite -extra:
141.0 seconds elapsed

VIS -level 4:
visdatasize: 72078 compressed from 258120
Elapsed time : 22:41
TyrLite -extra:
244.0 seconds elapsed

At 1790 brushes, the map is not even all that large, so I wouldn't think that I'm exceeding TyrLite's VIS capacity. 

Mail me the (unvised) .bsp and .prt files and I'll find out. 

One man's shit is another man's pate. 

Those vis sizes shouldn't be any problem at all. Just curious, did you rebuild from scratch (i.e. using qbsp) between those two tests ?

Otherwise the initial vis/light data lumps in the bsp are different in the two cases and may (although I can't see why) cause alternate behaviour.

Let's see what Tyrann finds out. 

aguiRe: Yes, I did a complete recompile between the two tests.

Tyrann: It's on its way. 

of two maps, using both my Light and TyrLite and none of them exposed this behaviour. I got the same timing after fast/full vis.

I'm interested what could be causing this in your specific map (or even possibly in your computer environment). 

Ok, I've run the two compiles and there's no difference here. My first suspicion is that this is something simple like a screensaver that comes on during the longer compile and saps CPU cycles.

Otherwise, it's more complex and other factors are involved. What vis program are you using? What's your OS version?