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) 

Not vis help, but general good building of the map.

For example putting a crate in the centre of the room on the floor or putting a crate in the centre of the room floating 2 units above the floor.

The second one is better (and invisible to the player) because it causes less subdivisions, which also helps compile time. 

 

 

As CZG so eloquently explained, while this will indeed reduce subdivisions of the floor, the saving in VIS time/polycounts will be negligble when compared to the creation of many tiny, tiny vis portals under the crate (which'll slow down you VIS a fair chunk, especially if done with every crate in a level (there should be as many as possible)) 

Fair point - I'll go back to my cave now. 

It's not dumb. It can lower the polycount considerably (depending on the area) and I doubt a few additional tiny portals will slow down VIS "a fair chunk." There's a more definite risk of ugly shadows beneath/around the crates, though.

However, speaking of poor VIS design: I'm now (again) stuck at a slow portal with no progress for a full week.