qbsp doesn't know what func_illusionary is, so it won't compile it any differently than any other bmodel. And, i'm pretty sure bmodel clipnodes do contribute to the total clipnode count. 

is there any way to trick qbsp into compiling the visual aspect of the brushes, but ignoring the colision part? so like, a bunch of ghost brushes? 

no, but in theory, qbsp could be modified to have that feature. 

nonono... thanks for the info though.

a clipping we will go, a clipping we will go... 

ways to modify qbsp hull processing for testing purposes. To get the effect that necros mentions, use the option -fill to make qbsp force fill the clipping hulls even if they leak. If they leak, they will be practically removed and you'll have to noclip to move around in the map.

This is especially useful in large maps that leaks, because otherwise the bsp probably wouldn't load in any engine. Please see readmes and ToolTips for more details on this issue. 

I often use your bspinfo tool to create .prt files when I have map leakage. I have never known it to fail to create a loadable map, even when the raw bsp (only qbsp used in the process I mean) wont load.

In fact some of the minor leakage issues wont even effect the size of the map to any substantial degree when a full -vis is done using your tools.

A big thanks for your setup while I am at it. 

I have a series of func_trains. As soon as the first one lands, I want the second one to go, and as soon as the second lands, I want the third to go, etc.. The only way I know of to do this is to measure the distance each train will travel, compute the number of seconds it will take, and then use trigger_relays with "delay" "x". That doesn't seem too bad until you realize that I have seventy-two trains.

So, any suggestions as to how I could do this in a simpler manner? 

Go work you lazy hippie! 

If you have leaks and still want to force a prt file for vis (not recommended though), you can use option -leak 3, i.e. only generate pts file for leaks in hull 3 which doesn't exist.

If the leak is in hull 0, vis processing time will most likely be significantly extended, since the entire outside of the map is also in the prt file.

I'm glad to hear you like the tools. 

the only thing i can think of involves custom qc. custents and hipnotic (i think) have new train code, lets you change speeds at different path_corners, fires targets when trains reach certain corners, and lets you set a 'duration' instead of speed, so it will take 'duration' amount of seconds for the train to go from the one corner to the other.
but no can do with normal quake...
and 72 func_trains? just... wow... 

I finally got my Orb and Stegosaur in Quake1 by managing the progs.dat with frikbot.

I got their health and dmg settings up, and to my surprise I could also change the intermission txt between the sequel.
Yes great!

But...
I suddenly got all levels on gravity 800, and I don't know what I done wrong. I used to seek it in World.qc but left it because it wouldn't archieve result.

What's gone wrong? 

I found it, there are several world.qc

Has anyone ever succeeded in creating a Q1level with the habbits of e1m8?
Looks a good speedmap theme to me. 

<pre>fdsfsd
sdf df</pre> 

if (self.model == "maps/e1m8.bsp")
cvar_set ("sv_gravity", "100");
else
cvar_set ("sv_gravity", "800");


that's the lines involving the gravity stuff, just change it to this:

if (self.model == "maps/e1m8.bsp")
cvar_set ("sv_gravity", "100");
else if (self.model == "maps/##YOURMAP##.bsp")
cvar_set ("sv_gravity", "##SOMENUMBER##");
else
cvar_set ("sv_gravity", "800");

and replace ##YOURMAP## and ##SOMENUMBER## accordingly.


ps, no preformatted text? bah. :P 

. 

Will try it as soon as possible,
thanks for the hint!

using several world.qc documents made my Quake engine somehow drunk... 

Hi!

I just got GTKRadiant 1.4 working the other day, and I'm using texmex for textures. There's one problem I've ran into. When I export textures from .wads the *water/*slime/*lava textures etc are renamed to #water/#slime/#lava because you cant use * in filenames.

Naturally when I compile the map the compiler cant find any #water texture in the wad cause its called *water there. Any suggestions?

And btw, isn't it time soon to make a new mappinghelp thread? I only refresh this thread every time I go to take a shit, cause it takes an age to load. No broadband. 

use proper wadconverter that will convert all the wads to tga and back:
http://www.orbiter-productions.com/alchemy/#qonverge

and use proper mapconverter which u can get here:
http://rem.fov120.com/rem/projects.projectDetails.action?id=3

and kay, log in properly, in this case you'll see only new posts. go to account section and register there... 

Necros, it worked...
many thanx from a spacewalker! 

Kay: use gtkradiant spogbranch, it doesnt require you to convert the textures to tga 

Would it be possible to modify a light util to create higher res lightmaps for surfaces? I understand the lightmaps are currently generated on a 1:1 ratio to texture resolution, would it be possible to increase that to a user specified ratio such as 3:1 4:1 etc... ?? 

To do that, you would at the very least need compiler support (light.exe) and engine support.

To make it a per-surface property (like in medal of honor and other games) you'd need editor and qbsp support, too.

However, a hack that would work in most custom engines is to build the map with HIGH-res textures, with texture scale set to 0.5 or something, and then include LOW-res .tga replacements. This would effectively increase the lightmap resolution.

P.S. Lightmaps are at a 1:16 resolution to textures, not 1:1. 

well no wonder no-one has done it already then... :)

Would be great if it did become possible though, re-lighting all my old maps to see the changes would be very cool. 

At 1:1 ratio would not every pixel in the textures be sampled in, and would not any ratio level above that be redundant? Just my guess (hey, those old tutorials on flip-code have to sink in somewhere). 

when i say 1:16 i mean that one lightmap sample covers a 16x16 texel area.