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? 

Vis 2.15 by Bengt Jardrup

Win98 SE 4.10.2222 A

Note that I have screensavers disabled, and there were no programs open during one compile that were not open during the other (I believe it was just Windows Explorer, MS-DOS Prompt, AIM, mIRC and WinAmp, and WinAmp was not playing anything during either compile). Also note that I noticed this happening at least twice, so it's not just a specific incidence.

When I get a few minutes, I'll do a full and fast compile using the BSP and prt I sent you, since before I did a complete recompile. 

If you open the Properties for your MSDOS Prompt in Win98 (the shortcut you're actually using), go to the last tab and check the settings for Background and Idle Sensitivity, what's their status ? 

Always suspend is unchecked, and Idle sensitivity is set in the middle. 

If you wish, you could send me the zipped map+wad (I'll rebuild it myself) so I can see if I can repeat the symptoms here (I've got both Win95 and XP). I think Tyrann's running W2K.

What TyrLite version are you using ? 

I'm using TyrLite v0.92

...you could send me the zipped map+wad (I'll rebuild it myself) so I can see if I can repeat the symptoms here (I've got both Win95 and XP).

TBH, I'm not that concerned about it, but I understand that you might just be curious as to how this is happening. So, don't obligate yourself to trying to figure this out, but if you want me to, I'll send the .map and wads (I don't mind). 

until it becomes a real problem ...

If you like to update, there are new versions both of Tyrann's tools and mine. 

I've upgraded all the compilers (TreeQBSP, VIS, and TyrLite) so I suppose we'll see if the inconsistency continues. 

Ok, I tried on Win98 as well, and using aguirRe's vis tools. I still can't reproduce it. Wierd. 

Well here's an interesting turn of events: I took the .bsp I sent Tyrann and compiled a fast vis and extra light. Afterwards, I replaced it with the unvised and unlit .bsp again, and did a full vis and extra light. Lighting after the fast vis took 224 seconds. Lighting after the full vis took 121 seconds, even though I had the same programs open.

I don't see what I could be doing that would cause light to take twice as long.

Anyway, it doesn't really matter, and apparently it has nothing to do with the compilers since it goes both ways. 

the "-nocount" option in TyrLite to see if it's console window related. In Win9x, the interaction between 32-bit console apps and the actual console window is a complex beast. 

Will do. 

sometimes my trigger-door-whatever setups stop to work, even tho I dont change them.

Have to delete and reconstruct to make them work again. ftw ?

bsp, treeqbsp by aguirRe, normal bsp compile (not onlyents) 

what map editor are you using? it could be the program is fucking up the target/targetnames or something like that.