I think he's on inside3d but I've never actually talked to him. 

Uhm, edit worldspawn in WC or a text editor and add "wad" "..."? 

It means that worldspawn will point onto a single wad file... But unfortunately, when you use different textures from different wad files, you will have to concatenate it before it works... hence more work...

Other solutions is to use a proper editor: QuArK owns this very well you know.. I guess it is the same for other editors ;)

So rather than editing the worlspawn, I would suggest to run the compiling processes from the editor itself, that may embed the proper wad generation with the necessary textures... safiest way to go I think ;) 

Editing the field manually, you can still have it point to multiple wads. And WC was one of the first editors to support this.
I assume the textures show correctly in the editor, so what if it's indeed some Vista issue? Maybe simplifying the paths could help. 

Dunno actually, I've never tested such feature, manually at least... I'd rather prefer to stick to something I'm sure it is working ;) 

One thing is very bad about Quark's texture handline though. It re-renders all the textures each time you open the texture browser. And it does not let you properly use it during that. This means that you will have to wait several seconds (for bigger wads) until you can select a texture. 

Spirit put file links... mine is fast... 

and i always have lots of wads instaled! 

key "wad", value "wad1.wad;wad2.wad" in worldspawn, put all the wad files in the same folder as the .map/compilers. Like negke said, it'll eliminate the possibility of it being misread paths...

(And manually specifying wads is a breeze compared to using an editor that has features you require missing (or has undocumented 'features' you'd rather avoid ;) 

) 

What is with me and the slow portals all the time... 

Thanks for the help. Seems like I can add a "wad" key but the value field isn't long enough to fit the path of more than one wad! Even so, the .map file gets generated with another (presumably worldcraft-generated) wad key, with all of the .hlwads in it, which is clearly wrong.

So how can I get worldcraft to generate the correct .wad names instead of using .hlwad...? anyone? 

Text editor then. No idea how to change it permanently. 

In WC go to Tools\Options\Textures Tab and add the wad files you need. They will show up in the map files automaticaly. Compile should work without problems. Maybe you have too long paths to the wads also. 

This is really dumb - I've had exactly the same setup working perfectly well before.

Ankh - I'm using WC3.3, so I have to specify .hlwad files in it - which are obviously incompatible with Quake. I thought that the quake adapter did some magic so that at compile time it would re-insert the correct wads, but apparently not (or at least, not in my case). 

Because it's pretty direct what happens with WC.

But it's fucking irritating when things don't work as they should.

You should have a folder inside WC called textures with all your wads in there. Inside the editor you go to tools/textures and add the wads that are inside that folder manually.

And you're good.

Tech support isn't easy across a forum - but that should set you right.

The adapter does nothing magical, it's just a collection of tools - most of the legwork is still yours, so patience and experimentation is needed. 

Quake does accept HLWAD - but worldcraft 3.3 doesn't accept wad. It's a big hack, but it does work, at leaast until the tex conversion tool refuses to do the business. 

I'm still working on my map, but when I run it true the Fitz or aguirRe engine with a fast vis only, it runs smooth as can be. Is full vis still necessary in this day and age ?

Another thing, if you get the "Excessive static entities" warning and just ignore it, do you get any real problems ? I don't care about warnings, but are there any consequences ? 

it's a choice you make. if you go over limits and get warnings in fitzquake, then you have to accept that it won't run in some engines.

as for full vis, my opinion is that it's just sloppy not to full vis. it's free performance, since not everyone has a monster machine and the quake engine becomes a lot less efficient at drawing stuff. the performance loss is not linear. 

I agree. It's a basic level designer skill to be able to seal your map and get a good VIS. And necros is right that it's not a linear thing - without a VIS, you're drawing the entire level with tons of extra lightmaps to boot. 

OK, thanks.
I thought it only had to do with speed, so gameplay doesn't become choppy. 

Speed is a large part of the reason but there are other concerns, yeah. 

There's lots of ways to build a map where full vis doesn't have to take weeks. Level of brush detail, turning details into func_walls, making LOS blocking 'doughnut corridors' putting clip brushes inside small holes and so on.

Its finnicky stuff to do, but it makes the map very easy to compile - which is important for betatesting, since not everyone has a powerful machine as mentioned. Some might be emulating in Wine or have other issues.

My Quake machine will have trouble on non-fullvised maps, for example - a decent incentive to keep my maps well built. 

"putting clip brushes inside small holes and so on. "

I don't see how this would improve VIS times. Clip is a collision thing while VIS looks at the rendering side of things, right? If you meant plugging up holes with solid brushes then, yes, that would help... 

the consequence is that some static entities wont appear in game (like torches and stuff)

AguirRe's engine should tell you how many static entities you have and what the limit is (256 IIRC)

Take some out and replace them with other light sources (i.e. light textures)