It is definately risky to run light before vis, and I think that might be the source of your problem.
The order in which one runs them doesn't matter. Both tools create individual data and store them in the BSP - they're independent from each other.

Ron: it seems as though while you're using the new TreeQBSP, it's still the old LIGHT and VIS tools that come with Worldcraft? If that's the case, switch to the BJP ones and see if that helps. 

They aren't too high or anything. There's still plenty of room for new stuff. TreeQbsp will tell you if the map exceeds any of the BSP limits. 

in a map can screw up the vis process. Maybe im going mad! :)

Ron: Negkes right about the tools, use these tools:

http://www.quaddicted.com/tools/visbjp.zip

Also TreeQBSP is good, but I remember AguirRe saying that TxQBSP was better for some reason, TreeQBSP didnt compile sickbase IIRC.

TxQBSP:

http://www.quaddicted.com/tools/txqbspbjp.zip

:S 

I wasn't sure if I was using Bengt Jardrup's Vis and Light's so I downloaded them again. I also did run the programs outside WC in a Dos box, combining both your suggestions. And it worked fine ! The fast Vis worked and Light as well !
And a lot faster too ! Thanks a lot ! Really, I'm quite happy, I've been working so long on this damned map now, it would be rather sad to have to bin it now ... 

The only warning is a superficial one, and with 22000 odd marksurfaces/clipnodes it must be a fairly large or detailed map :)

This is a useful source of info regarding Quake 1 mapping tools, buy AguirRe:

http://user.tninet.se/~xir870k/tooltips.txt

try runnning the bspinfo tool on your map too see the limits and how close you are to them...

Also post some screenshots please :DDD 

"The order in which one runs them doesn't matter. Both tools create individual data and store them in the BSP - they're independent from each other."

This is my understanding as well. If anyone has any concrete information about why vis should be run before light, I'd love to hear it.

AFAIK, as negke said, they are totally independent of each other. 

You can do is alpha testing - send your source to an established mapper who's already had to battle through the compile issues, they'll be able to point out known issues.

The less time you spend banging your head against a wall and the more time inventing cool stuff the better.

Don't know how much time I'll have this week, but probably by thursday I can take a look if you want - my emails under 'people'. 

To Rick: I'll run the bspinfo tomorrow or later this evening, I'm now doing a full vis, it's at 47.19 % at the minute and I've still got an estimated 7h 44 minutes to go. I think I will kill some time (and probably braincells too...) in the pub ! As for screenshots, I'll try to get some of more or less finished areas later. I have still got to do quite a bit of texture alignments and stuff like that to do. I don't want to post anything that's just not quite, ehm, good enough.

To Ijed: Thanks for your very generous offer !
I really appreciate it, and, if the offer still stands and you have time, I will gladly make use of your expertise. But to be honest, at the moment I'm back in and will battle on until the next problem arises.

Thank you all. You've made my day ! :) 

for the vis to finish, it will slow down as it nears completion!
I once had a map which took 6 and a half days to vis. And JPL, well he's the current record holder........

It must mean that the map has some large areas in it with a fair bit of detail, or some tiny details in it, or that there are places where you can see through a lot of rooms from some angles.... 

There are some basic tips to follow like - if you have gratings make out of brushes, func_wall them because each hole in the grating is a portal and VIS will need to process it and all of it's children. Very nasty.

The same goes for railings, cages, barred windows, etc. 

The only drawback there is if you were counting on cool shadows to be cast. In that case, well, suck it up and eat the VIS time. :) 

That said, I'm surprised that someone hasn't come up with a version of light that would cast light from func_walls (optionally, of course). If you aren't going to be removing the func_wall at some point through a killtarget, it seems perfectly reasonable to use it as a shadow caster. 

Something for you to do next weekend... 

Good job on the tools Willem. Multiplatform ftw.

This is my understanding as well. If anyone has any concrete information about why vis should be run before light, I'd love to hear it.

Some of the light programs use vis information to do quicker lighting. I think Lord Havoc's tool does this. Not sure on bjp's.

Some tests seemed to indicate that bjp's vis does more effective culling than others, btw. 

That said, I'm surprised that someone hasn't come up with a version of light that would cast light from func_walls

This has been on my compiler wishlist for a few years, along with other stuff like self-shadowing bmodels, global illumination, minlight on bmodels, light contribution caching for fast re-lighting after small lighting changes, "manual vis" (as used in medal of honor), portal-based vis (a static variant of the portal visibility used in doom3), hard-edged shadows, cubemapped lights, shambler clip brushes (hull2 only), nonsolid brushes (hull0 only), etc. I have hacked up the compiler sources a little bit over the years, but never enough to produce anything finished enough to release. (seriously, not even finished enough that i could use it for everyday mapping.) 

Even if that were true, lighting is very rarely the bottleneck. I suppose it could be cool if you were wanting to do fast iterations on lighting or something though... 

I'm not familiar with how editors work with multiple WADs so as I add support for them into ToeTag, I'm going to have a few questions. Heh.

OK, so if you load up 2 WADs that have a texture inside of them with the same name, what happens? Say you load WAD1 and WAD2 and they each have a texture called BLAH -- what do level editors commonly do about that? Hold them both? Only use the first one they see? 

will show all of them in alphabetical order, and it will show two of any textures the same. So when I have a load of IDbase wads loaded there are often two or three of each of the common textures in a row on the display...... 

Excellent info, thanks!

OK, so how does the UI work for Worldcraft?

How do you load multiple WADs? How do you unload a WAD you no longer want (or can you)? Are you just editing the worldspawn key/values or is there an actual dialog box for it? 

Which brings up a dialogue with several tabs ranging from 2d diplay options, your build programs, and one of them "is textures". Here you find a list of your current wads and the options to remove any you have highlighted and to load other wads. You can load as many wads as you like,and they will appear straight away in your textures. Removing a wad from the list requires a restart.
You cant actually see any textures from here.
You get to see all of the textures whenever you enter "texturing mode" (or whatever they call it). If you enter texture mode via a button on the left margin of the screen. If you press the button with brushes highlighted then all of the faces of those brushes become highlighted. A 90 degree right angle symbol appears in the middle of each face to make it easy to see what angle it is at.
A small dialogue appears near the right of the screen with a picture of the current texture on it. Beneath the texture are all of you alignment buttons (left, right, mcenter, top, bottom, fit) and your integer fields for x and y scaling and x and y position, and angle. There is a button beneath the picture of you current texture to open a window where you can see all of the textures you have loaded, and select another one. You can narrow the textures being shown to you by typing letters in a sort of search field.

As for the worldspawn, you never have to worry about that, WC just adds the correct paths into the worldspawn whenever it exports its RMF format into a MAP file. Along with a nice annoying key "mapversion" which it gives the value "220" and you have to remove it manualy (unless you have the utility "nomapversion.exe") :P 

Oh OK, so it's a global setting and not set up per map. Alright, thanks! 

Suppose this won't work, but asking anyway:

A push that only works when being touched from a certain direction like regular triggers with an angle field? Perhaps with a movedir/angles combo, or bastardized use of trigger_push_touch? 

I was making some custom wads lately with the same textures in them and the BSP editor i'm using shows just one of them (a 2 frame animation). I was wondering though, has anyone been able to load a 512 by 512 texture in their editor? The biggest i got to see and use are 128 by 512, and 256 by 256. The wad i made with a 512 by 512 texture shows correctly in a wadviewer i got, but shows up as a 32 by 32 white texture in BSP. 

This is just as a heads up for anyone still using Worldcraft 1.6 (myself) and who has the latest nvidia drivers. Apparently, if your driver version is anything higher than 182.50, your 3d view in WC will look something like this:

http://qrf.mine.nu/~orl/misc/wc.png

However, enabling the hardware acceleration option will fix the 3d view problem, unfortunately that also raises the other problem of not being able to select any object within the 3d view.

Again, anything higher than version 182.50 of the nvidia driver will result in WC's 3d view going crazy, and essentially useless. 

you can make triggers only work from a specific angle!?