ijed: Just as any new map is appreciated and looked forward to. Keeping you informed about the process is actually a double-edged affair, since it kind of renders me as a fool for going through such a hassle for so little gain, both in terms of VIS results and the quality of the map - which is not to say it sucks, but it got out of proportion some 500 hours ago. :D

necros: Keep in mind the time esimations don't stay constant throughout the whole process. If it says 1300 hours in the beginning, you can bet it'll go up dramatically at a later point and especially towards the end. Better add a digit. 

yep. i'm currently running a test with vis -level 1.
if that's enough to keep things smooth, i can stand not having super accurate vis calculations.

there's something wierd though, because i seem to be getting strange behaviour with the timer.
elapsed time is incorrect saying 34 minutes when it has been running for over 2 hours...
the estimate at level 1 is only 3 hours, but if the timer isn't working, than likely nothing it's outputting is correct... i'll see what it's like tomorow, i suppose... 

But this is a big negke space map. 

maybe the elapsed time readout is based on actual cpu tics used for vis, not real-world elapsed time? 

i doubt it because that doesn't really make any sense for aguire to code it that way. besides, i've used his vis for lots of maps and never had anything weird like that happen.

trying again with -level 2 and it seems to be working properly now. 

I put one texture on all brushes in the map, "wad" = "knave.wad" in worldspawn, and still this:

*** ERROR 37: Failure seeking to 471762432 in file knave.wad

I imported the whole map into a new file, and still the same. I even tried on a completely different map. If there are no wadfiles in worldspawn, it will compile. If there are valid wadfiles specified, qbsp will fail. Either there is something really fucked on my end, or there is a problem with the Mac port. Sorry to bother you all, I'm gonna go bawww at Willem now. 

If that WAD file is loading into your editor correctly then there's no reason it shouldn't work in QBSP. Weird. 

Which editor are you using ? 

it's gtkradiant 1.4 on mac os x 10.4. I convert the map file to q1 format with sleepy's java map converter. I would be using Willem's excellent Toetag, but it rendered my stupidly big map at molasses speeds on this old hardware.

In qbsp's source code, warnerr.h, I see that there is an "errSeekFailure" which is obviously what I'm getting. When and where would this be called?

I've tried several wads, most straight from quaddicted and a few I've assembled myself, all giving the same error.

Actually, I just had the horrifying thought that it could be failing to seek because my hard drive is dying. Yikes. Though I haven't noticed any other similar problems. 

Oh, I didn't realize it was a Mac port. In this case you, can put all the blame on Willum. Is there any other compatible QBSP you could try, perhaps with a Windows emulator? Doesn't MacRadiant save to .map or why do you have to use that converter? 

Indeed, the editor is not relevant, however for some reason, sometimes during .map generation, it can generate weird stuff.... anyway, the fact it is a Mac porting is certainely the issue.
You may should try with TxQBSP instead, or move to a PC... :( 

The fact that it's a Mac port should actually have very little to do with it. I use that version of it all the time and it works fine for me. I can't imagine what the issue is here...

Definitely try another version of QBSP and see what happens. If it's my fault, that's fine, I'll fix it - but I'm having a hard time buying it at this point in time. :P 

 

Grahf

Email me the MAP file and the WAD you're using (preferably something reasonably small) and I'll try compiling it myself. Should be easy to track down what's going on... 

 

Ahh OK, grahf has a PowerPC machine. I don't believe these tools are set up for big/little endian swapping. I believe the tools are currently Intel only.

I'll put that on my task list. :) 

I had a feeling that might be the cause of my problems. Thanks for looking into it anyways. 

I'm working on it. It might be easy and it might not be. I'll know more by the time the weekend is out. For now, you could compile in a Windows machine by using Parallels or something ... or just use a regular version of QBSP for now. 

I have a door but the angles 135 and 315 don't seem to work. Am I stupid ????

And how can I make a trigger that makes another trigger operational? 

1. not sure, can't say i recall having any problems with those angles.

try 134 and 314? could just be those specific angles or the door could be linking with others. check that each door's bounding box isn't intersecting another.

2. short answer, you can't.
long answer, you can.

make an info_notnull but as a brush entity. (make it a trigger_once and rename classname to 'info_notnull'.

make a 'think' key and set it to InitTrigger.
make a 'nextthink' key and set it to '0.5'
make a 'use' key and set it to 'trigger_once' or 'trigger_multiple'
now set targetname.
set up any other relevant stuff like message or delay or whatever.

when you trigger this thing, it will turn into a normal trigger but will not do anything before. 

1. 134 and 314 don't seem to work properly either.
I uploaded a testmap where I have this problem:
http://www.quaketastic.com/upload/files/misc/door.map.zip
2. Thanks I will try that :) 

try fudging it by giving the broken doors negative 'lip' values. 

That seems to do the trick :) 

you know what would be wild?

make a program that will load a bsp file that has had it's vis information calculated and somehow allow you to manually set which portals are visible from other portals. 

make a program that will load a bsp file that has had it's vis information calculated and somehow allow you to manually set which portals are visible from other portals.

Pure nightmare !!