News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread: http://www.celephais.net/board/view_thread.php?id=60097
First | Previous | Next | Last
RPG 
Mail me the (unvised) .bsp and .prt files and I'll find out. 
*Shrug* 
One man's shit is another man's pate. 
RPG 
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, Tyrann 
aguiRe: Yes, I did a complete recompile between the two tests.

Tyrann: It's on its way. 
I Made A Brief Test 
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). 
RPG 
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 And OS Versions 
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. 
Just A Farfetched Idea 
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 ? 
Re: Just A Farfetched Idea 
Always suspend is unchecked, and Idle sensitivity is set in the middle. 
That Seems OK 
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 ? 
Err, Whatever 
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). 
Maybe We Could Wait 
until it becomes a real problem ...

If you like to update, there are new versions both of Tyrann's tools and mine. 
Okay 
I've upgraded all the compilers (TreeQBSP, VIS, and TyrLite) so I suppose we'll see if the inconsistency continues. 
RPG 
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. 
You Could Try 
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. 
Right 
Will do. 
Bitch 
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) 
Speedy, 
what map editor are you using? it could be the program is fucking up the target/targetnames or something like that. 
 
readup - bsp
all the links look fine in the editor (you know it draws the lines) and I even hand-checked the map in the notepad - all targets matched. 
The Same Old Question 
im pretty sure everyone has asked this, so here it goes. does anyone know of some ass-kicking q1 textures?

see, today i wanted to start a new level but well, had no ideas with the original quake textures... so yeah.

thats it. 
Textures 
Astonishing Panoramas Of The Endtimes 
YAY! thanks dude. hehe. 
Re: You Could Try 
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.

aguiRe: I've been using the -nocount option lately, and it seems like the light times are more consistent now. The -extra light after a fast vis has been approximately the same since I started that, and during the full compile I just did TyrLite took about the same amount of time as during the -fast vis compile.

Again, since it appears to be more unpredictable than I initially thought, I have no idea if this actually means anything. 
Not The Point 
...if it takes two minutes or four. What matters is; did it or did it not crash and delete your porn collection? 
First | Previous | Next | Last
Post A Reply:
Name:
Title:
Body:
message
question
exclamation
idea
flame
noflame
error
skull
beer
moon
pent
rocket
sheep
pacman
pig
cheese
worldcraft
gauntlet
crate
pitfall
pimp
smile
cool
sad
frown
oi
yay
tongue
evil
wink
neutral
q1
q2
q3
ut
hl
cs
doom
dkt
serious
cube
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.