News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread:
First | Previous | Next | Last
I'm happy you seem to be able to use 1.5 easily (personally I consider it unuseable after earlier versions). But the simple fact is, some tasks take longer or take more steps. It was unecessary to change the brush manipulation stuff (if it ain't broke, don't fix it!). The new brush controls might make it easier to learn the editor or might make it more comfortable for maya/wordlcraft/whatever users to adjust...

...but for experienced radiant users, it just plain sucks. What GtkRadiant had over other editors was the sheer speed and efficiency with which you could manipulate brushes (create, re-size, edge & vert manipulation, etc).

Once you get used to it, you'll be just as fast as you were with old style radiant.

Its simply not true. In 1.5.x, you drag and edge or a vert, you have to select the brush, then turn on edge/vert mode, then select the vert/edge, and then drag it. In older versions, you just select the brush, hit edge mode and drag the vert straight away. 1.5.x adds the unecessary step of having to manually select the verts you want to move before moving them. Therefore it will always take longer to perform basic operations like dragging verts and edges. Therefore mapping time increases substantially over the course of a project. The sole benefit that the new 1.5 method brings is that you can select more than one vert at a time to drag... but considering you probably only want to do that at most 1-5% of the time, you lose more time than you save.

Basically all the new brush manipulation stuff is pants. Most especially the texturing. OMG having to select the brush, then hit face mode, then select some shitty handle on the face you want, THEN you can finally apply a texture to it? I mean what in the flying fuck... Radiant had an awesome texturing system, you could do so much cool stuff quickly, why change it?

New methods of doing stuff is fine and good but make it an option and put the traditional Radiant style editing back as the default. There are a few new things that work well and should stay (eg the Maya style handles for rotation of brushes only, but the new stuff should be optional and the old stuff should be restored as the defaults. Come on SpoG, at the very least put an option in there for old style editing that actually works. 
I Pretty Much Agree With Frib 
And Me 
i actually hate this change in radiant 
Fat Controller 
I will try it this evening, thanks a lot for this advice: it's a very good idea !!!
Just a few question: have you tried this method with lightning in one of your map before ??? 
GTK 1.5 
You can hit the magic "q" key, and have the brush resizing etc the same as in previous versions of GTK. But yes, I prefer to use 1.4 myself, and for DooM3, I am quite liking the built in editor, although there are things i wish were different, and more GTK like, but oh well.......................

Having an option to either have the new style, or the old style (with selected improvements) would be nice 
Gtk Stuff 
Vorelord: that's nice in theory, but in practice it actually does not revert back to the original controls if you press Q. It does allow you to do old-style brush moving and resizing, but, you still have to switch modes back to the new stuff to do vert/edge manipulation. And of course you still have to switch to face mode to texture stuff.. etc.

The fact that radiant editing features mostly were not broken up into different modes (eg face mode, move mode, select mode.. etc) is the main thing that set it apart from the other editors, and one of the big reasons Radiant was the editor of choice even for games like Quake (which it didn't natively support).

I don't mean to bitch so much... I do appreciate the efforts of SpoG and everyone else who has contributed to GtkR. I'd really love to be able to upgrade to 1.5.x as there's some cool new features and improvements, however on the balance of things it is not worth upgrading because of the big backwards step in editing speed and efficiency. 
It's not a "fix" to revert to the old, it just gives you some of the old ways back. I prefer the old way myself, IMO, it was far more intuitive. 
Gtk 1.5 
I haven't used it, but I have been using an older version of GtkR for Q1 mapping for some time. Based on the very detailed rants by Frib, I can totally agree with what seems to be the general opinion: it wasn't broke => it shouldn't have been fixed. 
Piling On 
I've been forcing myself to use GtkRadiant 1.5 while working on my q3 map and here's what I've noticed...

-middle mouse for copying textures was a priceless feature, and yes I know it will be back
-using ctrl for skew was really fast when vertex manipulation is overkill
-face selection mode is good for texturing a lot of faces at once, but for doing a single face the old method was 10x faster. There's no reason the shift-ctrl method should have been removed 
is the new method faster for selecting multiple faces than the old shift-ctrl-alt method? O_o 
Re: GTKRadiant 1.5 
necros: no.

And I agree with all general comments that texturing and skewing was a lot faster in GTKRadiant versions before 1.5. I can understand trying to unify the interface, but making something slower and then not listening to your testers when they ask you to make it faster is just not a good policy.

Frib: out of curiosity, what version of GTKR do you currently use? I have 1.4.0 from Dec 21, 2003 and there are a few bugs in there that really get me annoyed (b0rked edge selection and clipper preview are the big ones). 
I've made it clear that I'll be using GTK for the first time when I start my third map. Taking in all these comments, I'm pretty sure I'll use the 1.4 version.

Two reasons: It will be a Q3 bsp, so I don't need 1.5's native Q1 support.

Also, am I right in assuming that 1.4 is more similar to DoomEdit than 1.5? I'd imagine that would be handy when (if) I start D3 mapping.

But mainly, all this talk of 1.5's clunky interface has really put me off. 
Check the latest beta from, it has old-style vertex/edge dragging... 
necros: Not faster no, but when you attempt the scale multiple brushes along a common plane, I find it's very handy to be able to drag in only 1 direction, rather than the old style where it'd be common that you'd accidentally pulled a bit to another direction and ended up with one of the brushes with a side moved that you didn't intend. 
well, in 1.4, there are three buttons on the tool bar, X, Y, Z which lock the scaling in only that one direction at a time... so i fail to see the advantage... 
<-- Mr. Embaressed Face 
Is that what those buttons do!? I never touched them, figuring them to be shortcuts to scale on axis by a value. Thanks :D 
Rpg.. Gtk Versions 
I use 1.2.13 which is the last stable version which has all the features I like working and stuff. 1.4 is ok but it has a few old features that are broken (like paste to camera, dragging and dropping textures onto faces from the texture window, etc etc).

I've tried 1.3.8 and 1.4 but they don't really offer anything new that is useful for quake based editing, and some features are broken or missing, so you're really not missing anything if you're mapping for q1. For anyone doing q1 stuff I'd recommend using 1.2.13, for sure... edit mostly in q3 mode and then use a map converter or DuBSP to directly import the q3 map format. So, to get it all working

1. Install GtkRadiantSetup-1.2.11-Q3RTCW.exe
2. GtkRadiantSetup-1.2.13-update.exe
3. Use Tigger-on's setup guide here:
4. Map and be happy! 
Other Stuff 
RPG: yeah, I don't like the dodgy clipper thing either.

Kell: It will be a Q3 bsp, so I don't need 1.5's native Q1 support.

You don't need native Q1 support to map for Q1 in Radiant anyways. I guess it probably helps in some ways, but once you have it all set up (and yes, it is a pain in the ass, but Tig's setup guide makes it a lot easier) its plain sailing from then on.

I do use Riot's DuBSP so I don't have to worry about converting the .map to Q1 format, but you can use Sleepwalkr's map converter to convert it and then use any old bsp compiler too.

Aquire: It would be really awesome if you could include Q3 map format support in your BSP programs. Its really handy in DuBSP to be able to just use the -q3import switch and have it all work like magic. The map converter is ok but its an extra step and its a bit of a hassle at times. 
#2433 From Fat Controller 
Well, I've implemented your method to have a permanent lightning effect, and it works fine :)... I've just a problem of "location" of the lightning beam (at the bottom of the door instead of the top as wanted...), but it's pretty easy to correct...
So, just great thanks for your help man.. Bye.. 
Paste To Camera 
does that paste only the position of the camera or does it include rotations and stuff in gtkrad? I remember using paste to camera position with brushes in conjunction with a command to get the normal for a face in ogier to angle sunlight the way you wanted without having to think about what numbers to put in yourself. 
If all goes well, the upcoming version of my compilers will have a -q2map option which enables support for Q2/Q3 style map format from e.g. GtkRadiant. 
Trigger In Clipping List 
When playing through Kona's Carved In Flesh pak, I suddenly was thrown out of the engine with a Trigger in clipping list messagebox. It happened when I fired the newly acquired positron beam weapon in a certain direction. Does anyone recognize this or know what the cause could be?

It appears to have some similarity to the recently fixed e2m2 easy skill crash (also appearing in Ariadat). I've tried several engines with the same results. 
Winxp Failed Arghlight 
after compiling well for a period my arghlight suddenly fails to run on winxp.
Now everytime the message appears
light.exe failed
file read error
SV/model/index:modelprogs/player.mdl not precached

It just happens after a time of well compiling,
what goes wrong? 
this is more of a qc problem then engine oriented.

quake builds a clipping list at some point during map load. when you switch an entity's .solid setting later on, this causes a problem because quake finds things in the list that don't belong there.
the trick is to use a setorigin(self, self.origin) to 'refresh' the list.

i guess an engine alternative would be to refresh the list everytime qc changes the .solid setting... 
Thanks for the info, after some investigation I also think it's somehow QC related, possibly the self.solid isn't properly set (to SOLID_NOT?) after the player has grabbed the positron weapon.

I had this problem now and then throughout the whole pak which prevented me from using that weapon effectively.

I've now at least added the classname of the malplaced trigger edict (here posibeam) to the printout to ease troubleshooting. 
is there any way to get the standard 4 window (XYZ+3d Views) setup instead of the default wierd 1 top down + 3d + z thing?

also, the "inspectors" window can't be closed... like, you press T and it switches to textures, but pressing t again doesn't close the window... can it be done? 
If you go to the view menu/toggle, select top, side, front etc, they will open, but they are stacked on top of each other, so just drag them aside, position and resize them to your liking.

Inspector window, no I don't beleive it can be closed,(well it can, but then you have trouble reopening it, without restarting the editor) you can manualy move it out of the way, a pain I know, I have started just having it on the lower right, and leaving it there, you can also double click the individual tabs in the inspector window, and they will undock, when you close them they automatically redock in the inspector window.

I have settled for one half screen for the autho veiews, quarter screen 3d view, and quarter view inspector window. I wish I could get rid of the Z window all together, but it just gets hidden out of view anyway. 
I wish it could be set up just like I use GTK 1.4 and previous. I have basically one window open at a time (maximised) and just toggle through the top, side and front views when needed, or ctrl/shift/c for the camera view, and you just hit T, O, or N to bring up the tex,con or ent windows, but alas........... having to use little windows makes me feel like I have to bend down and try to peek in, I much rather the full screen area (maximised) for each window, much better. GTK 1.5 doesn't seem to allow me to do this either. But beggers can't be choosers 
Trigger In Clipping List Follow Up 
When looking at the "Carved In Flesh" thread here I noticed that cyBeAr also had the same problem with the positron gun with Win/FitzQuake, but DarkPlaces handled it better.

After some investigation, it appears to be fixable in the engine so I've done the same in my engines. It might still be a problem caused in QC of course. 
well... one could argue it is a problem with the engine, because, really, it should check and refresh the list when a change is made to an entity's solid type, however, it's easily fixable (by using a setorigin function right after) so it can also be argued that it is the qc coder's fault that he/she did not take this into account.
therefore, i'd suggest you actually leave it as it was (broke) so that when people test their mods out on your engine, they will get that error, find out what it is and fix it so it works in all engines.

0.02 ;) 
Damn Straight 
make the coders work for their crust! 
since the major goal with my engines is to be able to load (and play) maps that others can't, I can hardly leave it broken if there's an easy way around it.

Also, using my engines as a test for classic engine load/playability, is not really recommended since they have significantly higher limits. 
well, ultimatly it's your choice, but this is simply a bug that should have been fixed in the progs.dat. changing the engine so it doesn't complain about a bug that could have been fixed doesn't make sense to me. 
useful explanations of some BSP tech stuff, e.g. marksurfaces:

Scroll down to Spike's post from today. 
Maybe The Wrong Place To Post, But... 
Does anyone know where I can find a good, windows compatible editor for old school doom? I tried DCK v3.62, but it only works in DOS mode as far as I can tell.
At least we can point you in the correct direction: 
For a good, straight forward doom mapping tool, wadc is clearly the only correct choice. 
the best editor for classic doom is doombuilder 
Hey all -- I'm working on a Quake map for a mod, and I'm trying to set a door to be triggered by a button. I've done it a million times in my maps but for some reason, it's not working here. I've checked everything a million times and I dunno what's wrong. So I have given up, and I seek your help.

Thanks for your help. 
you've got two doors touching and being triggered at different times.

you need to check the "doors don't link" spawnflag so that each can be trig'd seperatly. 
Aguire - Light 
dude, i've got some pretty funky problems with the light program...

i'm not sure what's going on... it happens on a rotating torus brush... basically, the brush should be lit more or less uniformly, but in-game, the top, bottom, left and right areas of the torus are the only parts the proper lighting, the rest is fullblack...
anything i can do about that?

also, would it be possible to have light.exe to check, not only target-targetname sets, but also target2,3,4 and targetname2,3,4 sets? (numbers to do reference each other, target2 can target targetname4, etc...) 
Thanks necros -- Lordhavoc told me the same thing right as read your post -- I totally forgot they were touching. My intention was to leave the smallest unit of space between them. Thanks. 
Rotating brush lighting: I've some faint memory that rot brushes are actually positioned in the middle of the map (0 0 0) and this affects lighting (of course). I don't know if it's fixable. Please send me the zipped map+wad and I'll see what I can do.

Multiple target checking: Certainly possible, but I assume this must be some QC hack to get it to work in-game, right? I'm not sure I want to adapt a standard light tool for a specific progs.dat.

I've not even disabled the normal light complaints about missing target lighting although it's in the standard progs.dat for a similar reason.

Would you also like to have the light style handling on these additional keypairs or is it just a matching check? 
Rot Light 
I've some faint memory that rot brushes are actually positioned in the middle of the map (0 0 0) and this affects lighting (of course)

Hmmm...I had loads of rotators in Bastion and they all seemed to light correctly. (I was using the Hip rotator code btw). 
I Remember That Too 
i think it might have been in custents where the brushes light like theyre at (0 0 0). Wait, didnt that use the Hip rotate code? I dunno. 
Light On Rotating Brushes 
IIRC, the wierd lighting on rotating brushes has to do with the dynamic lights (e.g. muzzle flash, etc.), so it's more of an engine or QC problem. Static lighting should work fine.

I also found some wierdness where the position of the rotate_origin (I think) would affect the texture offsets. I may be able to dig up my example maps somewhere... 
i've been having some strange trouble with convmap (not mapconv, btw)...

mapconv packed up and left, spouting german obscenities, so i'm using convmap now, but when using the command line:
convmap -i -f32 mapfile
it refuses to write a file, however, if i omit the -i, and then say "Y" when it asks me if i wish to convert the file it will do it.

since i'm using this in a batch file, i'd like to get it to convert without asking me and requiring a keystroke...

any ideas? 
Rotating Brush Wierdness 
Grab this file and note the subtle differences in the map files and how they affect the dynamic lighting and texturing of the func_rotate_door (hipnotic progs):

(this is stuff I discovered during the OUM project) 
The ConvMap option groups are order sensitive; use the line convmap -f32 -i mapfile instead. The first group is the conversion group and the 2nd is the file selection group. It's certainly not the most user-friendly interface I've done ...

In the next version of my compilers you can omit the conversion step and use the new -q2map option in qbsp instead. 
Weird Hipnotic QC Error 
I've got a level that has tons of monsters spawning in, mostly using func_spawn and func_spawn_small. Now, for some reason, some of these func_spawns (some of the last ones placed) spawn in monster_dog rather than the monster specified by spawnclassfunction and spawnclassname. See, but I don't want dogs I want ogres and fiends. Any idea on why this might be? 
Thanks, Aguire. 
Gtkradiant Question: 
is it possible to get the quick compile menu to work with batch files so i can compile maps in q1 format right from the gtkr menu? i tried experimenting a bit, but gtkr started talking about not being able to connect to (me) so i gave up... 
Qc Error: 
are you sure the spawnclassname *and* spawnclassname are set? the func_spawn from hip (and custents) defaults to a random choice of dogs, fiends, shamblers and a few others. dogs are the most common in the random pick, so it's possible you just had a coincidence and you saw the dog on those occasions.
beyond that, i've never had any problems with the spawner code and i used is *extensivly* in ne_os1 without noticing a thing. 
Removing Floors Beneath Items 
Ok, I've got breakable floors in my map, but I can't get items on top to fall through once the floor has been removed. Monsters fall through fine, but items just stay hovering in the air.

Now, items are MOVETYPE_TOSS, which means they should obey gravity, right? Does the engine make them static shortly after placing them in the level? 
Makers Of Big Q1 Maps 
might want to keep an eye on the # vertexes in bsp, if the value exceeds 64k, the engine will probably have trouble loading it. 
AFAIK the only way to get around that without weird level-based hacks is to modify the engine. The bug itself can be exploited beneficially (see Vondur's Zed and Zed 2). I also exploited it in RPGSP1 when I had a MH float in the air, but then had to use a weird hack where I had a func_door nudge it for it to obey gravity again. (The source to RPGSP1 is available at my site if you want to look at what I did.)

I believe I was told something about it being a bug in fall-to-floor. The level loads, the item falls to the floor, and then it stays static until something forces it to move again (pushing down, up, or sideways). As an example, if it's on a func_train that starts moving up, you have no problem. But if it starts by moving down, then it will float like you've seen.

If you bump the item before the floor breaks, I wonder if it would stay dynamic so that it would fall after the breakage. 
Solved It In A (slightly) Hacky Way 
RPG - thanks for the info, although I have taken a QC-based approach.

I created new QC where the floor and the items on top of it are linked through target/targetnames (basically the disappearing floor targets the items).

Now, when the floor is removed, it searches through the entity list for the matching targetnames, and takes off their FL_ONGROUND flag. Voila, the engine assumes the items are now in motion, and they magically obey normal physics and fall through the gap. 
interesting post; i wasn't aware of the "bump to make it obey physics again" hack. 
Making A New Start 
The boss-gate, which only appears after receiving the sigil.

Right, then you got four boss-gates closed, and one finnishes the end-level.
At that point

what option does the changelevel of the end.bsp has, to return to the start-level without the boss-gates again?

I tried "jrstart" but it won't work.
I tried "start" but then the boss-gates are still there, although it's the same option as in the original game. 
I Believe 
(and if I had the time today, I would double check it for you, sorry) that it is hard coded in client.qc. You would need to change it there to get it to work normally if you are in poseession of the sigil. 
Take a look at and select client.qc 
Texture Mip Issue 
While playing through Kona's Ultramarine map, I noticed that in WinQuake some textures on the walls were flickering considerably when moving around. Up close the texture looked as it should, but after moving away the texture changed substantially. In GLQuake everything looked OK.

After loading the bsp into TexMex, I noticed that this texture didn't have the same look in all its mip levels; some white stripes were missing. Re-miping the texture did the the trick.

I've never noticed this before, is there a reason not to have the same texture in all mip levels or is it just a mishap? 
It's Possible 
he just forgot to remip the texture after making some adjustments.

i don't think there's any real reason to do it, unless you were looking for a very specific effect. (perhaps getting the textures to fade in the distance?) 
I Doubt 
that it was for visual quality, I don't think I've ever seen the mip level switch so obviously. I first thought it was some switchable light, func_wall flickering or even z-fighting.

The interesting thing is that it's not visible at all in GLQuake; it appears as if GLQ doesn't use the smaller mip levels but generates them on the fly from the biggest texture. 
Multum In Parvo 
This will be because of Texmex; if you paste a texture into a wad then alter the graphic later, TexMex prompts you to 'generate new submips?'. One assumes that in this instance, Kona selected 'No'. 
I also had an interesting TexMex issue when loading the bsp, re-miping that texture and then exiting and answering 'Yes' on save file.

After loading the bsp and checking out the weird texture in WinQuake, it was still not re-mipped. Then I noticed that TexMex had saved my changed data into a new wad file instead of the bsp and forgot to tell me ...

Btw, after inspecting the GLQuake source, I think I can confirm that it doesn't use the smaller mip levels but generates them on the fly. 
Yeah, it's just another example of why you should always playtest your maps in both Gl and software engines. Kona's maps also sometimes suffer from stray fullbrights; another glitch that won't get picked up in vanilla GlQuake. 
is it normal, when loading a map with excessive clipnodes into aguire's glquake, for doors to become non solid? they still blocks rockets and grendades, but the player can walk through them... 
I'm experiencing the exact same problem in all engines I've tested my map in (aguirRe's, DarkPlaces). 
A Bizarre Problem... 
I have something truly strange going on in my map: as soon as the map loads, you hear the sound of an opening door although no door is opening and when you move around the first room of the map you hear the sound of a lift. There is no lift nearby... Does anyone have any idea what could be going on? I've tried fullvising the map, but that didn't help. 
The clipnodes are directly related to the clipping hulls for collision detection so it seems reasonable. Rockets and grenades are point entities and clip against hull 0 (visible hull). 
As far as I know, TexMex won't let you save the .bsp if you've made any changes to it, with the exception of pasting a new texture or submip image over the top of an existing one. You can't add, remove, rename, resize, or remip textures and then save the BSP again.

I might be wrong about the remip thing though; try specifically saving the file as whatever.bsp as the default behaviour for TexMex (with BSP files) is to save the file as mapname.wad anyways, since that's usually what you want to do. 
Thanks for the tips, I solved it by taking the wad TexMex generated and run it through the updbsp tool, which updates the bsp with the new wad. 
Mixed Face Contents 
Is it ok to have mixed face contents in a Q1 map? I know what causes this warning in my map, but would like to leave it this way. 
See aguiRe's Tool Tips file at 
Ankhgod: it's 'ok' in that it only gives a warning and not a show stopping error, but the brush will only use the properties of the first face as defined in the .map source, which is difficult to tell in the editor. It's generally better to just use 1 type of texture per brush (solids only, water/lava/slime only, sky only). 
If you're using my compilers and if it's only a warning (i.e. one of the contents is Empty), it's caused by small brush misalignments and not any actual "mixed face contents" like mixing sky and *lava.

Brush misalignments are usually a good idea to look into and get rid of, otherwise they have a tendency to come up later as nasty clipping errors, HOMs etc. 
What Happened... 
Simple map, added a teleporter and a target.
Now when I cross the 0.0.0 in the map I suddenly get teleported. This is not the place of the teleporter, which is at the outer edges. 
trigger fields are based on the mins/maxs of the trigger brush, it doesn't work like bsp collision.

I don't know if that is the problem, but it's useful info nonetheless. 
Not Sure 
what you mean, the trigger brush doesn't touch other brushes or is in the area of the 0.0.0 point. 
well, you are using quark.

i know quark uses some kind of trick to get trigger_relays and such to work without actually requiring a brush. it's possible you muffed up some how and maybe, renamed a trigger_relay to trigger_teleport (which would work in other editors) and not the trigger field is set to '0 0 0'. beyond that, i don't know... 
Describe the shape of your teleport trigger brush(es).

If you have (for example) a trigger made up from two rectangular brushes joined to form an "L" shape, then the trigger field would encompass not just the space occupied by the brushes, but also the space inbetween, defined by the combined mins/maxs of all the brushes that comprise your trigger entity. eg:

x p
x x x

say a trigger is defined by brushes occupying the 'x's - a player at point 'p' would still activate the trigger. 
the func_ gremlins screwed up that "diagram" somewhat, but just imagine the 'p' shifted along a few spaces to the right (above the last 'x' on the bottom row). 
But Wait.. 
shape of the teleporter: 1291 6 695
teleporter destination : 2291 288 500

The error occurs when one passes point 0.0.0
in the map. With the teleporter itself is nothing wrong. 
is your teleport trigger just a simple rectangular brush? 
cheque your email 
It Appears 
to be just two orphaned trigger_teleport entities without any brushes attached. The engine (or QC) probably just put them at (0 0 0) and hope noone will notice. 
hi, just got your email. Dl'd and installed your pak. I managed to find the "Facade" map and the area in question. To be honest, it's a bit difficult to troubleshoot with just the .bsp - but I think aguirRe is the man to listen to here :) (see his post above). 
didn't i say that? 
Sorry, Yeah 
My Carelessly 
I had deleted the teleporter-brush without deleting the func_teleport. Reason the map became waxed.
Sorry for my short sighted mapping value. 
... "c'est le metier qui rentre".... :) 
Not All Parts Of The Map Get Lit 
New feature added to my code which supports
day\nite cycle in quakeworld but i noticed
not all spots get lit. All the outside edges will not light up. Its a big map because
it supports helocopters. Any ideas? 
How Are You Doing It? 
lightstyles with quakec? Some engine hack? 
I hope day/night cycles are not 24 hours !! I've never found somebody who played Quake for 24 hours consecutively... or this guy was a real fool Quake-maniac player 8p 
Day\nite Cycle 
Its in the C code(mod) and not engine but I do
work with the QW engine too.

No, not base on 24hr clock...hehe. its configurable but like to have it cycle 2 or 3 times in 35 min map time limit.

Starting looking at the light code and suspect a bug or limitation but need to confirm one more thing with my code first 
we can't help you without more information. 
Multiple Trigger Events Query 
I have a key door that I want to trigger multiple events. It triggers its own door, some other doors, some monster spawns and a 'trigger_once'. This last item has a delay set before it then triggers more doors - only it doesn't trigger them. All 'target' and 'targetname' entries are correct. The direction on the doors is set. I have tried trigger_once and trigger_multiple, also to no avail.

I want to use the delay as I do not want too much going on at one time: there are 12 other doors and several monsters involved, all within close proximity.

Is it me, or the wrong trigger, or what? Anyone tried something similar before? 
If You're Using A Trigger_once 
Tried setting the "Entity only" spawnflag (1)?
You may also try using the trigger_relay entity, which is a point entity. Use it exactly as trigger_multiple, except it hasn't got a brush. 
also note, if your trigger has a "killtarget", it will fail to fire it's regular "target". I consider this a bug in SUB_UseTargets, where the function exits too early if it has a killtarget set. 
I've Noticed 
that trigger_relays don't work quite rightly in certain custom engines. Try playing the start level to the classic Tale of Abbot's Rune with Dark Places and you will see a royal fuck up. 
czg: tried Entity Only, still no go. I am not clear on setting an entity without a brush?

Kinn: I didn't use KillTarget.

HeadThump: I am using Fitzquake. I am up to 430 entities with only 87 monsters (I have about 20 yet to be placed) 
I'd go with czg's advice and try replacing your faulty trigger_once with a trigger_relay - the trigger_relay is designed to obsolete the trigger_once in that situation anyway. 
also note, if your trigger has a "killtarget", it will fail to fire it's regular "target". I consider this a bug in SUB_UseTargets, where the function exits too early if it has a killtarget set.
jesus christ, how did i not know this? this caused me a lot of grief doing the end of pbrsp1. oh well :) 
My doors were touching and I had not set the the door_dont_link flag.

The doors in question were originally solid brushes that I converted to doors for effects. However, the second doors (via the trigger_relay) did not move with the first doors. Had they have done so, I would probably have twigged it straight away.

This lack of movement is not really a bug: first door is triggered, second door does not move because although it is touching, it has a different 'targetname'. Then the trigger_relay kicks-in but the engine gets confused because the doors were touching. Well, maybe.

Anyway, all now OK so not far from finishing the map. ('bout bloody time) 
Methodology Issue 
Hello all,

I have a little problem during QBSP process. I use in my map some arches which are rotated of 45 degrees, and it generates me a lot of CutNodePortals_r warnings, even if I forced brush to grid (dot corner by dot corner), and as well for textures alignment.. So, what is the good method to avoid this kind of problems ??

All good ideas and advices are welcomed.. thanx

PS: I'm using QuArK6.4 editor and aguirRe's TxQBSP tool..;) 
Difficult To Say 
but rotation of full objects can be tricky. Did you make the gridsnapping (for each vertex) before or after the rotation? In which hull(s) do you get the warnings?

If you can't sort it out and you're not having obvious problems in the area (clipping errors, HOMs, bad shadows etc), you might ignore the warnings. Make a full build to verify these things.

If you wish, you can send me the zipped map+wad and I'll take a look at it. 
I made the gridsnapping and texture re-alignement after the rotation... And if I remember well, the warnings occured in hull 0...
These arches are added just to break some uniform huge grey areas... and I can easily find a turnaround without any additional arches use... it is just an "aesthetic" add...
anyway, I just would like to know if there is a method to avoid these fu****g warnings that pollute my log file...

It's Ok JPLambert 
you can say FUCKING here. we're not that easily offended :D 
...I know you've said ...[t]hese arches are added just to break some uniform huge grey areas... but it's probably best to keep angular irregularity quarantined from other spaces in the level, so smaller vestibules rather than huge grey areas. Mind you, nowadays at least, you might just as easily say "fuck the CutNodePortals_r warnings" as long as r_speeds are within limits. 
... it's rather a design aesthetic issue than an real QBSP compilation problem... I have a huge places where all walls and ceiling are grey (like reinforce concrete bunker walls...), and I just would like to break this uniformity....
Anyway... I have a little idea to avoid this kind of FUCKING "troubleshootings"...
(I said it, yesssss.... ) 
...will set you free! Occasionally... for a while... perhaps... then comes the vacuum... and the need... then the drugs... etc. 
i personally wouldn't rotate anything that had multiple brushes that had to line up. I'd build it from scratch at the angle i wanted it. 
Rotating doors consisting of multiple brushes 90 degrees has never caused me any issues. 
Well, (unless that was sarcasm), obviously you won't have any issues when rotating objects in increments of 90, due to the symmetry of the coordinate system.

Rotating a brush any other amount is generally a bad idea, in my experience. Like metlslime said, build from scratch and use vertex manip. to get it at the angle you require. 
Rotating by anything other than 90� is a recipe for disaster. Do what metlkinn said. 
Probly Around Somewhere 
anyone know of a a radiant tutorial for worldcraft/hammer users?

or does such a creature exist? 
Metlslime And Kinn 
I agree, some rotation angles are more tricky to manage than others, I've experienced it... But I think it's rather difficult to build (for example) arches with more than 8 sections with the same precision the "shape-builder" tool do, with or without roation ! This due to the arche's intersections that can be off-grid ... and this is a real problem to polish correctly a design... 
Just take a look at , perhaps you will find what you are looking for.. 
Painkiller 1.35 Patch & Tools 
Tried this briefly last night, and the editor smacks me in the face with an error message saying it "failed to initialise DirectX9 renderer" and won't start. Just wondering if anyone else has tried this out yet, and whether it worked for you or not, before I start mucking about with drivers etc. 
Q1 Tools Update 
at . Main features are hardware gamma support in GLQuake, increased capacity in both engines, support for Q2/Q3 map format (from e.g. GtkRadiant) in compilers and many fixes/improvements. Please also see readmes for details.

Any comments are welcome. 
...are closely related to God. 
We Are All God's Children 
...we are but the children, BJ is something else. 
Does your version of Q3 map support include terrain alpha mapping? 
I Don't Even Know 
what that is, so probably not ...

It's not actually any specific Q3 support, it's only automatically converting from the Q2/Q3 map format into Q1, translating some and ignoring some of the info.

Nothing new, qbsp is just doing what SleepwalkR's MapConv and my ConvMap otherwise does in a pre-compile step.

distrans: I take it that there was something in this release that appealed to you? 
Does anyone use this to check their maps and if so, can you tell me if the output from running a Quake1 map through it gives accurate information.

In other words is it exclusively a Q2 utility? 
Yes, I do use it for Q1 on occasion. And only part of the info is useful for Q1 maps (e.g. bad brush output). 
aguirRe, you are, without a doubt, THE MAN
What He Said ^^^^ 
Although if you added coloured light you would be THE MAN x2 
Mmm....coloured Light.... :D~~ 
Thanks For The 
kind words guys! Although I'm still a bit unsure of what it is in this release that you seem to like so much ... 
I think it's just the overall support and improvements that you have made over time, and not just this release. I think the auto converting from Q2/Q3 format to Quake is very nice. just takes that extra step/prog out and makes it a more complete package 
The Q3 support.

I've been wanting to use your BSP compilers for a while now, for the better error reporting etc... but since they did not import Q3 map files directly, I used DuBSP instead. (Got to thank Riot for his tools, too!)

I could have used a map converter before, of course, but you know how it is (ohm's law.. path of least resistance... )

Now that your BSP(s) have the same q2/3 importing as DuBSP, I can have the best of both worlds. 
I'm building a map for quake 1. After adding some new monsters and brushes I get error after launching the map in quake (winquake, joequake). The error is "SZ_GetSpace: 8024 is > full buffer size". I get this error only after switching skill to 2 (means more monsters). Please help! Do I have to remove some entities? I wouldn't like to. 
Take a look at my engines and the readmegl at , they're specifically modified to fix this issue (and others).

AFAIK, the error is caused by having too many entities and events happening which cause the protocol between the server and client parts to overflow.

Typically this happens on higher skill levels since there are more action going on. The recently released Menkalinan had a similar problem.

I believe that either you'll have to cut down on entities or require a custom engine that has a higher limit. 
Found a serious bug in Light 1.36 that invalidated light data when using -onlyents option.

I've uploaded a new version 1.37 to that hopefully fixes this.

Sorry for the inconvenience. 
Texture Scaling And Doing "The Right Thing(tm)" 
Ok chaps, I'm having a spot of bother when it comes to deciding whether or not to scale up my terrain textures for performance reasons.

I'm aware that the whole issue of scaled textures is a bit of a salty subject around here. Should I go with the aesthetic and keep the rock textures at 1:1; or should I use *gasp* double scale and maybe squeeze a bit of juice out of the old nag? 
i really depends how carp it looks at 2x scaling... some textures scale better than others... best bet would be to experiment a bit... 
Also, it depends on how close the player is. If the player is kept 512 units away, then you would be more likely to get away with a scale of 2.

Also, I don't think you would get many complaints if the change in scale was appropriate and well thought out. Doing it randomly or on a global scale is a bit different. 
I Should Add 
that I can't gauge an accurate reading of the wpoly's until I've fullvised the map (which I won't be doing until I've completely finished the map) so my question refers to a sort of "general case" scenario really. Those of you who have seen the early screenshots should have an idea of the extent of the terrain involved. 
Necros, RPG 
Thanks. I guess a logical compromise would be to keep the flat ground texture at normal scale and apply double scale for the mountains - the problem is though, the player can walk over the mountain terrain at certain points, so I can't really avoid contact with the scaled textures all the time.

Worth bearing in mind though is that my only real problems with scaled textures are: a) the dynamic lighting issues, and b) the ugliness in software mode. Some custom engines have fixed point a), and of course in that case, point b) is irrelevant anyway. 
Scaling And Tiling 
I'd say go for the scaled look, it'll reduce the effect of tiling if the faces are large. A good rock texture should tile without looking especially odd, but over enough repeats the human eye is good at noticing the pattern. I'd say that combine that with the performance boost and the positives outweigh the negatives. 
Preach Is Right, 
the best way I have found to avoid the pattern issue is to fire up Photoshop, use the filter/distort/twirl, and I recommend twice. Once clockwise, a second counterclockwise, so you will have three seemless textures that fit together to avoid repeats.

I would have just e-mailed you an example that I was working on over the weekend, but I have been having some problems with my e-mail. 
you want a rock texture to repeat over a large expanse, try making a larger rock texture. Say, 256x256. 
256x256 is still repeated 16 times over a 1024x1024 surface. 
oh, right, so i guess the solution is to make it 65536x65536. What was I thinking? 
No, that's just silly. The Quake map bounds only go to +/- 4096. 
Thanks Guys 
I appreciate the comments :)

My rock texture is pretty big anyway (512x512) and I have decided to scale it 2x. I think it looks good even at close range actually :) 
I always thought that this was related to the number of sounds that were being generated at the same time, and that when the maximum was breached, packet_overflow occured and the sound did not play.

I have areas of my map that are not generating large numbers of sounds but I get the PO message. I have a constant sky(?) howl, I have some water, no live monsters within the map (I have killed them all and have plenty of bodies), no doors/platforms operating, no nearby secrets, and I am not shooting at anything.

I am using Fitzquake. Any ideas? 
Oh Yes... 
... and I have not yet done a full vis. 
It's not the sound overflowing, it's the amount of entities that are in view for the engine. Running a fullvis will probably help if the map isn't too open.

You could try one of my engines; they are specifically designed for this situation. Using WinQuake with the r_draworder 1 enabled, you'll see how much of the map that the engine thinks it has to render atm.

After fast/fullvis you'll see that less is in view and therefore r_speeds are lower and less packet overflows occur. 
So, too many bodies (and gibs), and uncollected ammo/health, and visable doors all add to the problem?

And sound, or not to worry about that?

Is there a countable limit? I know I can't account for the gibs but I can certainly move doors, ammo, health etc. 
it's the message traffic between the server and the client (normally both are inside the same engine process) that gets overloaded due to limited message size and throughput. This can also cause the SZ_GetSpace ... error which aborts the engine.

There is also something called visedicts (visible edicts/entities) which can cause flickering/disappearing entities; the normal limit is 256 and I've raised it to 4k. Normal max edict limit is 600 and mine is 4k.

Normally you "hear" when there's a sound problem; doors open silently or during a fight, some monster sounds get muffled or disappear entirely. This is related to two max sound channel limits which I've also raised.

As you can see, there are several "countable" limits and it can be tricky to estimate them.

Hopefully, these problems disappear after fullvis. 
Fullvis Vs Fastvis 
I just would like to have further informations about compilation time for the two process, particularly concerning the running time ratio between fastvis and fullvis. If fastvis run 1mn, how time will run a fullvis process ?? Is there a precise ratio, or something like this ??
no, there is not.
if fastvis goes 1min, fullfis might go from 10 to 600 mins and more and less...
depends on how smart (vis wise) u built your level. 
I've just tried WinQuake and had no Packet_Overflow problems, so that is good.

I did find some Fullbrights that were not noticable in Fitzquake - that I can fix.

But I cannot jump so high in your WinQuake as I can in Fitzquake and this is important in this particular map. It is exactly 40 .map units. Are the engine physics different in this respect? 
Tried your GLQuake, also no packet_overflow problems. In addition, no noticable Fullbtights and the necessary jump is fine. 
Basically what Vondur said, although a longer fastvis usually indicates much longer fullvis. Conversely, if you've made a fullvis that took a long time, cutting down on the fastvis time will cut even more off the fullvis time (in percentage).

I also have a feeling that the higher the relationship between # portals/leafs is, the slower the fullvis will be. More than 3 often indicates a really slow session. 
AFAIK, I haven't touched the physics in either of my engines but I think I recall that there sometimes are small differences in what you can do.

Also, please remember that if you want the map to play well in normal engines, you must check them specifically. But using my engines during development can help with big maps, that's the basic idea. You can watch the console for warnings that indicate that you're exceeding some limit. 
Well, if I understood correctly, there is no way to anticipate what will be the running time of a fullvis with fastvis running time.. And the resulting ratio fullvis/fastvis is at least 3 times longer... hmmmm .. with my latest map I guess fullvis will take many hours... OK, thanks for these crucial information.. 
I was unclear. It's not the fullvis/fastvis ratio I meant; it's the ratio between portals/leafs which you see early in the vis printout. However, I can't substantiate this really, just a feeling.

AFAIK, there's no obvious way to precalculate the fullvis time beforehand without actually doing an extra run just for the estimation ... 
OK, I understand, I will see it "at time"... thanx 
Detail Brushes In Quake 1 
I recall there were some attempts to implement Quake 2-like detail brushes into the Quake 1 compilers. Have there been any attempts at implementing Quake 3-like detail brushes (which are far more useful) into Quake 1? 
Those are already there. They're called func_wall. 
Don't be dense. 
1) func_wall's don't cast shadows

2) using an brush-entity in the same manner as detail brushes are used in Q3 will result in you exceeding entity-related limits imposed by the engine VERY fast. 
3) brush models are rendered very ineffeciently compared to world brushes, resulting in much higher wpolys, and other things like #clipnodes. 
Kell, Jago, Kinn 
Talk to a coder and he'll tell you the samething. You would need to rewrite the .bsp format to have Q3-style detail brushes work. 
what rpg said and func_illusionary works too.
as for the shadows, use antilight dammit ;) 
You would need to rewrite the .bsp format to have Q3-style detail brushes work.

I'm not arguing with that. But that's not what you said.

Funcs only work as a detail substitue in small, isolated places. And even then, they still add to the bmodel count and mess with the lighting if, for example, you want to make all your protruding light fixtures detail. It would likewise become impractical, or at least difficult and undesireable, to make all of the faceted psuedo curved architecture in a map funcs.
For e.g. a terrain map, Q3 detail makes the whole process easier to implement with vastly reduced compile times. Funcs are - take my word for it - not an option in this case.

Yes, detail isn't going to happen because of the bsp format, but that's no justification for declaring funcs a perfectly acceptable alternative anyway. Because in many cases, they're not. 
Yes, detail isn't going to happen because of the bsp format, but that's no justification for declaring funcs a perfectly acceptable alternative anyway. Because in many cases, they're not.

Of course they're not. But they're the closest you're going to get in all practical situations. I was assuming Jago was familiar with the limitations of using bmodel ents, and thus he could make an informed decision regarding when to use them and when not to. 
The fact that can sometimes manage to pull off some impressive geometry does not mean I am an engine expert :) As a matter of fact, I am pretty clueless when it comes to the inner workings of the Quake engine (or Unreal for that matter, even though I released 10 maps for that)... 
I Was Wondering The Other Day 
about bmodels and lighting. There is a place in my map where I have a brush model "fence" thing sticking up out of the terrain. Now, it had to be bmodel obviously, because you just don't want to go around arbitrarily jutting other brushes into triangulated terrain, but of course I don't get the shadows cast. Now I'm not too bothered about that, but I wondered if any light gurus (*hint* *hint* Aguirre ;) )had considered the possibility of making selected bmodels cast shadows. Considering how it would only seem to involve changes to the light.exe, and not to the .bsp format or engine, I was just wondering if it would be a theoretically possible thing to implement, or not. 
*Hint* Brushes 
is that what you mean ...? 
I did find some Fullbrights that were not noticable in Fitzquake - that I can fix.

Ah, this must be the bug in fitzquake that doesn't show color 255 as fullbright, even though winquake treats it as fullbright. Fixed in the next version, BTW :) 
I didn't know about that. And that makes it easier for me now as Texmex did not correct one fullbright pixel in one of the problem textures even though it corrected the others.

Now, if I can just clear this packet_overflow problem a 'new' SP map is in the offing ... 
Engine Limits... 
I am building my Q1SP in 2 parts for faster compile times and general convinience. Today I have realised that if I put both pieces together now and properly detail places which are missing detail, I will easily hit ~3500 brushes (without clip brushes and such). And this is Q1. AND both "pieces" are still missing many rooms. This puts my rough estimate of the final brushcount to 4000-4200 brushes. What kind of problems should I be expecting when I will eventually start merging both pieces together? 
Difficult to say with only those figures. # brushes is no problem for the compiler and brushes don't even exist in the engine (transformed into other objects).

Typical problems are clipnodes (especially if the map leaks) and marksurfaces, both related to complexity of architecture. Then comes entity overflows and vis problems if you're not careful with layout or brush amount/alignment.

Try to make complete builds as early as possible to get indication of problems. Then post here to get tips on how to proceed. 
My current Q1 map is around 7700 brushes and like aguirRe says, the brushcount doesn't really matter for the compiler - it's what the compiler turns those brushes into that can be a problem. Without clipbrushes, my #clipnodes is around 50,000. With loads of clipbrushes applied to out-of-reach areas I can bring the #clipnodes down to around 30,000.

#marksurfaces is another important figure. The limit here is again 32k, but you can exceed this limit in many engines and not have any problems. 
Yet Again Jago 
The map I showed pics of the other day is about 51oo brushes at the moment. It was started by joining 5-6 speedmaps I had lying around, a bit like you would like to do.

But as Kinn mentions it's the number of #clipnodes and #marksurfaces that matters.
Kinn mentions that #marksurfaces is limited to 32k, but some engines still can run it.
So far I have 41048 #marksurfaces and the map still loads in all the engines I tried it on, including the orig. GLQuake.exe.
Don't know about software Q since I cant run that! 
for the fence... i'm not sure what the technical problems might be, but you could try this:

rebuild the fence inside the func_wall, (make sure the texture alignment is identical to rule out z fighting) except cut off the bottom of the fence brushes just before they hit the terrain to stop them from splitting up the brushes.

i remember a while back, there was an article in pcgamer where some dude who mapped for half life gave "tips" to help map and he mentioned that in the desert maps, he had raised the catii 1 unit above the ground to not split up the terrain yet keep the shadows.

i remember suggesting that here before but it was not greeted warmly, so there may be technical aspects to this method that are negative... someone want to add to that? 
On A Similar Vein 
Single room map, player_start, single rectangular brush touching the floor but not the walls or ceiling = 210 clipnodes and 48 marksurfaces.

Add one default light = 125 clipnodes and 48 marksurfaces.

What principle is at work here and is it a useable feature when considering excessive clipnodes? 
Ah thanks - I'd forgotten about that technique. I may just leave it as purely func_wall though, considering how the lighting in that particular area is fairly flat (also I'd imagine having a world model fence there would give vis a fair bit to chew on ;) ). 
I'll try to dig a bit deeper what the issue is about marksurfaces. At least I now think that the warning about them being >32k is probably not correct. 
Marksurfaces 2 
The warning for marksurfaces <32k seems right after all, but there's another limit that should be checked too; #faces must also be <32k in normal engines. I've now added this warning to tools/engines.

I haven't been able to find out why some maps can exceed the 32k marksurfaces limit and still run OK in normal engines, it appears to be just "luck" ... 
Compiling Terms 
that might be interesting: 
QC Question 
Hmmm...I can't seem to call ambientsound() midway through the game - it only seems to work at level start - is it supposed to be like that? 
limitation of the engine. :P

there's a hacky way to get around it... frikaC explained it to me a while ago.

basically you can use my code:

void(float soundnum, vector org, float ambvolume, float atten) spawnambient =
WriteCoord(MSG_ALL, org_x);
WriteCoord(MSG_ALL, org_y);
WriteCoord(MSG_ALL, org_z);
WriteByte(MSG_ALL, soundnum);
WriteByte(MSG_ALL, ambvolume * 255); //translate this into a value between 0 and 255...
WriteByte(MSG_ALL, atten * 64);

soundnum, in this case, is actually the numerical value of a precached sound. the number is equivalent to when it was precached. so the first precached sound is 0, then 1,2,3, etc...

look through the qc files and you'll find the first sounds to be precached are the ones found in weapons.qc.

ambvolume * 255 is so you can use a 0 to 1 value and it will be converted into a number between 0 and 255.
same for atten, but in this case, it needs to be multiplied by 64.
don't ask why... i don't really know. something to do with bytes and whatever... 0 to 255 is 8bit or something, a short is 64... meh. :P 
Thanks necros! That's some pretty interesting stuff there. So, to clarify, I would have to make sure that the required sound is always precached in world.qc, (preferably near the beginning, so I can keep track of it more easily) for it to have a consistent soundnum.

Something else I did try, and I'm not sure if this is good practice or not, is just calling the regular sound() function on a looping .wav - once the sound starts, it seems to loop automatically ad infinitum, which is more or less what the ambientsound() function does is it not? 
yes, you can do it that way, however, when the player is too far away from the sound emitting entity, if it is not an ambientsound(), the game doesn't bother to keep track of it in some way, so the sound will stop playing. (i think this happens when the ent's volume reaches 0 from attenuation) so when you get near to the ent again, the sound won't play.

another hacky way of doing it would be to have a looping sound. find out the exact length of the loop up to the second decimal.
ex: length = 2.39 seconds.
use the play function to start the sound, and keep restarting the sound every 2.39 seconds without the autoloop feature.
the sound will be interrupted if the player goes into the console or menu or whatever though. also, if host_framerate isn't 0, then the rate at which the sound is called will be different as well.
you could also leave the autoloop markers in the soundfile in, and keep overriding the sound on it's own channel everytime but that's just ugly. 
Thanks again. The best solution I guess would be the one in your first post, which incidently I wouldn't call particularly "hacky" - it's just making use of an already existing network message that is otherwise unused in the QC. 
Stereo Wavs 
Do stereo .wav files play correctly in Quake 1? Or should I turn them into mono? 
Stereo Might Still Play But... 
use mono. 
Point Off Plane Error 
Nothing in aguirRe's Tool Tips

Can someone give me an explanation. I have just run into this error after adding the final brushwork to FMB100. The brushes are not important and I can leave them in or take them out (although it looks much pretier with them!)

It is only a warning and I can not find any problem in the vicinity of the brushwork e.g. random clip_brushes, non-solid brushes etc.

But I would like to understand what is happening. 
I think I remember getting this in Bastion at some point; is it associated with any hull in particular? IIRC, it didn't seem to cause any detrimental effects when I had it. 
Point Off Plane 
The first thing qbsp does to a brush face in the map file is to transform the three points into an infinite plane. These three points are all on this plane with only minor float precision offsets.

If I understand it correctly, qbsp then starts to figure out how this plane is limited (clipped) against the other planes in the brush. In this process, more points (vertexes) will appear in the positions where the planes meet.

When these new points are checked against the original plane, they might be slightly off and when the distance exceeds a certain limit (0.05), a warning is printed.

In my latest compilers, I've added an automatic healing of such points, i.e. adjusting them to the plane. It appears to help a bit, but I'm uncertain of the theory here ...

In any case it's usually rather easy to find the problem spot and align the vertexes, at least in hull 0. 
AguirRe - A Question/request 
In qbsp, I get a warning during LoadMapFile:

*** WARNING 03: Line 60471: Brush with duplicate plane

would it be possible to print the origin/location of this brush, so that I can chase it down? 
Those Go Away 
with a one button click if you use GTKRadiant (sniff, sniff), Hammer user! 
Duplicate Plane 
AFAIK it's an editor error; you shouldn't be able to produce such a thing. Therefore I doubt that you can fix it manually in the editor other than deleting/recreating the entire brush and hoping the editor won't do it again when generating the map file.

Also, at the time of discovery, the location of the brush isn't known yet. The extra plane will just silently be dropped with no side effects. 
Ah Cool 
so I can safely ignore it? 
and I forgot to mention that if you can enable some brush numbering scheme in Hammer that will add line comments to each brush/entity, you might be able to backtrack from line number to editor brush that way.

In QuArK I can do that and I guess GtkRadiant has something similar.

Btw Kinn, your choice of emoticon is a bit odd ... 
and I forgot to mention that if you can enable some brush numbering scheme in Hammer that will add line comments to each brush/entity, you might be able to backtrack from line number to editor brush that way.

Hmmm...I don't think I can do that. Can any other Hammer users confirm this?

your choice of emoticon is a bit odd ...

lol, the wink? I dunno, it kind of makes sense to me, almost as if qbsp is taunting me with a wry "I know something you don't know" warning, without actually telling me the source of the problem.

I thought the little guy was leaning down to his left side to snort a line. I guess your interpertation makes more sense. 
er, I was humming 'dosey dotes' while writing that. 
The classic examples of that would probably be Mixed face contents or Bad contents.

Somewhere in your 10k brush map, there is something bad. Go figure ... 
I've just downloaded the latest version and it seems to have support for Quake1. It loads .map files and shows the Quake1 entity list. I haven't tried the compile routines as I cannot get the editor to show the textures.

Does anyone know how this is done - there is nothing in the Help files on Quake1 texturing. 
If Memory Serves Me Correct 
Place the .wad file in your id1 folder. I think that's it, I don't have it installed anymore. Unlike the earlier versions, 1.5 will read the textures straight from the .wad file.
For what it's worth, I would use GTK 1.4 or earlier rather than 1.5, a bit more messing around to get it set up, but far less buggy etc, and IMO, just better to use. 
I have a similar problem with GTK1.5. I have the .wad files in the id1 folder, but when I compiled the map nothing showed up.

When I asked about it, they said to include the path to the .wad file in theworldspawn, but that did nothing either. So, I still dont know how to get it to work. 
Thanks, that's a start anyway.

Zwiffle: are you compiling from within GtkR or are you using some sort of 'tweak'?

I am still using BspEditor with BspBuild and have no problems apart from using the 3D view, which is extremely slow (I have a decent system). Also, you have to be careful not to hold your finger on the forward/backward key because the keyboard buffer fills faster that the screen can draw and there seems to be no way of stopping it moving once it's started.

Hence, I am looking at changing editors. 
Is There A Function For That????????!!!!!!111111 
Ok, i'm using quark and don't know how to get a "quake" key to turn into a key card. 
do not use quark 
It depends on worldtype value into the worldspawn of the map ... see below.. So to have a jey card instead of a key use value 2

"worldtype" "#" // Describes time of environment (changes appearance/name of keys)
// 0 == Medieval (medieval)
// 1 == Runic (metal)
// 2 == Present (base)

You can take a look at for further details about QuakeC specifications.. 
Medieval (medieval)

really medieval? 
really medieval?

Yes, I guess it can be considered as really medieval... but for sure it depends on the mapper's creativity... 
Only Von Can Do... 
I didn't know that Vondur map for medievil game... it's a big surprise... Does he map with QuArK for this game ??? 
/me murders jplambert 
So Quark or not Quark ??? 
/me destroys jplambert 
You didn't answer Von !!! ;)) 
I do all my mapping in Notepad, except near the end, where I finish it with a praxinoscope.

It still produces better results than QuArk.

/me finishes Kinn with proctoscope dammit

/me gives Vondur a "wink" 
Just A Basic Question 
Why many of you are hating QuArK ?? I use this tool and it seems not to be bad as far as you say, so wtf ?? 
quark cannot work with grid properly and there are much better editors on this planet. why to torture yourself when there are mighty alternatives? 
Have you tried other editors? It's difficult to see suckiness unless you try the alternatives. 
looks like i've found my spiritual brother - it's kinn!

thanks to practoscopes of the world!

/me hugs Vondur 
I never used other editors (only QuArK at this time), and I've never encountered any grid problems with this tool... Perhaps with more experience, and other editors test, I could change my point of view... Anyway, thanks for your point of view... 
If you think QuArK works well for you, then everything's fine. I've used QuArK for several years without any major problems and while it certainly has its issues, so do other editors.
The debate of editors is often similar to a religious debate.

The only exception is Qoole, which I wholeheartedly do not recommend ... 
Does Anyone Remember... 
...The DeathMatch Maker? 
the only person who used DMM for several years was QMD... he ended sadly... ;) 
I agree with you, all editors have its own advantages and problems, and that's the mappers's job to find turnaround in order to release good maps..
BTW, I understand that some mappers can prefer an editor more than one other... but it's not a good reason, IMHO, to do "lobbying" against QuArK ;D 
DeathMatch Maker 
I think Mark Shan used it for his huge Q2SP maps, e.g. Progetto Genoma
What Was Wrong With That Praxinoscope... 
since I tried that example everyone is kiddin' about it, practoscope, proctoscope.
I don't mind, but Jean Plateau deserve a better answer than his invention sealed forever in Quake!

I bought DeatMatchMaker Quake1 on Ebay for $3,00
Now wait untill these boardsurfers claim it "unworthy".

But my question:
does it make sense trying to convert the Quake1 monsters to Quake2?
Or is it just whisfull thinking? 
i would play quake2 if there were q1 monsters in it + [i]good[/i] maps. 
D'oh. :P 
also, regarding quark, you really need to try gtkr or wc to see the difference.

quark has it's strengths, but those other two just have more... 
Well, while I need for sure to test other editors to clearly have a good idea of these differences (differences that everybody seems to be convinced here), I just can say that QuArK works fine for me today... I think it's clearly the most important for many mappers: having an editor that works fine in order to have fun while mapping... even you need to fight against some "bugs".... But I guess it's not enough for most you... I'm not so "perfectionniste" ... ;P 
Q1 Tools Update 
at . Main features are major speedup of Light, increased model capacity and improved edict check in both engines and many other fixes/improvements. Please also see readmes for details.

Any comments are welcome. 
i'm not knocking quark. i used it to make four maps, so i do know what it's like. 
Re: Q1 Tools Update 
when he says major speedup of Light he means major. like 4 to 5 *Times* faster on some maps. a map i'm working on used to take 32 minutes to light. down to about 7 minutes.

it mostly affects maps with lots of spot lights and delay 1,2,5 lights.

it's one of those things that is really worth your time to download. it makes fine tuning lighting much less painful. ^_^ 
same here a map took 56 min before now it takes 20. I never use the fast option anymore since a normal -soft -extra compile only takes a few seconds more.

AguirRe is the man! 
Thanks Guys 
I've used the new Fade Gate feature on many different maps and it actually works well for almost any map, no matter what lights are in there.

Typical speedup is about 2-15 times faster without any noticable visual degradation. 
On my new map, the -fast light compile used to take 25 minutes. Now it barely takes 5. AguirRe rocks. 
Uh Oh... 
*** ERROR 73: Vertexes in map exceed 65535

uh oh... will sealing the map reduce vertices? i am inclined to believe so because the error appeared right after qbsp failed to fill the outside... 
fix0r teh leak0r and you will be good2go. 
Mapping Standards 
I'm looking for a mapper(s) to help me work out stanards for my CTF, arena, and normal dm within my mod. So, I have something that mappers will like to create with. Contact me through the javascript link on my website.

What DaZ said; most values go down pretty much when the map is sealed.

Btw, if all goes well, I might have found a way to increase #clipnodes from 32k to almost 64k in the engines. 
wow! that would be great! i haven't clipped anything yet, so naturally clipnodes is over the normal limit and all my bmodels have become non solid. :P
it would be a nice way to continue testing gameplay before i finish clipping stuff. ;) 
Now you've lost me. My understanding was that clip brushes are used to force the players/monsters to not reach specific areas in a map. What else do clip brushes do? Sounds like I am missing something here... 
well, say you have a big swath of terrain. this terrain is bumpy and lumpy. all these angles take up clipnodes.

now, you put a big clipbrush over all the terrain. that means in hull1 and hull2 (but not hull0) the terrain is completly filled in where the clipbrush is, therefore less clipnodes are required.

same goes for details in walls and floors that the player can never get to anyway. you can always clip those to reduce clipnodes. 
You've mixed up clip brushes and clipnodes. The former are what you manually put in the map to block (or help) player/monster movements.

The latter is automatically generated by qbsp when transforming your map into a bsp that the engine can load. As necros points out, the more complex geometry, the more clipnodes. However, you can use clip brushes to reduce # clipnodes by doing what necros describes.

Check out my ToolTips document at . There is more info regarding clipnodes and hulls. 
Clip Brushes 
Just to support what is being said, fmb100 was tens of thousands of clip_nodes over the limit. If you have a look at the .map file you will see that I have some massive clipbrushes over the tops of the terrain that I thought players would not want to climb over, and also over some of the fancy ceiling areas. If you walk about on the roofs of the buildings you will hit some clipbrushes.

Clip_nodes are now just over 31K and therefore not causing a problem. 
Maybe A Wad Toppic Question... 
I downloaded Texmex and am trying to convert the Tenebrea textures for Quake1 to Quake2.
As I converted the *.pgn textures to *.wall, all the maps I try to compile shut down of a GLQuake error.
How do i convert these textures to a Quake2 wad? 
Uh Oh 2... 
marksurfaces... these are visible faces, right?

i'm guessing 51k marksurfaces is too high to run in glquake?
also, visleafs @ 9200 (8192 (?)limit): will performing a level 4 vis reduce these? (it's only fast vis atm)

lightmaps: at 78 atm. limit is 64(?)... how would i reduce these? is my only option to remove lights? 
I Can't Say 
exactly what marksurfaces are, but in normal engines they cannot exceed 32k without trashing internal heap memory with more or less random/erroneous results.

Vis leafs in excess of 8k will most likely crash normal engines and running fast/fullvis doesn't matter; map complexity is the problem.

As for lightmaps, check out my ToolTips doc. Exceeding 64 will immediately generate the dreaded AllocBlock: full error in most GL engines. Removing lights won't help at all; it's the total size of visible faces together with texture scaling.

If you send me the zipped map+wad, maybe I can see if there are any easy ways to cut down on the numbers. 
Looking For Some Mapping Articles... 
I wonder if anyone here happens to know of any mapping articles/guides/etc which deal specifically with creating "situations" and interesting gameplay moments in 3D games? 
the map isn't even passed half done yet. :(
i guess there's no real point in your taking a look at it since it will obviously need to be split into two maps. 
lol, how many brushes just out of interest? 
None that I know of. I usually find that it's best to just sit down and brainstorm. Look at other cool situations for reference (Kell has had some nice ones).

Not that my maps usually have interesting situations, mind you. Probably the most interesting gameplay in could.bsp was the slanted crate. 
I have a suspicion that you may not be receiving some recent emails of mine. Did you get today's mail? 
I got one, but I found the reply a bit odd; it seemed to refer to an earlier mail today that I probably haven't got. Please re-send if in doubt. 
Packet Overflow 
I'm about to release a new map, but I'm currently fighting with packet overflow message during the game, that "troubles" sound rendering... I know it comes from the sound channel limitation of the engine, due to too much thing to perform...
So my question is: while a map without monsters is clean (no problem), how can I prevent packet overflow troubleshooting after I added monsters ?? Is there a method, or something to check in order to prevent this fucking problem ?? 
more proper visblocking, less monsters, less ambient sound sources... 
If you've fullvised your map, then you've got a problem - it you haven't fullvised yet, then don't worry about it just yet. 
For the moment I just fastvised the map (fullvised preview test ran at least for 10 hours /8( ...) so, if you're right, and I guess you are, the problem will "self-disappear"... cool...
just a wild out of nowhere guess, is could.bsp named after that most awesomest tune in the Alice in Chains discography? 
I shall quote:

This map is dedicated to all that could have been, but never was, and all that should have been, but never will be.

ohmigosh so goth. 
The Map Is On My Drive 
but somewhere a long the line I've erased the text file. many apologizes 
the general level design advice you are looking for can be found here: 
any1 got experience of lighting level with lights that go thru walls? (any geometry)
can have omni and spotlights and define radius 
That happens in old compilers before the community coders fixed it.

From your post it's unclear if you're experiencing a problem or if you actually want to achieve this effect. 
looking for recommendations, preferably from someone with experience (maybe someone made levels for engines where light doesnt cast shadows?)

and forget about quake plz, its for another game 
Could you be more vague? We wouldn't want anyone actually understanding what you mean now, would we? ^_~ 
Well if you're into looking at code, you could try looking at the changes that were made in the Q1 and Q2 compilers that stopped the light from "leaking" into adjacent rooms. Otherwise, I really don't know how to help you with your problem. Try programming some anti-lights, maybe? 
Import textures in Wally. Made them 64x64, 8/256 colours. Load them in Quark and start game. Q3bsp won't compile, but as soon as I change my own texture for the ones in Quake everything goes fine?

What goes wrong? I just wanted to add some Q1 textures to Quake2.
Or is it already done before? 
Deathmatch Maker? 
I'm a little confused. I bought DM-Maker for Quake1. Now opening the program it leads to a texeditor for Q1, but the submaps are all Q2 submaps.
Then compiling a Q1map it wants to export Q2 md2 maps.

Strange behaviour for a good editor program.
The site for the program is down. 
Oh please God no.

Don't tell me you paid money for that.

Strange behaviour for a good editor program.

Somewhere, someone has your money right now and is laughing. At you. Sorry if I sound blunt, but just download GTK (it's free!) and be done with it. 
Neh1m4 Source 
Does anyone have the Damaul neh1m4 (Grind Core) source map for Nehahra? I've tried to download it from his PQ site but the links don't seem to work anymore. 
And I Quoth 
"...DMM is the shit of my life" - QMD - RIP 2004 
has the Neh1m4 source matter been resolved? 
I'd appreciate any help in the matter. 
when I get home tonight, I'll hook an old hard drive up that should have it. 
Sorry, AquiRe 
The Damaul map wasn't on my old drive. Would a decompilation be acceptable? BSPC, which I use, only mangles some of the liquid brushes touching non liquid surfaces. Otherwise the .maps are accurate. 
for trying. I'm aware of the decompile alternative but it won't help me; it's the original entity section I'm after. 
I swear there is a bsp compiler that has a command line argument that dumps all the ents in the .map to a seperate file if thats what your after? Unfortunately I cannot for the life of me remember which compiler it is :/ Sorry I cant be more helpful... 
that would be, "dumps all ents in the *BSP* file" 
Grabbing Ents 
Adquedit will export all entities from a bsp into a text file(and will import them back afterwards if you wanted to do the equivalent of a -entsonly compile without the original map source) 
Thanks For The 
suggestions, my own BspInfo utility can extract entities also, but it won't help in this case. The original entity section is lost if I can't find the map source. The current ent section in the bsp is crippled compared to the original. 
*tries to help, but probably makes an ass of himself*

Erm... EntEd ? 
FOUND THE BUG ....Not All Parts Of The Map Get Lit 
Its in all clients. See screenshots of day\nite cycling in action. Fix for this
is on website in news 
Holy Shit. 
holy shit. 
Holy Shit 
holy shit 
Wholly Shit 
Uh, I mean, Holy Shit! 
Nehahra Engine 
Would there be a general interest in me releasing an updated Nehahra engine?

It would basically contain a merge of the original 2.54 engine and my Enhanced GLQuake features, i.e. hardware gamma support and general increased capacity/robustness. 
RE: Nehahra Engine 
LordHavoc was one of the coders responcible for Nehahra and his Darkplaces engine has full Nehahra support. 
I would be interested if you had an option to revert the new particle effects back to the classic Quake ones. Other than that, it doesn't really matter a lot to me.

But it might be useful to other engine moders for some Nehahra engine source to be released, since the original never was.

mmmm... Nehahra FitzQuake... 
I am theoretically interested in supporting nehahra in fitzquake. However, the prospect of having to support a seperate network protocol is sort of a turn-off. 
I've changed the trail effects slightly (they were rather thin before) and now you can turn them off via the menu, but as for now you can't revert to vanilla GLQ style.

Btw, the 2.54 source is available from the Nehahra site. Otherwise it would've been a bit difficult for me to make the merge ...

Thanks for the input. If anyone is interested, just let me know. 
Need A Little Help 
I'm need someone to look at a level I'm working on, it's still pretty early on but I need to finalize some stuff in it before I can move on. This is my first level so I'm having a hard time working out the details of it. If anyone is interested in giving some constructive critisism or even working with on it for a bit drop me an email. I'll explain everything then. Thanks. 
I'll take a look at it for you.

send to -- and send it as a .zip or .rar please. 
Me Too 
My email is 
Color The Light 
Hey i want the lights in my map to be different colors, but i can't figure out how. If anyone knows can you send me an email at

what game?
use google and look for the tutorials... 
Have you received my recent emails (last few days)? I have had one of them bounce, but it should have been resent. 
The last I've got from you is dated Nov 19th 14:08 and is a reply to my initial comments. Since then I've sent you several emails regarding the skybox orientation issue. Have you received them? 
Yes, I seem to have received the skybox emails ok, and I sent replies to each of them as I received them, so I guess there are at least three of my emails which you haven't got yet :(

Looking back over the skybox emails, and my comments, I think the general consensus is that DarkPlaces is doing it wrong, and FitzQuake/Nehahra/Quake2/3DSMax is doing it correctly. If we could get all the custom engines to use the correct convention, then it would be problem solved.

But getting all the engine coders to agree on a standard is the real trick, isn't it? ;)

Personally, if I could just get DarkPlaces to use the "correct" orientation/naming convention, I would be a happy bunny. I'm not really bothered about the other engines that do it differently (Tomaz/Telejano etc.) 
I Agree 
to your conclusion.

I still haven't got any replies though ... Please try using one of my other email accounts. 
Skybox Update 
just been speaking to LordHavoc in #tf and DP now does the correct orientation, so as far as I am concerned, the problem has been solved. 
Now you'll just have to move the sun ... 
I'll just alter the skybox 
.Wad Manipulation On A Mac 
I'm trying to help a Mac user via e-mail. He's trying to extract the textures from RPGDM1.bsp and put them back into the original .wad names. He says he can't find any .wad manipulation programs for the Mac. Does anyone know of any programs I could suggest to him? 
Is Emulation 
an option? If so, he'll have a larger selection of tools to choose from. Speed shouldn't be an issue here. 
Just Found This 
Fitzquake Crash 
Ok, my map is now under the edicts limit, and static ents limit. However, FitzQuake still won't load it. I get the following error:

SZ_GetSpace: overflow without allowoverflow set 
Thanks for the link and the idea. 
at startup is probably caused by overflow of the so called server signon buffer (default 8k, I've raised it to 64k, same as DP). This contains initial information about the map that gets larger the more entities there are.

Increasing this buffer might cause net protocol incompatibility.

I can't say for sure though without debugging the engine. I'll try to check with the map version I have. 
i'm not sure, but i think you need to remove bmodels (func_*, trigger_* etc...) to fix that... not sure though... 
Just Checked 
It's the signon buffer that overflows, you'll need about 8.5k to handle startup (on Normal). 
I Take It 
the size of the signon buffer is hard-coded in the engine, i.e. not specifiable at the command line? 
hardcoded and it wouldn't be very wise to have it flexible since it breaks net compatibility.

Btw, I've now added a warning in my engines if the signon buffer exceeds 8k. 
Hehe... Kinn The Mighty 
<aguiRe> Great, now you'll just have to move the sun...

*Kinn is now also known as Apollo

<Kinn> Nah, I'll just alter the sky...

*Kinn is now also known as Jupiter 
My power fantasies come from rereading my Silver Surfer collection -- I'll add to my list of inspirations. 
but unfortunately I am more like Homer . . .

I'll add Kinn! to my list of inspirations  
Free Edicts Problem 
Well, as you certainly noticed, I've released my latest map called CMC last saturday. I have a big problem in hard skill: suddenly during the game, a "No Free Edicts" error occurs. My quesion is: what is this fucking error, and how could I solve it ?? 
Nice one, distrans ^_~ 
aguirRe: that warning should be useful. I guess reducing the number of edicts present at startup would be the solution then?

JPLambert: No need to get stressed out. "No Free Edicts" just means you have too many entities in the level at a given moment. I believe if the number of edicts exceeds 600, then the game will exit with this error. The obvious way of solving this is to reduce the number of entities in your map. Of course, there are loads of edict-reducing QC changes you can make, but that might be a bit daunting if you're not into the whole QC thing. For example, in the original Quake progs.dat, items don't actually get removed from the level when you pick them up (this allows for deathmatch respawn, but in single player it is useless and can contribute to edict overflow). Making items remove themselves properly is a good start.

Another reasonably easy one (and something I make use of extensively in my Marcher map), reduces the need for multiple trigger relays, by giving triggers something akin to Half-Life style "multi-manager" type behaviour, with new fields .target1-5 and .delay1-5 . These work just like the normal target/delay combos and let me use a single entity to trigger up to 6 staggered events. It's an easy one to incorporate, because all you have to do is modify the SUB_UseTargets function to look for these new fields and take the appropriate action. 
Take a look in the file sv_main.c (found in, function SV_CreateBaseline. In that function the server goes through the entities and creates a baseline which is sent to the client.

If the total size of this baseline is larger than 8k, normal engines will abort here. I've put my check at the end of this function. 
Maybe the easiest solution for you is to just add the progs.dat from earlier packs that just removes corpses? You'll then have to put your files in a separate dir beneath Quake (e.g. quake\cmc). 
Thank for your help.

aguirRe, as well, give me precious advices as you've just did by mail. I will try to update the map tonight, or tomorrow if I didn't found enough time. I really hope I will be lucky and find the good way to solve the problem quiclkly...
I already have some ideas about it, for example some flashing lights are not usefull, and can be removed... (some guys complains about it... so... why not...) As well for some health in hard skill... I can "win" some edicts.. aguirRe told me edict count was near 620 , so trying to reduce it of 30 will for sure help... and this time I will try it in hard to be sure it will works... ;)
So, thank you for your precious informations... As I said before, I'm pretty young in mapping, so I really need feedback and advices from all pros you are, in order to improve myself..
I have just changed to use GTKRadiant for mapping, and i would like to know in what dir i should put my textures, and should they be .wad, . png or .tga and what not? 
Q1 Wads 
Should go in Quake/id1/

I don't know about Q2, but Q3 should already be setup correctly if you've not changed the basic directory structure of the game. 
If you don't have GTKRadiant set specifically for Quake, then you will need to use that game as your base file. Earlier versions (personally I wont go near 1.5) did not have Quake I as an option so I keep it set up for Quake III Arena (1.3.11, and 1.4 for Quake 2 and Half-Life)with this file set up Quake III Arena --> BaseQ3 --->Textures ---> Metal (example set of textures), with the .wad textures unpacked and converted to JPEG's.

The versions of Radiant I use don't support .wad files natively except in the case of 1.4 which supports Half-Life wads in the Classic version.

When I am ready to compile the map, I use a seperate set up. AquiRe's tools plus a utility called mapconv which converts Quake2 & Quake3 maps to the quake format (trivial difference really, but they can cause a ton of headaches if not converted).

Two things to watch out for if you are using GTKRadiant. Don't use the mesh feature which is native only to the Quake3 engine and also be aware of the default texture settings. Quake uses a 0.5 ratio and Quake and Quake 2 use 1.0. Trust me on this ;) 
I have tried putting the wads in quake/id1/textures.wad but it looks for some textures dir and can't find it, I know that you can use older version and convert q3>q1 but is that better, to use an older version of GTKRadiant? and what version should i use then? 
If you use 1.5, you put the .wad file in Quake\id1, Earlier versions you must extract the textures from the .wad file as jpeg's to Quake\id1\textures\WHATEVER, you must extract them so as Radiant can use them, use TexMex (or whatever you want), to extract them from the .wad as jpeg's, plus you must also have a copy of the .wad file in the same directory as your .map file/compile tools for compiling.

As to what version, I use 1.4, others would have differing preferences from the 1.2.XX or 1.3.XX series. It takes a little bit of messing around to get it set up, nothing to painful though, and once set up correctly Quake will be selectable from the games selection menu at start up. You'll need a map converter to convert between Q3/Q map formats and some compile tools. I prefer to use Sleepwalkers mapconverter, the non java version, if you wanted that version and can't find it, I can send it to you, and aguirRe's compile tools. All you really need to know can be found at the link below. It really isn't as complicated as it may seem, and once you have it set up, you'll be laughing. 
Q1 Tools Update 
at . Main features are a new ShadowSense feature in Light, updated Win/GLQuake engines with support for up to 64k clipnodes and a new enhanced Nehahra engine. Please also see readmes for more details.

Any comments are welcome. 
Thx for the info Vorelord, but i have already set up to versions of GTKRadiant, one with 1.2.13 and one with 1.5, i got it working now, both of them, now i just got a new problem, if using curves and whatnot it creates something called patch in the map file, and the converter don't know what to do with this, nor does the map exporter in 1.5. So it just deletes the parts made as patch, is there someway to convert patch to brush? since the curve features is really the reason why i want to use radiant 
You are not going to get curve/patch geometry in a quake 1 map. Fundamentally impossible. 
Maybe I misunderstand something, but isn't having curves/patches/other q3 bsp features the main reason for q3 bsp support in engines like Darkplaces? You can have a q3 bsp be a q1 map, so why wouldn't it be able to have curves and whatnot? 
Yes yes. You're talking about q3 bsps, which of course will run in DarkPlaces.

I was under the impression that Zalon somehow wanted a way to get q3 curve information compiled into a q1 bsp, which as I stated before, is not possible. 
There Are Decompilers 
that will accurately decompile Q3 bsp meshes to brushes. I use bspc myself. You will probably want to convert these brushes to func_walls if you decide to do this as they add quite a few brushes to your count.

Personally, I believe it isn't necessary though. Pingu's curves never suffered due to the fact he was limited to the Quake1 format. 
QuArK Sucks! 
The float/integer-problems has nearly driven me insane, so ^^
I trust in your map-experience: What editor shall I choose for quake1-maps? I know it's quite a general question and I don't want any kind of flame war! But maybe you could give me some advices. Thanks;) 
I prefer version 1.5 (beta) 
How can you 'accurately' convert patches to brushes? Assuming a patch is just a set of control points, which can have a varying level of detail (depending on the settings in the game engine)? Who decides what is the 'correct' number of subdivisions/polys/whatever to describe that curve with brushes? 
as in not distorted to an extent that is noticeable in game, and the brushes are not divided to the extent that they are overly simplified.

I have converted all of the original Q3 Arena maps using bspc and then converted over to Q1 maps for testing purposes, and it works fine without a hic-up. 
moving ones, like the expanding intestine like things in Q3DM4 do not translate well. 
The Math Would Indeed Be Curious 
I contacted the guy who wrote the md2, md3 and Q3 bsp converters for Blender several months ago ( to throw some ideas around and this idea is something we discussed.

Mesh to brush conversion has been a holygrail of mine for a long time now, since that article advanced brushes appeared on Rust that makes it sound like the easiest thing in the world to accomplish.

Any inaccuracies of the fallowing are my fault and not his.

The formula would perhaps go something like this -- deviding the surface into trigs you determine the width and legnth of the mesh from the visibility set of the adjacent normals, with the normal direction being the eventual thickness.

Brushes are volumetric, so you will have to determine a volume of at least 1.0 when calculating the thickness (width * height(thickness) = 1.0) So, a trig side of .25 will need a height of .40 to be an actual brush.

After this, determine within the group of touching trigs which of them is the thickest (and therefore the smallest brush) and adjust the height for the other brushes of the set to this size for a more coherent brush model unit. 
Good to see you got it going. And like everyone has said, you can't use Curves/patches with Quake, well without using engines that allow it. Also somethng that I forgot about (Blame DooM3}, is that aguirRe's tools will do the Q3/Q map format converting for you (with the use of the switch), doing away with the need for a seperate prog to do that step. 
Visual QuakeC 
Is it my imagination, or do I recall someone once wrote a cool interface for QuakeC editing. Googling doesn't yield much. Any thoughts? 
somehow, i doubt it would be any good. i am pesimistic hero. 
Monsters Don't Want To Walk Over 
I have a gangway over some slime made of bars.
Monsters (knights, ogres) can't walk over this bars. Is there any way to enable this?
Check the picture: 
If you mean that monsters fall between the bars, just uses clip brush in order to plug the holes... I can't see another way to do that... 
That's Not The Problem 
I want monsters to walk over the bars. The distance between bars isn't big. The player can walk over easily. I have tried to use clip brush to cover the whole thing but it didn't help 
Try Placing An Agre 
over the bars and see if it works then or not. 
That's due to a bug in the monster AI... You can attempt to place a clip over those bars, may even that may not work... I know last time someone had this issue, the best solution was to place monster jumps at either end that just so slightly hopped them onto them. Still not a perfect solution, but may work with some experimentation.

Otherwise, you may have to bite the bullet and remove the bars, making a flat bridge for them to walk over. 
I Had A Similar Problem... 
...and used a single clip brush that was one unit taller than the offending brushes. The clip brush is invisible to the player and the one unit difference is not noticable as a 'step' during play. The monsters happily walked on the clip brush.

That may help in this case. 
Line traces used in the walkmonster movement code are done in hull0, rather than the correct hull for the monster's bbox. Therefore, a monster attempting to navigate "broken ground" thinks he's a point object and therefore won't attempt to pass over small gaps in the geometry, that would otherwise be filled in the larger hulls. Placing clip brushes will have no effect sadly.

You could place an invisible, but solid bmodel in the gaps, and monsters will "see" it as solid, but it will block everything, including gibs and missiles, so that may not be the ideal solution. 
oh if that's the case, I stand corrected ^_^ 
Another suggestion would be to alter the design from bars to a grill, like the one in dm1 near the YA alcove. The monsters will still wander slightly erratically but they should be able to navigate down the length of the longitudinal brushes. 
Kinn (and Ankh) 
No, you're right. A clip-brush does not solve this particular problem. I am confusing things with my use of a one unit clearance in another problem. It should be mirror, signal, manouvre; not manouvre, signal, mirror :-)

Sorry Ankh. 
Linkdoors Problem (Q1) 
Here's my problem:

- In my map is a section with three doors. Each door has 4 pieces - like a plus sign and each of the 4 pieces moves away from the center when triggered. The first door works fine and is triggered by a trigger_multiple. The second and third doors work fine if they only consist of 2 pieces. I button triggered them for testing as I first suspected the trigger_multiples used before. When I make the other doors 4 pieces, Quake (FitzQuake) fails to load the map and displays info and declares a program error. Here are the main comments:

Program Error (map doesn't load)
Object error in Linkdoors
Cross Connected Doors

What really confuses me is that the second and third doors are duplicates of the first door with thier names changed. They work with two but not 4 bars. The first door works fine with 4 bars.

Any clues?

I can provide a small map file upon request. 
cross-connected doors means you have the doors triggering each other as well as being triggerd by another entity.
Enable the 'Do Not Link' spawnflag. 
Thanks Kell! 
That was a fast reply and accurate.

Problem fixed - thanks. 
Is it possible to determine coordinates of the place where you are while playing a Q1 map? 
A Hackey Way 
Try typing edict # on the console, and replace the # with a number. It will print out info about that specific edict (entity) in the map.
Edict 0 should be the world, edict 1 should be the first link in the bodyqueue, and so on, so if you continue increasing the number you should eventually stumble across the player edict/entity (it should be around 8 or 9 or so iirc).
In the printout from the player entity, there should be a line "origin" that contains, (duh,) the origin of the player at that time.
There's also a field "angles" (I think) where you can read the view angles of the player, in case you need that for setting up an info_intermission or something.

(Of course, the most practical solution would be to make a tiny adjustment to the qc, so you could make, say, impulse 167 print out the origin of the player to console.) 
Qdqstats Does That 
(Of course, the most practical solution would be to make a tiny adjustment to the qc, so you could make, say, impulse 167 print out the origin of the player to console.)
Excepts it's impulse 99, I think. 
The Hipnotic progs.dat has an impulse command that dumps the player coordinates to the console. I can't check what it is though, as I'm at work atm. 
use fitzquake
type 'viewepos' at the console
and you'll get your current coordinates

also, you can get coordinates of the point you look at, type 'tracepos' 
I will check the qdqstats solution first.

Also I have used Kells suggestion to change the design from bars to grill to enable monster walk over it. Looks a bit strange how monsters search for the way on the grill, but at least they get thru (it takes some time however). 
Sky Brushes 
I want to use _sunlight, _sun_mangle etc to light the map but do not want the player to see normal sky.

Is it possible to have a static sky texture e.g. use a rock texture aptly renamed sky?

Is it possible to have a skybrush with no visible texture? 
I'll assume you're talking Q1.

No, by naming a texture sky it must then conform to Q1's texture nomenclature ( see metl's page which details all of these ). A Q1 sky texture must be 256x128 and the two square halves will be parallaxed against each other as usual. Failure to conform to this structure will result in erros, though I don't know exactly what and where ( wad editor, map editor, compiler, engine, console? ).

If run in a custom engine that suports skyboxes e.g. FitzQuake or Dark Places, you could specify a skybox out of 6 flat-color panels.
That's about the best I can suggest :/ 
*you could specify a skybox made out of 6 flat-color panels. 
If You Can't Make A Skybox Thingie 
You could try putting a skybox over the area you want, then fill over that with whatever brushwork you want, make it a func_door or something with no sound/movement/never triggers. That might result in what you want, if I understand your dilemma correctly. 
If You Just Want A Solid-color Sky 
a 256x128 sky texture where it's all one color will do what you want. 
Or... could get your head around Riot's Q1Rad program 
It's a bit odd request, but try experimenting with skybrushes that have solid textures on the faces you don't want to have the sky texture, i.e. "mixed face contents" brushes.

There are several maps with such "corrupt" skybrushes which cast sunlight although they look like solids.

You'll then also probably get the behaviour that you can fire a rocket right through the brush as if it was sky.

However, I don't really recommend this since the behaviour might differ in different tools/engines. 
Some Problems With My Map 
I have some small (I hope) problems with my map:

1. Message "Name is not a field" when I load the map in quake.
Do I have to correct this? How?

2. Several messages "Total_channels = Max_channels" at level start
When I remove any wall torch the number of messages decreases by one. Is it acceptable to have this problem in a map?

3. Map doesn't load in Ezquake.
But it loads in winquake, glquake, fitzquake and joequake. The problem with ezquake is: "Host_Error: SV.NUM_SIGNON BUFFERS== MAX_SIGNON_BUFFERS-1"

4. Several messages WALKMONSTER IN WALL in some engines.
But not in winquake or glquake. There isn't any monster stuck in wall in the whole level - I know it. There are some ogres placed close to walls which cause the message, but they move and behave normally. Maybe this causes the problem with ezquake.

What is your opinion about all this? 
1. It seems that you try to add a filed named Name into the map. I think you should change it to message or something like this...

2. I already add this problems. Just take a llok at post 261, 266, 1804, 1817 and after... Globally you have too much sound sources in your map. (torch are light and sound source as well !) and Max_channel is 8 in Quake..

3. Sorry I can't help you here...

4. This problem is really weird, but sems to come from the fact monsters are really too much closer of the walls.... hhmmmm perhaps you have also walking monsters without path_corner, and the engine try to make them walk throught the walls, which generates this problems... Otherwize don't use Ezquake.. this engine seems to suck... 
Thanks for answers

2. I understand, but I would like to know if it's acceptable to leave it like it is. I didn't observe any problems with sound during the game

4. Can monster walk without path_corner? That would be interesting to me. 
2. You can leave it like it is, but you will have for sure some sound problems. For example, when I had this warnings, some teleporters, or exploding grenades, have no sounds... so the game loose a part of its functionality, and it dicrease its quality..

4. No no no, walking monsters cannot walk without path_corner items. I mean, that path_corner are perhaps not correctly placed: I don't know if I'm right, but for example in a "L like" corridor, you need at least 4 path_corner (1 at each end of the corridor, and 1 or 2 at the L angle... it depends if you want the monsters to turn back at the end, and return at it starting position, etc.. etc.). If you missed the L angle path_corners, monsters should try to path throught the wall from "end to end"...As far as walls are solid, it's obviously impossible, but I'm not sure of the way some engine work...
Well, this last problem seems to be tricky to solve, and maybe I don't have the good knowledges.... I was just trying to have some constructive idea in order to help you. 
If you get an error unique to one particular (obscure) custom engine - in this case 'ezquake' - don't worry about it, just don't use that engine. No-one around here will use a custom engine anyway if they can help it (with the exception of maybe FitzQuake, and a couple of others). 
Define custom engine. I'd wage that the vast majority of people here would NOT be using vanilla gl/soft quake. 
Thanks for your suggestions: I'll let you know what happens. 
Jago: Are you fucking retarded? The vast majority do. And those that don't are either morons or use FitzQuake. 
In that case the vast majority *IS* fucking retarded because vanilla software- and glquake don't run all that well (and in many cases not at all) on modern hardware and operating systems and lack a shitload of features I and many other people take for granted. And there is more than 1 engine port worth using. 
oh, ugly 24 bit textures and blue lighting effects on lightning bolts are features? 
Custom Engines 
I use Fitzquake because I cannot use the original Quake engine with WinXP and I would not want go back to Win98 or earlier. I am surprised that so few(?) users are with WinXP: I accept that everyone else maybe Mac or Linux.

Has anyone got original Quake to work with WinXP? I am sure I have asked this before and got negative replies.

Mind you, I am deleriously happy with Fitzquake (until I have problems). I am also using aguirRe's GLQuake - I threw 46,000 clip nodes at it yesterday and it didn't bat an eyelid. 
i have winxp pro and glquake works perfectly fine. all you have to do is delete the outdated opengl.dll file. 
glquake is uglyquake 
YOU are ugly. 
Original Quake... 
that came with the game will not run (after the later releases). GLQuake always had a horrible water-warp, but as I said, I have used aguirRe's GLQ. But I will stick to Fitzquake at present. 
A Humble Request 
You know the famous E2M2 bug, whereby if you shoot one button and then bunnyhop across the gap, the trigger inside the door will hang quake if you are on easy skill?

Well, this is a request for some hardcore engine coder dude to give me as detailed as possible an explanation as to what exactly is happening here, as this situation is rather relevant to what I am doing atm.

I know it may have been posted on this board before, but in the absence of a search function, I'm a bit clueless sadly. 
in fitzquake at least, that door's trigger forces bridge to extend, and the other button is still red...
w3rd indeed 
I think it's something like the trigger wakes up a fiend which isn't present on the map in skill 0. I've seen a detailed write up somewhere, but I can't find it :-( 
aguirRe, yes there's some helpful info in that link :)

I guess this is related to the QC "rule" that you shouldn't call remove() inside a touch function. What I don't get is why this rule is broken in several places in the QC, eg. in spike_touch(), remove(self) is called directly inside the function.

Is this effectively a "bug" in the original QC, or are there situations where remove() is legal to call inside a touch function? Is it only SOLID_TRIGGER entities that you're not allowed to remove() inside touch functions? 
I Would Think So Because 
i've removed many ents from within their touch functions and never noticed a thing.
where is this rule from? 
it happens a lot in triggers.qc; here's an extract from the multi_trigger() function:

// we can't just remove (self) here, because this is a touch function
// called wheil C code is looping through area links...

self.touch = SUB_Null;
self.nextthink = time + 0.1;
self.think = SUB_Remove;
now that you quoted that, i do remember seeing that. i would assume it only applies to triggers since i've seen it done and have done it countless times on non trigger entities. 
i would assume it only applies to triggers

Great, if we can definately confirm this, then I will be a happy camper ^_^ 
Item_spikes Oddity 
01:32:12 Jago : My map has 1 instance of item_spikes and it shows up ok
01:32:23 Jago : I try adding 1 more, it doesnt show up
01:32:37 Jago : I try moving it around the map, doesnt help
01:32:54 Jago : I try copying the existing and working entity and move it around, no good
01:33:00 Jago : WTF? 
Figured It Out 
02:00:00 Jago : figured it out
02:00:43 Jago : apparenltly, item_spikes doesnt like being only 16 units above the floor
02:00:57 Jago : moving it up to 32 units above floor fixed it
02:02:28 Jago : weird that it works fine for item_shells 
odd because i usually put item_* 0 units off the floor.

are you using worldcraft? maybe you need the fixed entities list thing. 
Has anyone tried adding spawnflags to an entity in WorldCraft/Hammer beyond 2048? (i.e., 4096, 8192 and upwards).

It doesn't seem to want to store them (even though it has checkboxes for them). 
I like your nickname 
... if you are using WC replace your existing quake.fgd with this

This will solve all sorts of problems 
I use GYKRadiant. It just never occured to me that the entity file in radiant is well commented. 
Fgd File 
Is it safe to change the fgd file in worldraft when working on an almost done map? 
Well Yes. 
But if you're feeling insecure just take a backup of your old one before you replace it. (Or just make your Quake configuration in Worldcraft use the new fgd.) 
I do it constantly in Hammer with no ill effects, older versions of worldcraft may be different. 
I have a problem.

I was trying to make a map for the 1000 brush pak and was therefore using the Dkte3.wad. However, after saving the unfinished map whenever I tried to load it, I got a 'Couldn't load wad file...' error, which crashes the editor.

By trial and error over several days I found that the map file was(still is) being saved with an empty line immediately following the line '//BSPFAVORITES0010'. On older maps, I notice that listed on the line should be the texture names of ten favourites e.g.
//A_LAVA1;A_WATER1;A_WATER2A;ARCH01;ARCH02;ARCH04;ARCH05;ARCH1;ARCH1_B;ARCH1_R. I am assuming therefore, that the editor 'knows' that as the commented line says there are ten favourites, their names will be found on the following line, which will enable the editor to display said favourites in the textre window. On not finding them, it gives up the ghost.

Does anyone know what setting I may have inadvertantly changed? Has anyone seen a similar problem in other editors? Can anyone help?

It has taken so long to discover this that I have missed the 1000 Brush Map deadline. I now have to save my work less often, which for me means less compiling, and then edit the map file in TextPad before I can re-load it into the editor. Most frustrating and begining to wear a bit thin.

The editor was written by Yahn Bernier. 
I Don't Know 
the answer, but after inspecting some other maps made by BSP, the favorites line doesn't seem to require 10 items, they could be less.

I believe Tyrann is the expert on BSP here. I have the editor installed so I could see if I could reproduce the behaviour if you send me the map. 
Good Start AguirRe... 
Favourite/favorite: bloody hell!

At least I can now see the FavoUrite setting in Bsp.ini that I could not find before - our friends across the water use American whereas I stick to plain English!

What this has shown me is that regardless of the setting, Quake101.wad works fine as do plenty of other wads. Dkte3.wad appears to be the culprit: I have found several other wads that give the same problem.

What I cannot see at the moment is what the difference is to BspEditor as far as these two example wads goes.

The display of textures in the Favorites List is set in bsp.ini (show_favorites=1), and regardless of how it is set (along with 'numfav' to set how many textures to show), Dkte3.wad causes a blank line to be saved. This happens even if show_favorites=0 and numfav=0. Also, what is not clear is why, when these are set to zero, the map is still saved with
It may be to do with the format of the commented lines: these lines are not needed for the building of the map but tell Bs[Editor things about how the editor itself is set-up.

So, concentrating on the wad files for a minute, I can see that Dkte3 has no * prefixed textures (no moving water, sky or lava), and only a few + prefixed textures when compared to quake101. Am I getting warm?

I will send aguirRe two simple maps showing the problem but don't let that stop anyone else coming up with the answer :-) 
you could open the wad up in Wally or TexMex, select the textures you intend to use and then add those to your basic Quake101 wad.

PS Sorry you missed the Pak. Wont be the same without you. 
You're filling my mailbox! What are you sending me? 
Sorry. You usually ask for the map and wad file in a zip file?

But it seems as though OE split it into 14 parts and this has caused a problem at both ends: I didn't realise anything actually got through. Once again, sorry.

I have subsequently sent two simple map files only, via Hotmail (attachment<1k), showing the problem. 
I'll try that in the morning. Thanks. 
I Thought 
it was just the map file that was the problem. I've received 22 emails totalling over 11 MB. My poor modem ...

It appears as if the split file is incomplete so I don't know if I can put it together. If you have such big attachments, please upload somewhere and offer a link instead. 
OK, Managed 
to puzzle out the important parts of the MIME message. On my system, I get the same problem opening After manually changing the line
opening and saving in BSP then seems to heal the map file. Repeated opening and saving after that seems OK. 
any place i can learn how to use custom textures in hl2? 
HL2 Custom Textures


There are many sites poping up with tut's, just keep an eye out 
Antilight Use 
While I'm not use with antilight, can somebody help me an explain how antilight are declared (field in light entity, color, etc...) in a map ?? I supposed it's done like light entity, but what are the differences ??
Is just a normal light but in the "light" field (Or Brightness field if you're using WorldCraft) you put a negative number instead of a positive one.

I'm not sure how you make negative colored lights. In good old arghrad you could make both the brightness and the color components positive and negative, so if you had a light with "light" "-200" and "color" "255 -128 0" you'd end up with a light that sucks up red light (negative * positive = negative), emits green light (negative * negative = positive), and leaves blue light alone (negative * 0 = 0).

Also, antilights only affect lights of the same "style", so a flickering antilight won't have any effect in an area where there are just normal styled lights, but it will suck up light from other similarly flickering lights.

And last but not least, read the readme for the light util, these things are usually explained pretty well there. RTFM! ;) 
what czg said and RTFM indeed! 
Thanks !!! In fact antilight are no more than "negative brightness" light... BTW, I've read (perhaps too much quickly) the readme file of my light tool, and I didn't find the stuff.... perhaps I missed it... Anyway, thank you very much for these important precisions.... 
RTFM ??? 
Could you explain please... I think it's a quick short cup like IMHO, or soething else, but I didn't understand this one (AFAIK not more by the way... ) 
Something along the lines of

What is RTFM?

RTFM is not having to say you are sorry. RTFM is a big chromatic dragon with bloodshot beady eyes and fangs the size of oars. RTFM is me screaming at you as fireballs come out of my mouth to get off your precious no-good tush, march down to the local bookstore or MAN page repository, and get the eff off my back because I'm trying very hard to get some freakin' work done. Jeez.

RTFM - read the fucking manual ;) 
... I understand the stuff now... ;D 
Thanks for the last message re .map file problem (only just back to my desktop today).

Interesting. I did as you did and found it would now load. Looking at the new map though, the line that I had changed to 0000 now says 0001 and includes one texture on the following line even though the bsp.ini file clearly states that I do not want Favourites.

However, it works so I will leave well alone. I still don't understand why it inserted the blank line in the first place but if it happens again I will do a 'repair' and carry on. 
is it possible to make lava emit light as sky does? but w/o angles etc, just imitation of the loads of point lights ;) 
my esteemed russian friend means: surfacelight 
Heh, do you remember this:

#493 posted by {Vondur} [] on 2003/09/30 01:21:59
is it possible to make lavalight?
i mean the light that generates by lava surface as it generates by sky, but with delay.

#498 posted by {aguirRe} [] on 2003/09/30 06:20:48
I guess lava light should be possible using a similar technique, but I doubt the extra coding and processing time would be worth the effect.

Lava is relatively scarce in maps (I'm not so fond of it either) and the lava light would be rather local and diffuse. That makes it very different from sunlight which is more difficult to simulate with point lights.

Hrimfaxi actually had the same suggestion a while ago. He also wanted the lava light to be slowly pulsating.

To add to that, the closest thing I can see is something similar to the 2nd sunlight which is also diffuse. However, 2nd sunlight is non-attenuated and generated by automatically positioned extra suns in a grid, the amount depending on oversampling level (-extra*). 
Its very easy with Q1rad, just set it up in the lights.rad file like this:

*LAVA1 255 255 255 50

As you see above, there's the texture name, the 3 following numbers are the RGB values of the light, and the final number is the brightness. 
Aguirre Und Frib 
aguirre: yeah, i remember i was asking u that but was not sure where to search for that :> okay.

frib: yeah i know that util, but i use aguirre's light cuz it's more advanced though ;) 
How trivial/hard would it be to port this feature from q1rad into your light tool? 
I Haven't 
made any investigation, but I believe the lighting design is rather different so I don't think it'd be easy. If I understand it correctly, q1rad is based on HL's hlrad.

I have no current plans to include this functionality.

Vondur: Please try the new -gate 1 option as it really cuts down on processing time. 
The tools are fundamentally different, I imagine it wouldn't be possible to add any radiosity stuff into the existing quake lighting tools without a full rewrite of the code.

I'm sure it'd be much easier to integrate the advanced features into the radiosity tool instead, but that also would require a lot of work I'm sure (and in any case Riot has lost the code for Q1rad, so you'd be starting from scratch again). 
yeah i see it's rather complex task, then fek it. adding lava light manually isn't that bad in fact, you can make it more interesting.
off the laziness! ;)

aguirre, yah i tried it, but didn't notice any significant speed up (so far). maybe because the level is too small. 
The good thing is that you're mapping again!

And as for the Fade Gate, I can e.g. make a complete re-light of Adamantine Cruelty in just 2:20, or Nastrond in 2:49 ... 
regarding mapping: well, that doesn't mean i'll finish it ;)

regarding gate: eh? is the light quality the same as with -soft -extra etc? 
I used surfacelight for all the lava in my dm map "blood sweat & piss" (on my website - ) normal lighting for everything else, and dumped surface lights to the bsp with a program then lit it with arguires light.exe , worked a treat 
The quality is the same. The difference is measurable but not visible. I use it all the time now and in most maps, it speeds up light processing by 2-15 times
Movable Keys? 
Is it possible to make a key move around in a level? I.E. I want a gold key "driving" on a func_train:) 
so make a small func_train, and put the key on top of it. 
Yeah Sure. 
Just place the key on top of the train...

Excuse My Newbiness 
=) You're right... I am not familiar with setting up func_trains, so I ever placed the key somewhere else but not at the "real" (as it is compiled) top of the trainbrushes:\ Well, me < editor < Quake 
the train will begin its movement from the path_corner it targeted, so put the key under the train near that path_corner entity... 
i've met some troubles with shadows of sunlight2/3.
i tried every possible settings with sunlights, including sunlight3 usage. and cannot get how to make these shadows render properly.
maybe because they're too far from the sky? 
Difficult To Say 
from just the shot. I assume you mean why the bright spots are there? One thing that normally isn't very good is the sun pitch of -90. Please try e.g. -89 instead and see if it works better.

Otherwise I can only think of that sunlight2/3 is actually generated by a limited number of extra suns arranged in a grid around the upper hemisphere, which means that they won't be able to reach every corner, especially not if the architecture is complex or very vertical.

The distance from sky shouldn't matter since sunlight is non-attenuated (like delay 3).

If you wish, you can send me the zipped map+wad and I'll see if I can find out what's going on. 
ok, the .map sent :) 
I tried something like that a while ago, and couldn't get it to work, can you tell me how you managed to use two lighting tools on one BSP? Bastid :D

When I tried it, I found that the last lighting tool used stomped all of the pre-existing lightmap data, but perhaps I was doing something wrong (or using the tools in the wrong order). I was using Q1rad and aguire's light tool, but I can't remember which one I used first. 
From my bsp.bsp compile.bat -->

dubsp -nocrouch bsp
vis -level 4 bsp
durad -extra -dumpfacelights bsp
dulight -extra -surfacelights bsp

if u dont have dulight/rad I can email them to you... 
Thanks Daz 
I do have durad/dulight, I've just never used them as I thought they were made redundant by Q1rad. I'll have to have a look, thanks! 
/me Has Had An Idea 
Do any quake engines that anyone knows of support moving lights with negative values? 
FitzQuake Supports Colored Lightning 
but you must have an associated .lit file with your .bsp file.

Glad if someone would explane this a little more. Don't care to write one, if I knew how. 
Moving lights? I'd think darkplaces and tenbrae could do that since they're the only ones with dynamic lights I know of off the top of my head. Fuckall knows if they allow negative lights. 
moving lights is easy.
make a func_train with a small brush. in the func_train, give the key 'effects' '1' 
This is interesting, I don't think I've ever heard of this key before. What exactly does it do and what entities does it work with? 

why they fuck didn't I know of that page when I was doing speedmaps!? neat shit like that is what makes speedmaps great! 
a key that is normally only used in qc stuff (like when an enforcer bolt is spawned, that key is set so that it glows) and is handled all by the engine.
but we can hijack it like fatty demonstrates. ^_^ 
I Think It Was... 
...Pingu who used it to great effect (no pun intended) in "The Journey Home" by adding "effects" value "1" to the gold key.

If I'm wrong about it being Pingu, bleh!

Scampie: j00 r n00b 
Don't Forget: 
effects = 4 is a bright light
effects = 8 is the yellow particle field + dimlight 
So is there an "effects" "2"? If so, what does it do? 
Yeah, Its A Cool Page 
i never got the light to emit i remember, but i did use the particle field in a speedmap once. The trick with the door sounds might have been freaky to use too. 
Worldcraft 1.6a 
Another n00b question:

Is there any way (i.e. edit the RMF or Map file) to add back a camera that you accidentally deleted? I have done this a couple of times now and am tired of "re-piloting" the camera to the last point-of-interest in the map I am currently working on. 

Well, I guess you could edit the RMF file but those aren't exactly human-readable... 
well, effects 2 is for the muzzle flash when you shoot. it is a flash of duration 0.2 seconds. i haven't tried it, but i don't imagine it will do anything as the actual game doesn't start at 0 seconds but more like 0.5 or 0.6 seconds, so you wouldn't be able to see the flash anyway as that would happen at 0 seconds.
it's difficult for me to explain, sorry... 
If you want to go hacking the .effects field in the editor, here's what they do...

EF_BRIGHTFIELD = 1 //silly looking ball of moving yellow dots
EF_MUZZLEFLASH = 2 //short-lived flash of light
EF_BRIGHTLIGHT = 4 //a bright light
EF_DIMLIGHT = 8 //a "dim" light, like on lasers/rockets 
I believe you have the brightfield and dimlight the wrong way around. 
Yup, It Looks That Way. 
my bad. ^_^ 
My Light 
stands still...
and just wonders how to get the *.lit file 
first use tyrlite or equivalent program that can compile coloured lights.

then, in the lights, you use _color 'r g b i'
where r is red, g is gree and b is blue while i is intensity.

i think. i haven't done coloured likes in ages. 
i think it's just "_color" "r g b" but that's just from quake2 and quake3 experience. 
Colored Lights 
According to, you use "_color" "r g b" to set the color, and "light" "200" (for example) to set the intensity. That's what works with TyrLite. 
a lot! Couldn't believe my eyes seeing a moving light in Quake1! 
so you've never fired a rocked in q1 then madfox? :D 
you're right. it's q1rad that you use r g b i. i have terrible memory. :P 
I Fired More Than One 
but that's coding,not hacking. Never succeeded rocket-jumping without getting su�cided... 
I am not sure one should be mapping for a game before he learns to move around in it. 
Abandon me! 
GTKRadiant 1.5.0 
I jsut downlaoded this and it says it has support for making quake1 maps, however when I load it up and press t for textures there is nuthing to browse, any ideas? 
1) Read the documentation.
2) Put your texture WADs into /Quake/ID1
3) Read the documentation. 
At Least... 
Tried it out in GtkRadiant 1.04 but after setting the preferences, and turning the wad file into Quake/Id1, the programm ended in a solid brush. 
That sentence made no sence whatsoever. 
His programm ended in a solid brush, what's there not to understand? 
I've been working 2 houres to get the thing done. Then I realized i was using GtkR1.04 in stead of Gtk1.02
Also forgot to use Java applet.

But if my sentence made no sence I'll read the manual two times. Might help jago one time... 
What... The... Fuck?

1) GTKRadiant 1.02 does not exist
2) GTKRadiant 1.04 does not exist
3) what the hell do Java applets have to do with... ANYTHING? 
madfox is trying to fool you, jago ;) 
Sorry If Someone Feelsd Screwed Up, But 
I thought someone asked for quake1 in GTKradiant.
Since two times RTFM seems no help to me I considdered to make a link to industry.

If you don't use it, don't tell me what and what not excists. If you used the link you would know what I mean.

I'm not helped with...the..fuck! (one time) 
again... WHAT THE FUCK?

1) what on god's green Earth is a "link to the industry" ?
2) What "link" is anyone here supposed to be using?

Dude, really, take some english classes. You are not making any sense. AT ALL. 
Shut Up Jago 
He means the link to Tigger-on's industri/how to set up gtkr for q1 tutorial which he posted just up here... 
He linked to Tigger's industri Radiant tutorial in his previous post. 
LOL Beaten 
Like A Child In Thailand! 
Well in that case...

That tutorial is of no use to you if you are using GTKRadiant 1.5, because that branch supports Q1 natively without the need to fuck around with texture and mapfile conversions and whatnot. 
Thing Is.. 
GTKRadiant is for somewhat clever ppl
so dont bother madfox 
That's The Thing 
There is no documentation regarding quake in there but it does have help topic on every other game supported :S

But saying that, putting the was into /quake/id1/ worked, I had them in /quake/id1/textures for some reason. 
It Would Save You A Whole Lot Of Time 
if you used or learned to use batch files. Don't be a slave to the GUI. 
Gtkradiant 1.5 Question 
How do I select ALL faces that use a specific texture? 
don't think the option exists... but if you're trying to change them all to something else, there is find/replace in the textures menu. 
Actually, I am trying to properly align the texture, on some of the brushes the texture is offset by multiple units. 
is there a way to select all the brushes on a map at once in gtkradiant 1.4? im trying to mirror the entire thing. 
make a huge brush in the top view that covers the whole map. click on the button for 'select partial tall'
and voila, all the brushes will be selected.
press space and it's copied.
To Select All Faces With A Specific Texture 
You can kind of do it by selecting the texture (or one face with that texture) and pressing SHIFT+A. This is not the ideal solution though, as it selects all brushes with that texture, rather than all faces...

Depending on your needs though, that may be ok.

SHIFT+A is usually used to select all entities of the same type as the selection. 
i learn something new about gtkr everyday. :P
thanks, that will come in handy in the future. ^_^ 
When I try and compile my map with c:\..\qbsp

I get the warning: no wadfile specified, any idea what could be causing this? 
AFAIK, GTKRadiant still doesn't add the WAD files you use to the map worldspawn. You have 2 solutions for this:

1) add the WAD files manually to the worldspawn entry of your map.
2) open the map in another map editor and re-save the map. I've done this with WorldCraft. 
Thanks I think I'll do it via wc. 
Im trying to use your TreeQBSP to compile a Q1 map. If i understand correctly all i have to do is add "-q2map" to the command line for it to spit out a Q1 map. However when i try this i get an error message "***ERROR 54: Line 6: Line is incomplete". I've tried googleing but no luck. Theres no entities in the map and i havint modified it in any way other then with gtkradiant. also theres no wad file specified.. not sure how to go about doing that

Any suggestions? 
the first thing i'd do it open up the .map file and see what is on line6.

there is something wrong with that line. if it's not obvious, then copy it and paste it here and i'll take a look. 
I sometimes get that message if I have converted the map back and forth between .map formats a few times.

Take a look at the worldspawn entity, does it look like this,

"classname"" "Worldspawn"?

just do a find "" and replace with " in a text editor if this is the source of the problem. 
Lines 1 Through 12 Or 13 I Think I Forgot 
Ok below are lines 1 through 13. with it like this i get the error "line 7 is incomplete.

// entity 0
"classname" "worldspawn"
"wad" "egyptsoc.wad"
// brush 0
( -320 320 320 ) ( -512 320 320 ) ( -512 -448 320 ) egypt/block06a 0 0 0 0.500000 0.500000
( -512 -448 352 ) ( -512 320 352 ) ( -320 320 352 ) egypt/stone01c 0 0 0 0.500000 0.500000
( -512 -416 328 ) ( -320 -416 328 ) ( -320 -416 320 ) egypt/stone01c 0 0 0 0.500000 0.500000
( -320 -448 328 ) ( -320 320 328 ) ( -320 320 320 ) egypt/stone01c 0 0 0 0.500000 0.500000
( -320 -192 328 ) ( -512 -192 328 ) ( -512 -192 320 ) egypt/v128-01c 0 0 90 0.500000 0.500000
( -512 320 328 ) ( -512 -448 328 ) ( -512 -448 320 ) egypt/stone01c 0 0 0 0.500000 0.500000
I Tested The Map Text 
you have there with the latest build of txbsp because I'm more familar with it as a basis than treebsp. It has the same support base as treebsp however.

I saved it as a test map, adding only a brace at the end to enclose the worldspawn entity, like so:

// entity 0
"classname" "worldspawn"
"wad" "egyptsoc.wad"
// brush 0
( -320 320 320 ) ( -512 320 320 ) ( -512 -448 320 ) egypt/block06a 0 0 0 0.500000 0.500000
( -512 -448 352 ) ( -512 320 352 ) ( -320 320 352 ) egypt/stone01c 0 0 0 0.500000 0.500000
( -512 -416 328 ) ( -320 -416 328 ) ( -320 -416 320 ) egypt/stone01c 0 0 0 0.500000 0.500000
( -320 -448 328 ) ( -320 320 328 ) ( -320 320 320 ) egypt/stone01c 0 0 0 0.500000 0.500000
( -320 -192 328 ) ( -512 -192 328 ) ( -512 -192 320 ) egypt/v128-01c 0 0 90 0.500000 0.500000
( -512 320 328 ) ( -512 -448 328 ) ( -512 -448 320 ) egypt/stone01c 0 0 0 0.500000 0.500000

and I ran it without the -q2map option and it compiled without a problem. It would seem that the option is no longer necessary to compile q2map builds, but that is just my inference from this test. 
You must use the -q2map option for maps in Q2 map format. However, from what I can see in the excerpts above, the face format seems to be mixed Q2/Q1.

There are paths in the texture names like in a Q2 map, but the additional values after the tex name are missing (like in a straight Q1 map).

Something seems wrong in the generation of this map file. As for the wad, you must either include it in the "wad" key in worldspawn (like you already do, but check file position) or have a wad file with the same name as the map file in the same directory (the default wad logic). E.g. "" and "mymap.wad".

Dakza: If you wish, you can send me the zipped (unconverted) map+wad and I'll take a look at it. 
Cheesey Workaround 
I used the replace feature in wordpad to deleate the texture paths... then i saved it in worldcraft.. for some reason if i didint some of the brushes went missing when i went to compile. then i just run it like a normal quake map. Works, but its an awful hassle. Plus i have some consern re not knowing whats going wrong.

ALso, how do you go about modifying entities in gtk? eg. adding targetnames and spawnflags and such. 
(shouldn't that be leaves?)

So there I am, happily polishing my effort for the SM40 contest, when all of a sudden I get 'Vis leafs 8684 exceed normal engine max 8192'. Bugger!

During this latest bout of polishing I have added about 12 brushes. I haven't seen this message before on this map so am somewhat surprised.

Am I right in thinking that vis_leafs are 'the sides of brushes that face into the map that a player can see'? For simplicity, I am assuming that we have a hollow cube and that it is made of six brushes, resulting in 6 vis_leafs. Each brush is six sided in the .map file but the player can only see those sides that are 'inside' the map when it is played i.e. the six inside surfaces of the wall, ceiling and floor.

I know about func_walls (from earlier posts) but my most numerous brushes that fit my simple scenario are all cave walls and ceilings. If I turn these into func_walls and place brushes outside of these to seal the map, am I likely to get some success in reducing vis_leafs?

I don't seem to get a vis_leaf count unless it's a problem and I have 5500 brushes in this map so I don't want major changes unless I need to.

Any suggestions? 
well, i don't know tons about this subject, but vis_leafs isn't the visible surfaces, that would be surfaces and marksurfaces i think.

anyway, i think the simplest way to reduce vis_leafs is to reduce the complexity of the vis data, so, for example, convert sticky outey bits into func_walls. 
The most common cause for that warning is a leak. Assuming you've already checked that, the "vis leafs" is the first of the two values that vis prints out at startup (can also be read from the prt file), the other being the portals.

AFAIK, a vis leaf is an empty volume inside the map that the player can theoretically be in, regardless of size. Each leaf borders either to solid faces or other leafs via portals ("doors" between leafs).

The more complex a map, the more leafs/portals there'll be and the longer vis will take processing it.

Due to a bug in most engines, the max # vis leafs is limited to 8k, otherwise the stack will be trashed and the engine will crash. This is one of the most common causes for an engine crash and it usually happens when trying to load a big leaky map.

In my engines, I've upped the limit to 32k and added a protection for amounts beyond that. Like necros said, try to reduce complexity to get down vis leafs. 
I want to ask a question that I wanted to ask a long long time ago.

How to make trigger_shooter work as trigger_spikeshooter? I mean it should start to shoot when player enters the trigger zone and stop to shoot when player leaves the zone of the trigger that is targeted at shooter.
So far even if I give it a targetname it always shoot, no matter where the player is. 
have you tried calling it a trap_spikeshooter? 
More Detail 
pulsar - although i've never used shooters before, i'm just looking at the QC, and they seem simple enough. Just hook a trap_spikeshooter up to a trigger_multiple (with "wait" set to the time between spike firings) and bob's your uncle! 
OK, something going on here that doesn't make sense to me.

I spent the morning clearing leaks: the map had all of its major brushwork in place and up to this point I had been using -nofill in Qbsp. I then ran Qbsp normally (about ten times), using each generated .pts file to clear all leaks and eventually running a quick vis all without problems.

Only then did I add my dozen or so brushes, all inside the sealed map. Does this mean/suggest that these few brushes pushed vis_leaves over the top?

I have since changed 200ish brushes to func_walls to see if this would make a difference, and it didn't.

Right now, I intend to retrace my steps from the pre-leakcheck map to see if I can recreate the problem: of course, I can't get the vis-leaf count as I go as I have leaks. Is this Catch22?

Anyway, thanks for your input. 
I understand what I say, I know that.
It seems I need to explain it more: trap_spikeshooter works exactly in the way you described, but it shoots too fast. It hard for player pass thru it without getting damage. Trap_shooter shoots slow (as I want), but it shoots always and triggering it just makes it to shoot faster (like trap_spikeshooter does).

So I want to know if it is possible to make it start to shoot only after triggering it and not from the time the has been loaded. 
the has been loaded.
the map has been loaded. 
I take it you are using a trigger_multiple to trigger the trap_spikeshooter, yes?

Just set the trigger_multiple's "wait" field to the time you want to elapse between spike firings. The trigger_multiple's default wait is 0.2 secs, so if you don't set it, the spikes will be launched at a rate of 5 per second. 
I haven't thought about it in a such way. I'm going to check it right now. 
AFAIK, you'll get the vis leaf warning also when the map leaks (which is the normal reason why the amount is so high). Having a sealed map with >8k leafs usually means >24k portals and then you'll have a fullvis nightmare ...

If you can't sort it out, send me the zipped map and I'll take a look at it. 
Funny Really 
I have this 'system' that I use when working on a map: I compile regularly (like every 15 minutes) using Qbsp -nofill, and Light, which also saves the work done so far. Every so often I will save the WIP with a new name, in this case, etc. Occaisionally, I will try some major change that I am not sure about and will use the file so if it doesn't work I can just dump it and continue where I left off.

So, I am moving a piece of terrain that is on a grid of 1536 x 1536 x 768 - this is big so I use to try it out first. It's a success and I am so pleased that I continue leak testing (post 2969 above) and resolve every leak. Then I go and have some lunch.

When I come back I load the last map ( and continue polishing. I add my 12 extra brushes, compile and... get the vis_leaf problem. WTF, it worked before lunch? But of course as we all know now, the last map I saved was called and had all of my leak fixing in it - I had forgotten to save it with the usual series name.

Oh well, at least with the system I use, when I retraced my steps back to the last good map and then worked forward, as soon as I got to the need to move the piece of terrain I realised what had happened. Only wasted a couple of hours and now back on track, no leaks, full vised, so polishing continues.

There's a moral there somewhere... 
The moral of the story is: mapping editors need a built-in database system for tracking changes. Something like CVS or Subversion (which are used for tracking changes in big software projects). 
There's a moral there somewhere...

Always Backup Your Maps*

*even if you are easy to confuse 
QuakeC Help Needed 
I am getting to the phase where I should be adding gameplay to apinaraivo.bsp and I am in need of QuakeC help. I need to port the Mega-Enforcer for Zerst�rer and something from Scourge of Armagon over to the ID sources. If anyone would be so kind as to do this for me (should be pretty trivial for a person fluent in QuakeC, which I am not), please get in touch. My eternal gratitude is assured. 
What the heck, I'll sort you out ;) What is it you need from SoA exactly? 
I sent a email to the address mentioned in your profile. 
sorry - could you resend to:

bdwooding - at - gmail - dot - com

thanks :)

/me needs to update his profile 
Have you received my last three emails? 
don't worry, I'm getting round to it (blame christmas ;) 
My Head Fucking Hurts :o 
Just for kicks, try compiling the hipnotic sources with FrikQCC, put a monster_scourge into a map (the mechanical scorpion from SoA), compile and run the map. Notice how after dying, no centripede doesn't have any death animation whatsoever and just "stops" with his body becoming non-solid (as in, you can walk through him). The original hipnotic progs,dat file however, works just fine.

After pulling my hair out for an hour, I realise that what we have here is a bug in THE BLOODY QUAKEC COMPILER! I downloaded some bizarre ProQCC release from 1997, it compiled the code and everything worked as advertised. Ugh. 
A Few Noob Questions 
I'm currently making a quake sp map and Im quite confident I will finish this as alot of the structure is in place.

Having never really got this far when creating a map, it leaves me not too hot with entities so here goes..

I want two doors to open reveiling a monster behind each (already in place), but I want the doors to only open once the four monsters that your fighting have been killed.

Secondly I want a button to trigger a door open only once two of the buttons have been pressed, I've seen this in some maps and it has an on screen message "1 more left".

Also one other thing, is it possible to make a monster or a set of monsters "spawn" as you pass over a trigger or a button?

If anyone could shed any light over these I would be most greatful. 
I want two doors to open reveiling a monster behind each (already in place), but I want the doors to only open once the four monsters that your fighting have been killed.

Secondly I want a button to trigger a door open only once two of the buttons have been pressed, I've seen this in some maps and it has an on screen message "1 more left".

You need to you use trigger_counter. Create a trigger_counter, give it a targetname (counter1 for example), fill the 'count' field with the number of monsters/buttons you need to activate it (4 (monsters) or 2 (buttons) for you), and then fill the 'target' fill as for usual trigger. Then target buttons or monsters to that trigger (for example 4 monsters should have 'target' field with 'counter1' value.

Also one other thing, is it possible to make a monster or a set of monsters "spawn" as you pass over a trigger or a button?

You need to create a room somewhere, place monster there, cover him with trigger_teleport and give this trigger_teleport any targetname. Then target your trigger or button to that teleport.

I hope it's clear. 
I want two doors to open reveiling a monster behind each (already in place), but I want the doors to only open once the four monsters that your fighting have been killed.
Target each of the four monsters to a trigger_counter, give it a "count" value of "4", and if desirable set spawnflag 1 to make it not print out "there are more to go..." messages when you kill the monsters.

Secondly I want a button to trigger a door open only once two of the buttons have been pressed, I've seen this in some maps and it has an on screen message "1 more left".
Exactly same as above, just set "count" to "2" and target trigger_counter with the buttons instead of the monsters.

Also one other thing, is it possible to make a monster or a set of monsters "spawn" as you pass over a trigger or a button?
You have to make this happen by creating a small box outside the map, place the monsters you want to spawn inside, place individual trigger_teleport over each monster, give the teleporters a common "targetname" like, say, "spawn_monsters" or something, and target each of the teleports to their own info_teleport_destination placed where you want them to appear in the map. Triggering the teleport(s) will now spawn the monsters at the info_teleport_destination(s). 
Omg Double Penetration :/ 
VPhysics Penetration Error! 
The counter thing worked great and I can complete some more of the set pieces now, thanks. As for the monster spawning haven't tried that yet but sounds easy enough.

I just wonder if the trigger_counter needs to be an entity that's pressed, passed through or touch by the player or can it reside anywhere within the level? 
I just wonder if the trigger_counter needs to be an entity that's pressed, passed through or touch by the player or can it reside anywhere within the level?

No, it's brush-entity, but you just vreate it somewhere, no matter where, it doesn't need to be touched. 
Another Question 
Is it possible to set it so that once you've hit a certain monster to a cetain % health left, you can make it teleport away before it dies.

e.g. Just like spawning monsters into a level but spawning this particular one to a different location triggered by it reaching a certain set health level, if you know what I mean. 
afaik only death of the monster can trigger anything. 
you may use trigger_relay and spawn in monsters after some time after the first trigger has been activated. 
I was thinking more along the lines of a boss type monster spawning in, then fighting then spawning out when it was almost dead and to do this a varying stages of the map up until the final battle. 
I was thinking more along the lines of a boss type monster spawning in, then fighting then spawning out when it was almost dead and to do this a varying stages of the map up until the final battle.

That sounds too complex for quake, it seems you need another engine or at least custom qc. 
The Recurring Boss Monster 
That would certainly be possible in QC, but how you'd put it into the map would, of course, depend on how you coded it. If you want to use a custom mod for your map, I would write this part of it, e-mail me if you're interested. I am going away for new years, so if you want a simple boss(like a basic quake monster with just ajusted stats and this ability) I could do that tomorrow. If you wanted something more complex, like changed AI or some totally new creature, it would have to wait until next week(and would likely take even longer than that...) 
My idea was to encounter a vore or shambler (boss creature) and just before the last shot made on him he would teleport out with a system message "Not this time" or something similar. When it teleports out it would target another trigger spawning in some mobs like ogres / zomies.. Then further on in the level do the same kinda setup with maybe a different message "Your getting closer". It doesn't neccesarily need to be the same vore/shambler, just have the ability to spawn out before death with a setable system message each time.

The final battle can just be a normal vore/shambler that will die and thus completing the mission.

I hope that makes sense, basically don't need new AI or anything like that :) 
Post #3000 
probably you could just change the death animation of those monsters into something like spawning or make some similar effect via qc as Preach offers. 
Ah yea that sounds like a good / less complicated idea and I could use a trigger_counter with 1 to trigger the message when the teleport anim/sound plays. 
the obvious solution would be to have to seperate versions of the monster. one that does the teleport flash as it dies and another that just plain dies. centerprints can be handled by trigger_relays as usual, and monsters fire off their targets when they die.

just a fast cnp qc job, really.
don't look at me though. 
...didn't the boss wraith in DoE teleport? Sure it was to a place behind or near to the player, but that's easily changed. 
Yes. The Hipnotic/FrikQCC thing is worrying as FrikQCC is supposedly the "gold standard" for QuakeC compilers now, and everyone uses it. That said, I've been using it to compile all my stuff for years now, and I've never met any problems except when I turn optimisations on - some optimisations (I can't pinpoint which exactly) seem to turn my progs.dat into garbage :P 
Animated Textures 
Aw come on! Just as I think it's done, I find another problem...

TreeQBSP tells me that it has found all of the textures in the .wad file. It tells me that it has added x number of textures. But in-game I am seeing the dreaded pink/black texture as one of the frames.

I know (from earlier posts) that I could add the missing textures to 'hidden' faces in the map but I would have to do that manually as BspEditor doesn't show the individual frame textures, only the animated version.

But why would this be happening and why are other animated textures displaying correctly? This is a 64 x 64 texture based on ID's tlight02 i.e. +0tlight02, +1tlight02, +2tlight02, +3tlight02 and +atlight02.

Help will be appreciated. 
Wait, you only get the pink/black texture as one of the five frames? 
If it only happens in FitzQuake 0.75, then it's a known and fixed engine bug. I think it's because only some of the animated frames contain fullbright pixels and others don't. 
R.P.G. - yes, appears to be just one of the frames missing.

aguirRe - looks like you have something - it's OK in your GLQuake and also in DarkPlaces. Unfortunately, the Fog effect is lost and I want to keep it. So, I will adjust the Brites out of the texture in TexMex.

By the way, are you saying that there is a 'fixed' version of Fitzquake somewhere 'cause I can't see it on the FQ web-site? 
Once aguiRre put me on the right trail, my own memory clicked into gear (age is against me chaps!)

There is a slight problem with TexMex's Remove Brites function in that it leaves White (255,255,255) in place. Therefore, although you think you have circumvented the problem with FitzQuake's fullbright handling in animated textures, you haven't as you still have a fullbright in the texture.

So, change the dirtywhite to dirtierwhite, and change the white(255,255,255) to dirtywhite, and hey presto, it works correctly in FitzQuake.

Mind you, now that I've seen it, I'm not so sure that it was worth all the fuss. Ho hum.

You'll see what I mean in SM40. Thanks guys. 
i've always been using the ancient 1997 version of ProQCC. nesp02 was compiled with proqcc, as was every other release i've made with modififed code.

i have never had any problems with proqcc and haven't ever seen the need to switch. whatever limitations proqcc may have, it's never stopped me from doing what i wanted to do. 
AFAIK the problem is fixed in the upcoming FitzQuake 0.80. Maybe metl could fill me in here ... 
How do I get your light to spit out a .lit file? I've gotten it to work with Tyrlite, but I have some ugly results. I saw no clear way to do this in the -help command, and instead of thouroughly researching I thought I'd ask you. 
You Can't 
I have no support (nor any plans) for coloured lighting in my light tool. TyrLite is probably your best bet here. The only other coloured light tool I know is TomLite, but I think it's based on an earlier version of TyrLite. 
Is it possible to have a lift/door go down on one button and then up again on another, then on and on and on? 
Trigger Help 
How would I go about doing the following:

Player steps into a trigger_once, thus triggering a bunch of lights to turn on and playing a "lights turned on" sound. Wait 1 sec. Another bunch of lights gets turned on with a "lights turned on" sound. Wait 2 seconds, another even is triggered.

Some parts I do understand how to do. However, I don't know how to make the delays in triggering the lights and how to make an appropriate sound play once it's triggered. 
...if it's just one level down and one level up then use door for the lift and check the 'toggle' flag. 
...trigger_relay is your friend in this instance. You can give them all the same name but have them target different light groups with an increasing 'wait' time for each one.

But be very careful, as Quake will very quickly crash if you try to overlay too many light sources on a face. 
Teleporting Boss Monsters 
Woo, made the mod, and a short test map to demonstrate it. All in the following zip 
Wonderful! This worked perfectly. Now how would I go about having a sound that would play only once when it's triggered by something? Do I need custom QuakeC for that? 
That is perfect just what I was after, thanks 
Seem to have encountered a problem, I put the bsp in the mod folder and use monster_shalrath_tele in the map and for some reason it doesn't spawn the other monsters. I have it so that once you kill the monsters the shalrath_tele gets spawned in.

I am using -game from, run, and yourmap worked fine. 
sound that would play only once when it's triggered by something

mail me your zipped QC source and I'll hook you up ;) 
sent you an email 
Did you name the other monsters as normal? I didn't change anything besides the code for the shambler and vore. Don't call the other monsters monster_ogre_tele or something, give them all their usual names. Other than that I can't say what's causing it, try some of the ID maps and see if the monsters work in those... 
Entity Count 
I have 480 entities in my map according to TreeQbsp, of which 360 are lights. How many monster can I expect to place (there are none at present) before I hit problems?

How does a dead monster's back pack affect this count?

Can anyone tell me how to calculate the position of the info_teleport_destination to allow me to teleport more than one monster at a time (I haven't tried it but am thinking two monsters, not touching, in one trigger_teleport box) i.e. in top view, does the info_teleport_destination brush line up to the centre of the trigger_teleport or maybe the left hand corner etc?

I am going to need to teleport monsters in and I thought that I could save on entities somehow - I can't use the progs.dat that I used previously as that is banned in SM40 comp rules. 
Entity Limits 
There are several limits that can cause you problems. In normal engines you can have 256 static ents (unusual to exceed this limit) and 600 "edicts" (which I believe is similar to ents).

In my engines you'll get warnings when exceeding these limits. You can always check current edict amount with the edictcount command (first number). Always check while playing on Hard and in god/quad/RL mode.

Regardless of these limits, you can have various engine overflow issues (e.g. packet overflows or invisible ents) before or after vis. 
Can anyone tell me how to calculate the position of the info_teleport_destination

You seem to misunderstand: info_teleport_destinations ( or any info_ entity ) are point entities, not brush entities. That means you should place them in a map exactly as you would the info_player_start or a monster_ of some sort i.e. like sticking a pin in a cork map board.
Keep its origin at least 64 units from any walls and 32 units above the floor.

Because of this, any two or more monsters teleported to the same info_teleport_destination simultaneously will immediately telefrag each other. Count the gibs! :D
This has occassionalyl been used intentionally for effect, as at the end of one of the Prodigy SE maps where a bunch of zombies were telefragged to rains gibbage over the player.

However, as a means to limit the entity count in your map, it will not work.
What you would need to do to have several monsters appearing at the same destination is to stagger their teleporting by a few seconds each. Or, more simply, use more than 1 info_teleport_destination near ( but not too near ) each other. 
Thanks, you have answered the main point of my question in that one cannot teleport two monsters from the same trigger_teleport box.

The other question still remains and I'll try to explain in more (but still not technically correct) detail. I am not interested in the programming side of things, only relating the editor to the game.

The info_teleport_destination entity is a fixed size when displayed in the editor, regardless of how big the brush is from which the entity is created. The trigger_teleport box can be as big as you like and generally is made to be slightly larger than the monster to be tranported. The monsters each have their fixed-size box when displayed in the editor.

So, when the monster teleports into the game, from the editor's point of view, does the centre of the monster line up with the centre of the info_teleport_destination ? You clearly know that the origin needs to be 64 units from the wall and 32 above the floor - but why? I don't recall ever placing the info_teleport_destination above the 'floor' level except where I wanted monsters falling from above the player, and through simple experiment, I know that the ogre still teleports OK even when the i_t_d is up to 8 units BELOW floor level.

I am trying to find out how the monsters bounding box relates the position of the i_t_d in the editor. The i_t_d is 40 units tall and if you place it on the floor in the editor, the monsters still drops maybe 8 units(?) when it teleports in. Therefore the monsters head must also be higher.

Ordinarilly, this is not an issue as space is available in the game's environment. However, where space is an issue, it's important.

I relise that I could have worked all this out in the time it has taken to type this post: I only asked in the first place because I'm not into re-inventing the wheel and I thought someone would know the answer off the top of the head.

And I would still like a judgement on the likely number of monsters I might achieve and whether monsters back packs affect things. Non-teknikal now :-) 
The info_teleport_destination entity is a fixed size when displayed in the editor, regardless of how big the brush is from which the entity is created.

This is the confusion; there isn't a brush for an info_teleport_destination, only a colored box that gives an estimate of the size of the player. Only func_ and trigger_ entities have brushes.
Unless your editor is somehow unable to represent point entities as anything other than brushes or you are using a custom version of the info_teleport_destination.

What you should be seeing is a solid-color box about the size of the player.

Here is a screenshot of GtkRadiant:

In the 3D view, the i_t_d is selected and highlighted. Next to it is an info_player_start which is exactly the same size and shape. It is likewise a point entity.

The center point of the i_t_d rests on the grid crosshair in the center of the red selection outline as seen in the 2D views - this is the point where I placed the entity, and this is where the game will position a monster when it teleports. 
Different editors, different phraseology, same thing.

In the 3D view I can see a model of the player, not just a bounding box (and my editor is 6 years old!). I can only see a wire-frame version of the i_t_d. In the top, right and front views, the player is 32 units square and 48 units tall. The i_t_d is 16 units square and 40 units tall.

In your screen shot, the centre of the i_t_d appears to be on grid x128, y0. My question was, will the teleporting monster land also centred on x128, y0?

The bit about 'the brush from which the entity is created' is just that as you click and drag the mouse in the (say) top view, you create a brush and it appears in the 3D view as you draw. You fix that brush by pressing Return to de-select it. But if before you press Return you select the Entity list (press E) you can turn that brush into an entity, which will immediately resize to its default if it has one or remain at the drawn size if the entity size is variable. Hence, 'the brush from which the entity is created' - just phraseology.

So anyway, what about the likely monster count? 
If I want to turn an existing brush into an entity, let's say because it happens to be the right size for a door and I want to add a door where the brush is, left-shift and left-click to select it, E for the entity list, select func-door, press return and the brush becomes a door.

I thought all editors worked like that? 
Ah ok, it was a matter of terminology. That's cool, as long as it's clear now :)

My question was, will the teleporting monster land also centred on x128, y0?

Yes, the origin of the monster will be placed exactly on the origin of the i_t_d. Which is why I stated those values - 32 above the floor and 64 from any walls. The ceiling should be a good bit more above, just for aesthetics ;)

Regarding monster counts: it does depend on which engines you want your map to be playable in, since they have different limits for total entities on mapload and also for what could be handled on screen in any given combat.

I don't really know these sorts of values exactly, that would be for an engine coder to answer accurately. But as a rough guide, my Contract Revoked maps had up to 101 monsters plus lots of walltorches and ran in GLQuake without choking.
I think PuLSaR's more recent Menkalinan had a few more beasties than that and ran perfectly well in FitzQuake.
Kinn's latest map, otoh, contains a veritable army and so far doesn't run so well in FitzQuake, though it does load.

I'd say generally, when you reach 100 monsters in a single map, you should already know where the end is. 
I thought all editors worked like that?

Nope. All the Quake editors I've tried have separate methods for placing point and brush entities. Points are simply selected from a list and placed on a grid intersection, or placed on a grid intersection and selected from a list; hence the 'pin in a map' analogy. No brushes are involved. 
you can have 256 static ents (unusual to exceed this limit)

I wish it was so unusual for me... 
Just For Info... 
... I have now played around with this transporting lark a bit more. And using the Ogre as an example:-

1. the trigger_teleport does not need to surround the monster entity in its out-of-the-way room. It works when any part of the trigger is overlapping any part of the monster's bounding box. I don't know if that is of any use?

2. the ogre spawns 10 units above the lowest point of the i_t_d, so the i_t_d can be placed on the floor of the map

3. the ogre's bounding box is 64 units square and it needs just one unit either side to manouvre after spawning, but nothing behind. The i_t_d can be placed with its centre 32 units from the rearmost obstruction.

4. the ogre's bounding box is 88 units high and he needs 99 units above the lowest point of the i-t_d (which is 88 units for the ogre, 10 units for the fall in item 2 above, and 1 unit clearance.

The above is when considering the centre of both the Ogre's bounding box and the i_t_d to be the same in the top view, and when the lowest part of both the Ogre's bounding box and the i_t_d are on the same grid reference in the front or side view.

An' I thank you. 
My current project (a Q1SP map) has 463 entities of which 371 are lights and I haven't even started placing down monsters yet... 
488 of which 370 are lights, and I am just about to start placing monsters. I'll let you know how I get on. 
I think most modern light compilers remove static light ents from the map after generating the lightmap, but I could be wrong. 
Are my emails arriving ok? I've sent quite a few recently :) 
Yes, I've received them. I'll get back to you. 
Odd Question 
Not really a burning issue, but something that has always intrigued me: in the QC, what does the "th_" prefix stand for on the monster ai functions? (like .th_walk, .th_die etc.) 
Error Message 
I get an error message in QBSP that goes something like this:

WARNING: Brush with duplicate plane on line XXX

What does it mean??
I get like 50 of them all on diffrent lines.
Will it cause trouble? 
Those are function pointers to their respective ai functions (th_walk is walking, etc). Its like 'when i am told to die i go to the function that is enforcer_die()' (or whatever). Sort of like a finite state machine. 
Lol, yes but what I meant was: What is the historical significance of the "th_" prefix? Or more specifically, what is "th" short for? 
what kell said. 
Yes, that makes sense. 
During polishing my entry to SM40, I moved a couple of brushes and now have a leak through a solid brush.

I have used the -nosortface option and no longer get a leak reported. Clip-nodes are not an issue as I had already made good use of clip-brushes. I have fast vised and it looks OK in-game.

What does -nosortface do and why should I not use it all the time? (You probably know why I am getting the leaks - you've seen the map before allbeit that it didn't have the SM40 bits in it)

Ah, I see from the time that you are probably building up the alcohol levels at present so hopefully I will hear from you sometime next year! 
Take a look at my Q1 ToolTips document at (link bottom right). It contains among other things
explanations on some of the warning/error messages from the tools. 
-nosortface just disables the automatic brush face sorting before build. This is done to make builds more consistent, since some editors (e.g. QuArK) shuffles the faces around between builds.

Theoretically, the face order shouldn't make any difference, but it does (as you've already noticed). Apart from the consistency, the chosen order is also an attempt to improve build quality by putting faces on opposite brush sides next to each other. Don't ask me why this helps ...

Normally, I definitely recommend to keep the automatic sorting to avoid e.g. leaks popping in and out between different saved map versions. If you choose to disable the sorting, there's also another face order you can try (if the current doesn't help). Just use my ConvMap utility to reverse all faces in all brushes, e.g. convmap -r -i sm40. See the readme for more details. 
OK, thanks. 
I See... 
Nice txt file by the way... q1 is lucky to have you. 
Q1 is even luckier to have mappers still creating new material. 
Scampie's Post, No. 3038 
Hang on, what's the implication here? If the light entities are removed from the map (.bsp file), does this mean I can put more monsters in?

Where, or when, is the entity limit significant? Do the compilers baulk at large numbers of entites or is it just the engine? I have 597 fixed or modifiable entities in my version of SM40, of which 392 are lights. I would happily put more monsters in as I get the distinct impression that players like lots of opposition when playing.

I am just about to do a final, full overnight vis, so any answers today will be appreciated. 
... Light before Vis or Vis before Light? 
It Duzzn't Mattah! 
Really duzzn't mattah! 
All light entities are stripped out when the level loads, with two exceptions:

1) Switchable lights, because these need to hang around so that they can be "triggered".

2) Lights with models (torches etc.) However, these get turned into static entities, and therefore do not contribute to the edict count.

Bear in mind that there is nothing significant about light entities that distinguishes them from other entities. By this I mean (although there's not much point) you can give any entity a "light" field, and the light compiler will light the surrounding area accordingly. This is why most light entities are stripped out on level load; they just act as placeholders for light information, and do nothing else.

In conclusion, you could have thousands of light entities in your map, and it would cause no overhead if they all get stripped out at startup. 
for your responses. 
In conclusion, you could have thousands of light entities in your map, and it would cause no overhead if they all get stripped out at startup.

...that's comforting, ta mauch! 
Quake 2 Compile Tools And Texture Sets 
What custom compile utilities exist for Quake 2 and what are their main advantages over the vanilla ones? Also, where would I go to download some good custom texture sets for Quake 2? 
if you can find the latest GDDBSP and GDDVIS, and ArghRad, those were the top of the line for Q2 last I knew, that being right before q3 came out, not sure exactly what GDD bsp and vis added, but arghrad has a ton of extras, including phong shading.

good luck on custom textures. weren't many sets, because q2 doesn't have .pk3 formats and textures aren't included in the bsp so they never caught on. 
on the Rust message board,
Tim Wright is still updating his Arghrad tool, famous for adding phong shading (it adds smooth shading to corners and rounded areas). Other tool links can be found there as well, though I believe in most cases the Quark tools may be the most current.

As for custom texture sets for Quake2. I would suggest hitting the wadfather (planethalflife/wadfather), and it may be helpful to know this as well: I have never known any Quake 2 enthusiest to have any apprehension in using the customized versions of the Q2 engine (like Quake2Max for instance).

The pallette for Q2 is more restrictive than Q1 IMHO. In other words, you can get away with using q3, Unreal or any other texture set without getting bitched at. 
I did find ArghRad quite easily, but I couldn't find GDDBSP and GDDVIS. Could anyone provide a direct link or send them to my email if you have them on your PC?

Metlslime: thanks. 
Re: Compilers 
Arghrad definitely.

As for the gdd compilers, i heard good things about them, but checked my old batch files and it seems i was still using qbsp3 and qvis3 when i last did quake2 stuff. 
Mirrored Textures 
Is there some way to mirror a texture using gtkradiant? For example a texture thats only half an arch. 
use a negative value for the X axis texture scale 
Im sorry but it seem that in the surface inspector there's no option for X axis texture scale. Only horizontal and vertical. Tried flipping the brush X-wise but the texture dont stick. Im useing ver 1.4 
by X axis I meant Horizontal stretch. Sorry, i was thinking in terms of a paint prog. 
I got a question for you.

As I mentioned before in GA thread, I got a new PC. Fitzquake started to render properly (080beta), but your glquake started not to render in the way that it should. All textures look grey, but lighting effects still exist.

Is there any solution for me? 
You Should Probably 
find out what kind of video card you have. 
I know it's all because of new video card. It's rather shite (all-uncluding-mega-motherboard), but is there any way to avoid this rendering problem without changing my videocard? 
I have no idea, GLQuake doesn't require much to work. Have you tried the old GLQ 0.97 or other engines? Have you checked the console at startup for error messages or other info? Enable option -condebug for logging to file and send me the zipped file.

Having grey textures sounds a lot like a texture problem. Is it the same problem regardless of map?

Maybe you'd better send me all this info in an email instead. 
Having grey textures sounds a lot like a texture problem. Is it the same problem regardless of map?

No, that's not a texture problem. To be more correct I should say that every wall is just grey with no texes on it.

Maybe you'd better send me all this info in an email instead.

I wanted to do it, but I don't have a mail client so far (I'll get it tomorrow) so I decided to post it here first. I think I'll send you a mail with screenshots and more details tomorrow. 
By Texture 
problem I meant that the uploading of texes to the card doesn't work properly. Maybe a multitexture problem, try -nomtex option.

I did a quick search on usenet and suggestions were bad drivers (update available?), 16/32 bpp issues (try using same depth as the desktop) or even the classic 3dfx opengl32.dll file (should be removed from the GLQ dir if you don't have a 3dfx). 
Ms2 Mesh Files For Glquake 
what's the deal with .ms2 files being generated in glquake? does each computer generate a unique file that only works on their computer, or can these ms2 files be packaged in a .pak file so that players don't have to sit and wait for all the new models to mesh the first time? 
To be more correct I should say that every wall is just grey with no texes on it.

It sounds like what you're seeing is the lightmap. Which implies that the textures aren't being loaded at all. 
AFAIK the meshes are only depending on the mdl file so they can be pre-made and distributed with the pak. Note that only mdl files in the progs dir (not subdirs) are meshed. Also note that some engines don't use the mesh files at all; they rebuild from mdl each time. 
Note that only mdl files in the progs dir (not subdirs) are meshed
haha, don't i know it. ;) 
Oh And... 
can't believe i forgot, but thanks for clarifying that. :) 
haha, don't i know it. ;)

Fitzquake HUD 
I keep losing it: it's there when I start but as soon as I move, it disappears. Drop the console and it comes back, press escape and it comes back. But as soon as I move in-game it goes.

I haven't knowingly changed anything. Any ideas? 
gl_clear is on? although fq is supposed to fix that, and it does on my computer... 
Thanks, if I type 'gl_clear 1' at the console my HUD remains on.

Anyone know why it changed or how to fix it permanently? 
did you try different vidcard drivers?
or maybe different fq resolution/bpp? 
Interesting: I changed the bpp from 32 down to 16 and the HUD stays on. So my .bat file now reads, quake.exe -width 1024 -bpp 16.

I wonder if it's been missing all the time but I've only just noticed it? Nah, surely not. 
But 'ang On A Mo'... when I no_clip, which I'm allowed to do when creating maps, I get this awful reflection/banding/graphic interference on the outside of the playing area. And it goes if I use bpp32.

So, does this mean I can't have my cake and eat it? 
it must be that your drivers clear the screen even if gl_clear is 0. That explains why the hall of mirrors effect you describe in #3089 is new to you, and it explains why fitzquake isn't redrawing the statusbar every frame (becuase it thinks the screen isn't being cleared every frame.)

Solution: gl_clear 1. That way you can keep all your other settings, like bpp and stuff. 

I changed my video card settings on Open GL to Application Preference and hey presto, all OK.

Perhaps they got changed when playing HL2 or Doom3 recently? 
Have you received my last two emails? 
Have you managed to fix the GLQuake problem or have you sent me any info? 
Yes! I hope you get my reply! 
D3 Sound Question 
I thought to create a ambient sound you simply used a speaker entitie and assign it a sound within it's property. Appearantly thats not it, any clues how to properly implement ambients? 
Texture Question 
I've never been a huge fan of using textures from other games in Quake but I want to use some from Unreal 1 and Quake 3.

The map is mean to be able to run on any engine. So I'll be using standard wads.

What, if any limitations are there to converting Unreal 1 and QUake 3 textures to Quake?

I've seen both used and I assume they turn out ok. Are there any that just look shit?

To make things easier on me, has anyone already converted those game's texture sets to Quake wads? I'm doubting it due to the legality of posting the wads online. 
some look good, some don't. it's a matter of converting them all and removing the ones that look ass.
in general though, unreal textures tend to look worse than q3 ones do, but only in general. some unreal textures convert over nearly perfectly.
it all depends on the colours used in the original texture and quake's palette. 
technically, it's illegal to use any other game's textures and release them in anyway in your maps... but most often, it's completely ignored in q1.

only thing I have to add is to remember that q3 textures are double sized, so you'll need to size them down before converting to q1. 
Q3 Textures 
Importing Complex Brushes From Maya / 3DS Max 
I am wondering if it's possible to create mapobjects in Maya / 3DS Max and then proceed to import them as brushes into a Q1 or Q2 map? I recall seeing some screenshots of Darkplaces showing off some uber-complicated brush objects in Q1, how was that done? GTKRadiant also seems to be only able to open .map, .reg and .xmap files. How would I go about importing something from a 3D design app? 
well, you can easily export from 3dsmax as .dxf, or .3ds both of which are easily importable into a .mdl file via qme and i know there is a conversion tool that can convert .mdls over to .map format.

i don't really see the point of this though... most likely you'll get funky compiler errors in q1bsp format.
you may as well just keep mapobjects as models and go from there. 
Can anyone point me to a working download?

Also, Tri2map and Raw2map. Like Jago, I want to explore the possibilities. 
Sound In Doom 3 
I'll ask again, how exactly do you implement an ambient sound in Doom 3? I thought you simply used a speaker entity and assigned a sound to that, however it doesn't seem to work. Help anyone? 
Legality Of Textures 
I know it's technically illegal which is why I've avoided it up until now. But since a lot of mappers use them in Quake I'm tempted to as I think there are some that are do look good and I wouldn't mind using 'em.

I'll just dump 'em all and make a little project out of converting them. 
Tho I've not touched d3 for awhile, I think you need to set a sound shader to the speaker. Exactly how you do that I'm not sure... I'll try and poke around abit later on tonight with d3 and see what comes up. 
if you have 3ds Max you may find this plug-in useful.

another possibilaty you may want to look into is the splashdamage forum

There is alot of discussion on using q3map2 in using .ase's (3ds ascii model format) to accomplish what you are asking.

However, for nonterrain models, Necros is likely correct 
q3map2 is for quake3 Arena of course, but if you can successfully decompile a bsp using ase (I believe spawnflag 6 on the misc_model entity will cause an .ase surface to be treated as a regular brush in terms of collision and lighting), you should be able to further convert it to a Quake1 map file. 
Modelling Question 
Is it at all possible to get a quake1 .mdl loaded into milkshape to have some new animations-made via using bones? (or any other program, I haven't touched em MS3D in ages, but i dont remember mdl support being very good). Id like to do some animations for ....a project, but i dont want to do them by hand (nor do I really have the ability to, qme doesn't like me) 
The person to speak to about this is necros, definately.

but i dont want to do them by hand...qme doesn't like me

I share your pain. 
Animation With Bones 
The quake models don't store any bone info,so you'd have to set the skeleton up yourself. But once you did that, there's no reason why you couldn't use them to animate it. If the export to mdl format is lacking, then you can export to md2 or md3, and then convert it using quark. 
afaik, milkshape should accept .dxf or .3ds format, which can be exported from qme, so just load the model in qme, select a frame you'd like to use for the skeleton, then export that one. import in milkshape, rig it, and start animating. it works very well! ^_^ 
that shouldn't be a problem. You will have to convert the bone positions into keyframes for your .mdl's. I don't know if Milkshape does it (hard to imagine with the Half-Life and Quake support it would not have that sort of functionality) but Blender has a very good md2 model plugin script as well as skelatal to key frame conversion built in. 
walk around j00r map, then type "editsounds" in the console and ding! there u go, u can bring up this menu in the editor as well by typing editsounds into the console window there, gg. 
you are the king of cool for that tip :) 
...but Only For The Day 
let's not get carried away here :D 
Thanks Mate 
I'll try that when I get home from work. Top of the day to ya! 
afaik, milkshape should accept .dxf or .3ds format, which can be exported from qme...
Erm, the uh, fully working version of qme i have does not do this. the newer qme (lite?), crippled abandoned version (yet somehow is still for sale) might, but it has that frame limitation. 
I guess you meant export one frame, animate using that, then export and somehow merge into the original? I'll try that but seems more difficult that it should be. 
what have u done with scampie?! :D 
well, someone gave me a full version of the demo... (preach?)
but anyway, yeah, as long as the number of vertices are the same, you can export, bone (heh) and animate, then add new frames into a preexisting monster, no problems.

I'll try that but seems more difficult that it should be.

what other way would there be to do it? 
Upgrade 3.0 To 3.1 
If you've got the full version of 3.0, then download the demo of 3.1. It contains a patch that will upgrade the full version from 3.0 to 3.1 full. There is a good reason to do this, as 3.1 will save models as .md2s. These can be imported by milkshape with all the animations intact.

There are two slight problems with this method. One is that you'll lose some precision in the model with all the conversion, but quake isn't too accurate anyway, so no biggie. The other is that you'll rig the skeleton to one frame, and it'll match up with any new animations, but the skeleton will remain totally wrong for all the other frames the model will have. So if you wanted one animation based off the stand pose, and one based off the attack pose, you'd need to rig the skeleton twice. Also modifing previous animations would probably turn out badly, as the skeleton would only line up in one frame.

Basically though, if you just create whole new animations you should be able to do it with no troubles. 
In Aguire's Engine: 
excessive faces 33668. (crashes fq with no error) (fully sealed and vised)
i'm guessing this is actual wpolys and the only way to reduce this is to actually get rid of brushes and therefore faces. am i right?

also, marksurfaces... do they reduce along with faces? 
Max Faces 
is a bit unusual to hit, but AFAIK they are just visible brush faces. Marksurfaces I'm still not sure what they are (except being a problem in some maps).

You could try inserting a big solid brush over some more complex brushwork and see how the faces/marksurfaces are reduced. 
i managed to get faces under 32767, but marksurfaces is still over 39000. and the game still crashes. :( how can i lower marksurfaces more without having to take out too many brushes? 
if a face occupies more than one leaf, it will have one marksurface for each leaf. The only practical way to reduce marksurfaces is to reduce faces, as far as i know. 
well, thanks for the info i guess. :\ more pruning is in order then. 
afaik, milkshape should accept .dxf or .3ds format, which can be exported from qme, so just load the model in qme, select a frame you'd like to use for the skeleton, then export that one. import in milkshape, rig it, and start animating. it works very well! ^_^

How exactly do you get the animation from milkshape into the .mdl file?

I exported a frame from qme (lwo seems to be best for this), made a skeleton, and silly test animation in milkshape. I export from milkshape into md2. I load the new md2 in qme. I export the frames of the new animation (to lwo/dxf/hrc, whatever). I open enforcer.mdl and import the frames but the mesh is messed up. See:
Note- that is a view from the front (!).

I *think* this could be avoided if there was, god forbid, some documentation on compiling to quake .mdl directly from milkshape. But for the life of me I can find none.

judging by past experience with the same problem and the name or the frame, i'm guessing you mirrored the whole model along the x axis? this screws up the order in which the tris are stored or something like that, so they are all flipped around. have you tried doing animations or a frame without flipping the model? did that get screwed up? (it shouldn't). afaik (and that's not that much) redoing the animation from scratch is the only way to get it working, so you'll have to reanimate the firing frames for the other side...

if anyone else knows better, please speak up, cause i hate to have only bad news. :\ 
Fixing Those Animations 
It's actually a fairly simple fix to get all the triangles facing the correct direction. Convert the model into a single object, then go to the object transformations. Set the scope to the whole scene. Set the scale on the x axis of the object to -1, and it should now work. Then you can reconstruct objects or reset the pivot if you need to do anything else with the model in qme(although hopefully you shouldn't need to) 
Foggy Ambiance 
I've played yesterday night SM40 contest maps, and I would like to reproduce the "foggy" effects I found into Mike's FMB_SM40 map. So Mike please, could you explain how do you achieve such this kind of effects ??? 
Fog... glad you liked it. First, take some dry-ice (but be careful as its surface temperature is something like -78c) and drop it into a bucket of water.

Alternatively, a simpler way is to use the _fog entry in the Worldspawn for your map. I used _fog 0.05 for Fmb-sm40, which gives a fairly good effect.

Unfortunately, this is only good for FitzQuake as other engines seem to produce fog in a different way. For example, DarkPlaces seems to just darken everything and this was not the effect I wanted. In FitzQuake you can also enter fog as a command at the console (for any map) so if you load Fmb_sm40 you can adjust the fog before your very eyes.

For anyone who has seen real fog, you would know that it enhances light and gives an almost glowing effect without necessarily making things darker.

It does obviously cut down viewing distance and just for fun I tried it with The Marcher Fortress. It completely ruined the outside areas - the skybox is too far away and became invisible and the skybox was one of the things that made the outside areas look so good.

So, use it carefully and I would recommend understatement rather than the opposite.

Hope that helps. 
you should actually do four numbers for fog in the worldspawn -- density, red, green, and blue, where all 4 numbers should be between 0.0 and 1.0. I think the reason you had problems between fitzquake and darkplaces is that they handle the incorrect worldspawn differently.

Also, you should be able to do "fog" instead of "_fog", though i don't know if this is true for all engines and whatnot.

example: "fog" "0.1 0.3 0.3 0.3" 
I Haven't The Foggiest 
the skybox is too far away and became invisible

I can't speak for DP, but in FQ ( and anywhere else I've seen fog ) the skybox is removed entirely, because the volumetric effect would break the illusion skyboxes are supposed to create wouldn't be able to see the sky if it was foggy anyway :P 
Mike & Al... 
I already known the fog console command, but I never tried it as a worldspwan field (BTW, I didn't know that it was possible, so that's why my question is...), so thank you very much for these great information !!
As well, I've already noticed that with fog you wouldn't be able to see the sky anymore.... anyway, the effect should be particularly dreadful into a cemetery for example....
Thanks again for this cool "ambiance effect related" information... 
Skyboxes And Fog 
In the original Nehahra engines, my upcoming NehQuake 3.01 and GLQ 1.26, you can have both visible skybox and fog. Not every combination is possible, but in most maps it works and can have a stunning effect.

Marcher is not well suited for fog because of the skybox size, rich colours and scenery. 
Effin' Fog 
The FitzQuake ReadMe gave the syntax as either/or.

If you use all four numbers with Darkplaces, I now know that it works as intended in Fmb_sm40

One lives and learns. 
Fog setting with 4 number works fine, so let's go for a "british weather" like map ;D 
British Weather 
would be rain, not fog. And plenty of it. 
I you can see the sky: it rain, if you cannot see the sky: there's fog ...doh !! Summer starts on 31 of july, and stops 1st of august... peraps you can see the sun by these 2 days, but not more in the year... doh !!! 
Fog On 4!!! 
'kin' 'ell! I haven't seen fog that thick since I was a kid. 
here's what *seems* to work:

- export frame from qme (as lwo)
- import .lwo into milkshape (use the lwo thats the top most, theres a couple lwo import versions)
- rig and animate in milkshape. this is weird because you're animating with the model mirrored (enforcer becomes left handed, for example, i didnt notice this until necros pointed it out).
- export as quake2 .md2
- load .md2 into qme
- export new animation frames (again, using lwo)
- load existing model (enforcer.mdl in my case) in qme
- import previously-exported frames.
- for the new scene/frames, you have to scale bye -1 in x-axis, and also rotate -90 degrees on z axis.
- now a new animation is working and actually has the same mesh & skin as the existing id model.

Subject to change of course. Dxf is a horrible format and milkshape needs way better documentation. 
that is a lot of steps.

usually, what i do is:
-export a frame from qme
-import into 3ds
-rig, animate (and yes, i noticed the reversal too... not sure what causes that though.)
export each frame to dxf files (i don't mind them)
-import them into the model.

can you not export frames in milkshape directly to dxf or lwo or whatever? it seems a lot of extra steps saving as md2 and all that...

also, preach, thanks for the info about resetting the faces. i never ran into exactly the same problem myself as it was under different circumstances that the faces got reversed. :) 
RE: Omg... 
can you not export frames in milkshape directly to dxf or lwo or whatever? it seems a lot of extra steps saving as md2 and all that...
Remember when i said it sounds more difficult than it should be? :|

If theres a way to export individual frames, I don't know it. I went through each frame, while in animation mode, and exported, but it only exported the first frame each time. Sigh.

Also for the record, I just tried rotating/mirroring the mesh in milkshape after the initial import, just to be able to animate non-mirrored and on the right axis as what it will eventually be, and that created a huge ungodly mess. I'll stick with what works for me at the moment, its only a few small animations I want to do anyways.

(and yes, i noticed the reversal too... not sure what causes that though.)
Probably the discrepancy between file formats and how they store data.

it seems like it would be easier to export all of the frames from milkshape into one folder, create a .qc file listing the frames, and compile it into a mdl with the original Id tools. 
Except you forgot the part where I said you can't export individual frames from milkshape. Hence exporting to md2. Thanks though 8-) 
you're reading the syntax for the fog console command. That's not the same as the syntax for the fog worldspawn value. I guess i never explained how to do it in the worldspawn becuase i thought i was supporting an existing standard. But maybe not... sorry. 
Some Useful Tricks 
There's an option in qme preferences, under the import/export tab, called mirror x. Try toggling that on or off. It may not be helpful, as it'll happen on both the import and export, and two reflections will cancel out, and turning it on/off in between import and export is an extra step, which is as much work as mirroring the model. But it might be handy for the milkshape stage, as the model won't be left handed.

Also, in case you're importing/exporting all the frames in a scene individually, use the export scene from the menu, and shift select all the frames in the import dialogue.

But yeah, anything you're gonna do for models in quake is gonna need a fair few steps since three is no single good modelling tool with mdl support. 
Cool preach, will try that maybe.

By the by, I did manage to just figure out how to export directly to .mdl from milkshape, you need a control file like this one that i stumbled across:
BUT, for some reason when I do this, milkshape for whatever reason removes 4 tris from the enforcer mesh, meaning the new exported model frames can't be merged with the existing .mdl. (MS3D mesh and original .mdl have 424, exported mdl has 420) Thats slightly annoying to say the least.

Oh well, back to animating :) 
Map Won't Load... 
has anyone ever seen this error?

CALL1 512(precache_sound2)precache_sound2()
shalrath.qc : monster_shalrath
Pf_precache_sound: overflow
Host_Error: Program Error

the vore/shalrath has no modified code. if i remove the shalrath/vore then it happens with another monster.

does this mean the map uses too many sounds to be precached or something? 
You can only precache up to 256 sounds; after that you will get this error. 
I Assume... 
that this is with a modified progs.dat. Correct? 
aww man.
yeah, it's a modified progs. it allows you to play any sound you want and i've got lots of machinery that all have unique sounds along with lots of new ambient sounds. i must have went over this limit at some point.

between maps, are precached sounds cleared, so that, say sounds that appear in one map and not in another don't carry over so that the 256 sound limit starts from 0 every map that gets loaded? 
the precached sounds get cleared between maps. 
Terrain Meshing 
I've just downloaded gensurf at office, and I would like to try it this evening. I'm currently using QuArK 6.4 (I know that someone here think it sucks... errr.. but it woks fine for me.. bleh.. anyway...), and I would like to know if there exists a cool tutorial/getting started for gensurf use with QuArK, or something like this... I didn't found anything relevant on the web... Thanks in advance.... 
Terrain Meshing... 2nd Part 
I made a quick test on gensurf.exe at office, and it seems it doesn't support Quake.... but newer games (Q2/3, HL, etc..) Does it make sense to use it for Quake2, and import the generated map file into a Quake map ??? Or not ?? How do you use it in fact ?? 
I don't think using something like gensurf is recommended for Quake, probably better off doing the terrain yourself... I think most Quake mappers make it themselves anyways... no? 
I don't think so... Just aking a look at Kinn's "Marcher Fortress" map for example. I really don't think he build the outside castle terrain manually... ;P... So how did he do ?? 
I mean they for sure use a terrain meshing tool, but if it's not gensurf, what is it ?? 
Marcher's outside area is definatly doable by hand with a bit of patience, but he might have used a tool I guess, dunno. In most cases I wouldn't recommend it anyways for a game like Quake.
Just takes a bit of practice with vertex and edge manip... Then again if your using Quark, good luck, cause it's hell for that kind of stuff if I remember correctly.
<insert pimpage for radiant here>. 
kinn's map terrain was built using hands only 
Bal & Vondur 
OK, if you say it I trust you, because you have for sure much more experience than me... BTW, I've read many tutorial for terrain meshing, and it frightned me (due to the amount of work it seems to be while doing it manually..), and I'm very surprised that it seems no terrain tool exist for Quake... or perhaps I didn't know it.... Is there any terrain tool for Quake so ??? 
The thing is, technically, you can very well use gensurf or any other tool for Quake, but chances are it'll cause alot of bsp problems, and you'll end up having to rework it so much that in the end you're better off just doing it manually.
As I said, quark might not be the best editor for this kind of stuff... =\ But with a bit of patience and training it isn't so long (but it is pretty boring yeah, hehe).

Quake just doesnt handle very funky brushwork so well, so it's good to keep things pretty simple and cleanly built (bleh, if only quake had detail brushes -___-). 
... so according to you I only need to be patient and take my time to build terrain... hmmmmm.... So, it will took me many years to be able to match Kinn performances !!! ;P
Anyway, thanks for your feedback... 
begin with e1m1 type o terrain, then make things more complex until u end up fighting with bsp/vis errors. 
Thank for the advice...;) 
Mike Woodham uses generated terrain in his maps. 
I used Gensurf ( as it's included as a plugin for GtkR ) to create a very sizeable chunk of terrain for a map I am currently working on ( not related to the chapters event ).
The main advantage to using a heightmap generated terrain tool like this is it makes creating and also modifying very large - i.e. the whole map - terrains much faster and clearer.
However, the absence of detail brushes in Q1 makes the compile times for Gensurf material absolutely astronomical. A few months ago, aguiRe did a full compile on a nearly-complete version of my map - it took just over a week. For comparison, that's about 25%-30% more than Marcher o_O
I also supplemented this heightmapped terrain with hand-built terrain.

So yeah, unless you have a very good reason to be chucking out vast areas of terrain, work by hand for now. 
Terrain Generation 
I've dabbled a bit with generated terrain and I've found Nem's Terrain Generator to be the easiest to use. You set how big the triangles should be, and how many on the x & y axises, then you manipulate it using built-in tools to raise/lower/smooth, all in a 3d view. It exports directly to .map. It doesn't do a great job of optimizing the output, so you may have to do a bit of that yourself.
for download and info. 
i prefer making terrain by hand... simply because terrain generators don't create the edges of terrain, only the height. you also get a more personal touch to terrain you make yourself, and you can easily start splitting up areas to create more of less detail depending on what's needed.

when you generate terrain, it's all uniform, and although it's faster, you don't get as nice a 'feel'. you can, however, always modify the generated brushes after, i guess. i just like doing everything at once. :P 
there's a bug in info_intermission description in the entities.def that goes with gtkrad 1.4.

here's the right part, replace it if you want less puzzlement with info_intermission:

/*QUAKED info_intermission (0 1 1) (-16 -16 -16) (16 16 16)
This is the camera point for the intermission.
Use mangle instead of angle, so you can set pitch or roll as well as yaw: 'pitch yaw roll'
If there is more than one info_intermission in the map, Quake will randomly pick one.
If no info_intermission entity is in the map, Quake uses the player start.
pitch -10 (look up10 degs) yaw 10 (look 10 deg left) roll 10 (tilt 10 degs right)

set 'pitch yaw roll'

Cool information you give here guy !!! Thanks as well for the related link...
BTW, I agree with necros when he says generated terrain can be perhaps too much uniform... but at least it's a good starting point, in order not to do the all work manually... 
Doing the work manually builds character. 
Doing It By Hand Is Easy 
For a few unreleased Day of Defeat maps I worked on months and months ago I created all the terrian by hand. Using the popular triangle method you can have good looking terrain in no time by vertex maniping them. I tried using Gensurf but found it to over-complicate the process and wasn't worth the hassle. Just sit down, copy/paste a bunch of triangles, and goto work. It's simple, and quick once you get into it. 
Sorry, but I disagree with the suggestion that terrain should be built by hand: it just is not necessary.

No doubt people will pick holes but look at these screenshots - the terrain took less than 5 minutes to create, and I haven't even started to tidy it up yet (I'm not going to as I only did it for this post). It's hardly uniform.

All of the terrain used in Fmb_sm40 was generated and I bet nobody noticed... because that's the point, if it doesn't blend in to the map, it doesn't matter whether it was done by hand or not.

Sure, it is not perfect but if more people embraced it they would help improve what is, after all, just a tool to aid a task.

And yes, I am anti-Luddite. So, JPL go ahead and generate your terrain. 
well, to my eyes it is kind of uniform. it's good, but it's not something i'd do with my own map.

all the subdivisions are the same size, and the edges of the terrain start and end on those uniform subdivision sizes.

if there was a way to change the subdivs so that some areas got more attention than others and to promote more than just height maps with outcroppings, overhangs, etc... 
Yes, in this example I have only use 128 triangles. You can easily achieve the effects you mention by a) using two or more triangle sizes b) off-setting 'blocks' of terrain (I daren't mention s-u-b-t-r...) and c) not trying to build everything in one go.

Your response is exactly what is needed - HOW do I achieve such-and-such effect quicker, easier, more accurately etc.

In Fmb_sm40 you can see some different effects (and I am not promoting this map as a paragon of terrain mapping, it was done in quite a hurry and has a number of flaws) but nevertheless, it has walls, floors, islands and caverns. Oh yes, and an 'organic' blob on the wall of the GoldKey area, which I forgot to texture with a suitable bloody, moving texture. Ho hum.

Mountains, canyons, caves, overhangs, parapets, bridges; all possible with a good generator. And much quicker and just as accurate as doing it by hand. But as always, if it works for you... 
i'm just one of those people that will never be comfortable using something to generate terrain.
i just like making the terrain by hand. all my terrain has been hand made and will continue to be so. :P

a) using two or more triangle sizes
what do you mean exactly? if you mean to make all the triangles smaller... yes, that's *a* solution, but that means some areas will get super hires that don't need it, not to mention wpolys will go crazy and axe (or possibly hammer?) murder you.
b) off-setting 'blocks' of terrain (I daren't mention s-u-b-t-r...)
i didn't really understand what you meant -- offset in what way? i'm guessing it has something to do with substraction, but i can't quite think of anything..?
and finally, c) not trying to build everything in one go.
you still end up having to align smaller triangles to larger triangles in the end, which is 'by hand' work, so brings me back to my original argument of doing it all by hand. 
Entity Definition File Converter 
I wrote a little program that converts entity definition files for Quake. Currently it only converts the good old .def files into .ent files to be used with GTKRadiant 1.5. Additional file formats (i.e. .fgd) and games might be added in the future.

You can download the program here: 
When using the generator, it requires a triangle size e.g. 128. If ALL the terrain in a map used this one size, you would begin to see uniformity. In my opinion, this is no more an issue than when mappers use same size corridors or wall heights. However, it would be easy to have (say) distant terrain on 128 or larger triangles, and middle distance on 64. This would break-up the visuals.

By off-setting, I mean that one block of terrain with 128 triangles could be placed on a different grid referrence to another block, again, to break up the visuals.

By not trying to build everything in one go, and the terrain generator makes it very easy for you to try to do so, the visuals will get broken-up naturally - bit of terrain, now some water, now some brick work, now some terrain etc.

Finally, seeing the restrictions in the other tools in use should not stop you trying to improve things generally. After all, nobody wants aguirRe or metslime (and others) to stop developing their tools, do we?

Moving forward is the only way. If we stand still, we go backwards.

We all still play Quake because certain mappers and certain tool suppliers are always moving forwards. Don't stop them... please. 
hm... first of all, i'd like to say this business of standing still == moving backwards is rhetorical nonsense.

this is not a matter of standing still.

this is a little bit of terrain i tossed together in about 30 minutes, so -- didn't take me long, but agreed -- it does take longer to do than in a terrain generator.

i've highlighted the relevant edges, green for the lower ridge, and orange for the upper one.

you can see how the triangles follow the curve of the rock lending a more natural edge. also, you can see what i was talking about with variable sized triangles. you can achieve a smooth transition from one bit to the next while still allowing plenty of detail.

the uniformity i was refering to is the way terrain generators make all the terrain tris in the same fashion -- all aligned onto a large grid and no room for little bits of character to make the rocks stand out.

also, note how i was slowly expanding the size of the tris as i got into the higher up parts of the rock. eventually, they would have grown to about 256x256 sized tris to make up the bulk of the far away rocks.
you can do this in terrain generators by making two seperate terrain bits and then butting them up against one another, but the transition will be noticeable unless you spend the time to make the pieces of the smaller terrain grow into the pieces of the larger one and in that case, you may as well make the terrain by hand since you'd be doing that anyway.

cheers, dude. :) 
Mike / Necros 
I agree with both point of view... terrain generator are very "easy" to use, and save a lot of time. On the other hand, that's true as well that hand-made terrain are more "customizable".. and give the mapper muchmore possibilities... There is here a trade-off to find between speed and design...
In fact mapper's experience will choose between hand-made and generated terrain...
OK, I think I have all the huge line of this design methodologie.. Thanks for this very interesting discussion, and all the advices in there... 
GTKRadiant - Newbie Question 
Is it necessary to have installed Quake3 for GTKRadiant to work properly? I get an error �GtkGLExt-warning: cannot create GdkGLContext� when starting the program. In the new release of GTKRadiant you can also directly choose the configuration for Quake1 maps. 
probably u need to upgrade GTK

and no, you don't need to install q3 files 
Is this the half-crown argument or would you like the five shilling one :-)

Everything you highlight could be done in the generator. But that is not the real point: compare the original game of Quake that you bought in the store with the latest set of map releases played in the latest engines using the latest tools. People have moved it forward - same game but better.

Not rhetoric just fact: stand still to go backwards. Don't stop people trying to improve themselves. That's all.

JPL: nice bit of refereeing. 
Let Us Go 
forwards, not backwards, upwards, not forwards, and always twirling, twirling, twirling towards freedom! 
i'll be going backwards then. lates. ^_^ 
I Just Don't See How 
Necros expressing a contrary opinion is going to set the community back. He is just giving advice concerning what he feels is the best method for achieving decent looking terrain, and he is not trying to lead a counter-revolution to dismantle the last six years of Quake mapping history. That is the rhetorical component in the previous argument. 
If the terrain is done in half the time, but is twice as shit, who wins? 
Marcher Terrain 
Just to confirm, all of Marcher's terrain was build by hand (one of the reasons it took a while to make!). This was essential so that I could have complete control over the geometry, polycount, and to ensure that the terrain elements matched up vertex-for-vertex with the adjoining castle architecture.

Using an automatic terrain generator like gensurf would have made it a hideous compile nightmare, as the terrain would intersect with the castle brushwork. Also, I don't believe there is a satisfying way to make hollow terrain formations (like caves) with gensurf, so you might get problems there as well.

(PS: greetings from Minnesota :D) 
Terrain Meshing... 
Like I said in #3181, regarding the previous posts, I now really think it's for the mapper just a trade off to find between speed and design, and clearly, it also depends on his experience..
Some prefer using generator, other prefer using hand-made terrain... Anyway, do we really care how the terrain was made if the map is good in the end ??
I have now a clear overview of the pros/cons about terrain generation/hand-made and now I just have to test the stuff, and see what will be the "good" method (in my opinion) when I will use generated terrain, or not, etc.. etc.....
Thanks again for this interesting discussion, and all the precious advices I can found here... 
Maybe I've Missed The Point... it was ME that was disagreeing with the implication that terrain SHOULD be done by hand.

I am saying that it doesn't need to be. And the point about moving forward to avoid going backwards is supplemented by the fact that certain editors now provide 'displacement mapping' built-in. But hey, I'm not after an argument here. If you don't like my generated terrain, and if it spoilt your enjoyment of my maps, I am sorry.

(Spend an extra week building some terrain by hand or an extra week compiling - who's paying my wages anyway and where's my fishing rod?)

JPL: I also use Nem's Terrain Generator. It took me about 2 minutes to build the main cavern in Fmb_sm40 (behind the silver-key door) and import it into the map. And (wait for the screams) I used subtraction, although I don't use Quark.

I will surely be hung, drawn and quartered for this outrage. 
I will surely be hung, drawn and quartered for this outrage.

I'm sure nobody will blame you for a good map, in anyway the terrain has been generated, so don't worry ;) 
He He 
no problem, I've enjoyed your maps quite a bit over the years, Mike, and I thought the terrain in your Rogue-ish map was quite decent.

I just fealt some points could use a little clarifying to avoid things getting ugly, but, hey, if they did, it may be the first flame ever sustained around a Quake map making issue without delving into politics or ego. 
GTK 1.5 gives me this error:

.\plugin.cpp: 316
runtimeerror: Parse Primitive Quake: invalid primitive type

What is this, why did it just start happening (working on my Lost Chapters map) and how do I fix it? 
Have you recently installed a newer version of GTKRadiant? I've heard of something similar to this cropping up in newer builds, try the most recent build and see if SPOG has fixed it already. 
No sweat. 
I did download the latest version, I still have a problem. :( 
Texture Misaligns During Compilation 
Argh! Textures are fine in Worldcraft 1.6, but when I compile with aguirre's utilities, some small textures are out-of place. (They are textures that have offset and scaling.)

Check shots from:

This must be a bug. And there must be way to correct it.

The map is Czg's terra6, I've modified it a bit. The original has the textures perfectly, but if I just open the given rmf or map in wc and save it again to map, it's fucked up when compiled. (Of course i can't compile the original .map because I don't know where Czg keeps his wads or their names, so I can't test if its Wc's or qbsp's fault.)

I've extracted the textures straight from the map using bsp2wad so that should not be a problem either, they should be identical.

All the material is here. 
Ok It's Aguirre's Qbsp 
Seems compiling works allright with old id utils (and iklite)... (see _oldutils.png at the same address)

What's the best qbsp to use? Or should I have some wacky options in treeqbsp so it would work right? 
try -oldaxis? or -alternateaxis, or whatever the hell that option was renamed to 
It worked! Huge thanks!! 
Worldcraft 1.6a 
Does anyone know how to get this sucker up and running in Windows XP? I got it once on an old machine but it is behaving like a bitch on my new one :(

Thanks in advance :) 
Do Not Use 

there are better solutions like gtkradiant... 
WC 1.6 
Install it and run it except it won't run, but rather it will crawl on any medium to big sized map (unless you have a monstrous CPU). What Vondur said, use GTKRadiant. 
Oh Jago 
Thats what visgroups are for. 
but it's a pain to be obligated to use them. if i wanted to load up a big map in gtkr and glance at everything at once for last minute checks, i can. it's nice to have the capability, even though you may not use it very often. 
Obligated to use them? I choose to use them, as they make adding new brushes and finding what the hell you're looking at in any 2d view much easier. To each his own, I suppose. 
well, in response to Jago's comment on wc running terribly slow on medium to large maps, you said that you can use visgroups, thereby reducing the amount of stuff on screen.

the point i was trying to make was that gtkr doesn't slow down to a crawl as jago was implying so that, you can still map even on large or medium maps without having to use visgroups to overcome slowness.

in wc, you can choose not to use visgroups yes, but the implication is that the program will run too slow to map properly without them.
thus, you are, more or less obligated to use them if you want to be able to use wc without slowdown. 
No one has Worldcraft 1.6a up and running in Windows XP?

That sorta sucks :( 
No One Said That. 
and it would probably help if you described in more detail what was wrong with wc, instead of just 'behaving like a bitch' which tells us nothing. 
well, in response to Jago's comment on wc running terribly slow on medium to large maps, you said that you can use visgroups, thereby reducing the amount of stuff on screen.
I probably should have mentioned I havent had this problem since along time ago using my old old p3 550 box. Then again, these days I have a somewhat beefy cpu and lots of memory. Use what you want. I just see alot of digs against worldcraft for *rad, and almost all of them I've never encountered or seen. Maybe I'm just lucky.

No one has Worldcraft 1.6a up and running in Windows XP?
Err, what? Lots of people do, myself included. What the problem is? 
I have windows xp and run it fine. 
NoRay Or Gib 
My maps won't compile correctly under the Normal run map settings -- I finally got them working in Expert though :)

Also, do your toolbar buttons lose their images after a compile? Thanx. 
Yeah, don't compile through worldcraft. Open a dos box and run the commands from there. Its much better. 
Obviously you have to export to .map first. 
No Shareware 
Any idea where to get the non-shareware version of WorldCraft (for Quake)?

Also - if I wanted to import a bunch of jpg files into Quake editor (WC) what would I have to do? Put them all into one pack using Wally or something? 
Make A WAD File Using TexMex 
Terrain Generator Use 
I made a test with GenSurf (not really impressive) and Nemesis' Terrain Generator (wich is really impressive...), but it generates me an amount of compilation errors (like textures/poly misalignment) during TxQBSP process that crashed the BSP elaboration... (no VIS, no Light...) so... so playable BSP...grrr...
I know that some of you guys (Mike Woodham for example if I remember well) are currently using Nemesis' terrain generator tool, so the question is: how do you avoid errors in order to build the BSP ?? Is there a turnaround (without making hand-made terrains) to be able to increase confidence for this tool ?? 
I have not experienced the errors you mention.

But given that NTG works on a grid system and in my editor (BspEditor) the imported NTG file always lines up with the editor's grid, I would suspect you may not have 'snap-to-grid' or something similar in your editor.

I don't see why you should get poly misalignment errors otherwise. I have had up to 32,000 brushes in the editor and although I have had issues, it has never been poly connected.

If you want to e-mail me a small section of a map that is giving this error, I will try it in my editor and see if I can spot anything? 
...although I am a fan of NTG as can be noted from previous posts and my recent releases, if the terrain section is only small, doing it by hand is fairly straightforward even if a bit longwinded ;-) 
I tried to compile the generated terrain only, and this kind of misalignement error remains... I'm using aguirRe's TxQBSP tool, and QuArK editor.
I know there is a snap-to-grid option for polys in Quark, but I didn't use it while I was supposing NTG generates a correctly "grided" file... Well, I have to check if NTG and QuArK grid-settings match at least.. This can perhaps explain why I had this problem...
BTW, is there a quick tutorial that explains all the NTG features somewhere ??? I found by myself how to create mountains and canyon, but I'm not really used with the others features (like smoothing options, etc...), so I need a little bit help.... ;) 
There are some tutorials on Nim's site but his site is still not accessable at the moment. He does not seem to know when it will be as it is an issue outside of his control: global_register PHP setting!

The tools do need explanation and I am not sure that I am the right person for that, but in the meantime you can use the Smoothing tool from the Tool menu at its default settings, and this will certainly get rid of the acutely angled brushes that can be formed using the Raise/Lower tool.

One word of caution though, if you use it on lower slopes it will allow the player to climb the terrain more easily - this may not be the effect you want as terrain is most often used as a barrier to the player.

Also, using generated terrain is any easy way to increase clip-nodes beyond standard limits. This will be dependent on the base triangle size (I use 64 and 128) but you will probably need to use some large clip_brushes in your map if the clip-nodes get into the high 20,000s and you still have standard walls, floors, ceilings to build.

The main thing I did wrong in the early days was to build a fabulous terrain - mountains canyons, water courses etc - and then try to build a map into it. I would suggest that a better course of action is to build the map first and then place terrain sections into it. Fmb_sm40 is a good example of this technique where the terrain is about 12 or so seperate sections. (Of course I use the term 'good example' with tounge firmly in cheek.)

Ummm, don't know if this helps? 
It helps for sure... while I already see that Nemesis web site is down... grrr...
For mu first test, I tried to create the terrain in one pass... even if I have a clear idea about what I need, it's now for sure a bad idea... well, "hierarchization" of the map will save me... I hope.... ;P I have to split the terrain in many parts...
Well, so for the moments, I have to find by myself which settings will be the better for me... Anyway, thanx for your feedback.. 
Console Commands 
Is there a way to invoke/emulate a console command from within the game (without the player knowing) by perhaps using a trigger?

I want to 'play' with some ideas but dont want to get into coding. For example (and I dont actually want to do this), 'r_fullbright 1' followed by 'r_fullbright 0' could effectively flash the screen.

Any ideas? 
not without custom qc, no. :\
the hipnotic pack does have an entity for this, i believe.

what is the specific effect you want to achieve? there may still be a way to do it. 
Well, one of the things I am looking at is the use of fog. I liked the overall effect that I had in Fmb_sm40, especially in conjunction with the underground scenario, but I am aware that you can have too much of a good thing and also that it renders the sky/skyboxes as useless.

As far as I can see, fog in the Quake engines is global and you cannot use it regionally. But I noted that it could be switched on and off at the console...

So, to achieve regional fog I could set triggers in the map file and according to where the player was, trigger it on or off. Only I now know that I can't.

Marcher's sky wheted my appetite for skyboxes and I think I can develop the underground terrain thing a bit more.

But as I say, I don't want to get into coding (old dog, new tricks). 
Hmm, in Nehahra we could turn fog on and off, or even make it change (density etc). I remember testing it by making a hallway where the fog gradually builds up as you walk furhter into it (and vice versa).
Probably requires coding to get that working in any other mod I guess though... 
yeah, you'd really qc for that, sorry. :\
i'm pretty sure i could whip up a trigger for you that would change the fog density on touching it, but it would obviously need a progs for that... 
How to select brush faces in WC1.6 (shareware)? I remember that was done with Ctrl, Shift & mouse in newer versions of WC but it doesn't seem to work here in the old one.

And how to select stuff in 3d-view window? It doesn't seem to work. 
Disable Hardware acceleration in the options menu. 
Thanks for the offer. I'll leave it on the back-burner for now but if things develop further with my ideas, perhaps I might be able to call on you then? 
I made another test yesterday night with NTG, taking into account your advices, and now it works fine :)) It seems that I made too much manipulations with brush edges and faces in NTG, and TxQBSP (aguirRe's tool) find me many warnings (CuteNodePortals, HealingPoint), and then finally found me an Error in latest hull (ReachOccupant...)... Well, I solved the stuff restarting the terrain in a simpliest way, with much more care about edges and "volume" manipulations, and now it remains me only warnings (CuteNodePortals only BTW) so I can start to build other architectural stuff on the terrain...
Thanks for your help 
Sounds good. Again, a word of caution when building architecture into an existing terrain: if you place your new brushes onto the existing grid and they bisect the terrain brushes, you are more likely to get errors. Therefore, try to keep to the same grid layout as the terrain i.e. in the top view of the editor you can see that the terrain is made up of pairs of triangles forming squares, so place your new brushes in the intersections of these squares.

Of course, you will also find that when you form a room or building in the terrain, the terrain will 'fill' the room. You then have the choice of manipulating the terrain brushwork (horror of horrors) or, and only if your editor can handle it, using subtraction.

Now, I don't have a problem with subtraction but I know a lot of mappers stay well clear of it. I suspect that this is borne out of
a) using an editor that can't handle it
b) a bad experience at sometime in their youth, or
c) a bit a mass hysteria

If you 'need' to use subtraction, I would suggest you experiment with a test map af a few brushes first, just to get the hang of it.

A final point. If you read any of the previous posts about terrain and its problems (I can't point you to the right posts as I think they are mostly in the News Archive, which is still not available) you wil know that generated terrain seems to create clipping errors during compile. These become evident in the game as invisible barriers. To minimise this, stear clear of acutely angled brushwork, only use subtraction on-grid, and avoid extremely small brushes - these are easily created inadvertantly if you use subtraction on terrain and you are bisecting those brushes.

Rock on!

Pun absolutely intentional:-)

Long post caused by lack of interest in the decorating that I'm supposed to be doing. Sorry. 
The story was I tried to make a very complex terrain into my first try, and so it was a nightmare to solve any problems. So I restart with a less complex terrain, having the same architecture, but with much more less micro-brushes, much more less polys, etc... and so it works...
My editor (QuArK... no comment please...) can't handle NTG, but it can handle multiple projects, so with a copy-paste, it's really easy to import terrain map file in the project, and so use substraction in order to "fit" with my "requirements" (I'm talking like I do all day at office... brrrr...).
Anyway, the good thing is that at least I have a good first try... and now only experience can improve the "process"...
For sure I will post some screenshot later, in order to give everybody an overview of the results.
Thanks again Mike for your helpfull advices.. 
Are you still looking for the Full version of Worldcraft 1.6? I can send it to you if you like. Having said that you would probably be better off using GTK Radiant, but if it is Worlcraft you want, I can send it to you. Just let me know
Have a look around there, you may find the info you require (selecting faces) etc. It's been a long time since I have seen WC, I wouldn't remember what it looked like 
or why not use the new hammer editor instead of wc? 
Worldcraft 1.6 
There's a link to the full version somewhere in the General Abuse section archive or here in Mapping Help, I think it still works it's where I got my copy from. 
Is there any tutorial how to enable Quake editing in Hammer? I downloaded the editor from
but I can't get it to work with quake maps.
I'm just looking for new editor - GTK Radiant somehow doesn't work on my comp :( 
Use TexMex to export your Q1 wad as a Half-Life wad3 - this can then be loaded into Hammer. I believe aguirRe's tools take care of the compilation from there, you'll have to read his documentation. 
Thanks Kinn 
I can create map files with Hammer now but I can't convert to Q1 map format. I have tried both convmap from aguirre and mapconv but the first one does nothing and the second one exits with an error. Maybe this is because in Hammer I only can choose Map Type: HalfLife. After exporting to map, the file looks like this:
( 0 -512 0 ) ( 0 0 0 ) ( 512 0 0 ) WMET1_1 [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1
( 0 0 -32 ) ( 0 0 0 ) ( 0 -512 0 ) WMET1_1 [ 0 1 0 0 ] [ 0 0 -1 0 ] 0 1 1
When compiling with mapconv the error is:
Exception EConverterError ... '[' ist kein gueltiger Integerwert.
Someone help please! 
Well sure you can send it but is it necessary? I have been doing pretty well with the shareware version so far. How does it differ?

And as for GTKRadiant - Yeah well I like the editor and I'm familiar with it but I understood that it requires some tweaking before you can make it Quake compatible. And I'm already pretty far into mapping my level so there's no need to change the editor at this point. 
Has a brush limit of 500 I believe.

Eventually you'll surpass that, trust me. :) 
I'm at 416 now:( Shit...

I have been using IKBase textures with the shareware - if I switch to registered version will they still stay in the level? Would the switch be painless? 
I'm at 416 now:( Crap...

I have been using IKBase textures with the shareware - if I switch to registered version would the textures still stay in the level? Would the switch be painless? 
The Shareware Version Of WC Has No Brush Limit. 
I've been using WC1.6 for all of my maps. No problem.

I you're planning to switch anyway, yes it should be painless. Export your RMFs to MAP for safety first though. 
And as for GTKRadiant - Yeah well I like the editor and I'm familiar with it but I understood that it requires some tweaking before you can make it Quake compatible.

Excuse me? GTKRadiant requires no tweaking at all to make it work with Quake. Just download, install and map away... 
The Shareware Version Of WC Has No Brush Limit.

Always did for me, huh... 
Mikko was probably referring to pre 1.5 versions that didn't support quake natively.

but what Gom says is true. the newest version of GTKR supports Q1 natively and i supposed to be quite painless an installation. 
Well then it seems that I have been reading old posts/news since I have been under the impression that GTKRadiant doesn't natively support Q and that you have to tweak it to make it support it (or convert the level into a Q map).

However I'll stick with WC for now at least with this level I'm working on right now. I have never built a level before with WC but I have with GTKRadiant so getting some experience is not a bad idea.

But anyways if the shareware WC really has a brush limit then I need the full one - so please someone tell me where to get it. And still - will the custom textures 'vanish' if I switch from shareware to registered? 
Well it seems that I've been reading old news/posts since I have been under the impression that GTKRadiant doesn't natively support Q and that you have to tweak it to make it support it.

However I'll stick with WC for now - at least with the map I'm doing now. I have previous experience with GTKRadiant but not anything serious with WC so I need the experience.

But anyways if the shareware version really has a brush limit then I really need the registered version in case someone knows where it is or can send it to me at

Also I still would like to know that will the custom textures vanish if I switch from shareware to registered? My level is so far covered with IKBase textures - would I lose them during the switch? 
And Again 
Well it seems that I've been reading old news/posts since I have been under the impression that GTKRadiant doesn't natively support Q and that you have to tweak it to make it support it.

However I'll stick with WC for now - at least with the map I'm doing now. I have previous experience with GTKRadiant but not anything serious with WC so I need the experience.

But anyways if the shareware version really has a brush limit then I really need the registered version in case someone knows where it is or can send it to me at

Also I still would like to know that will the custom textures vanish if I switch from shareware to registered? My level is so far covered with IKBase textures - would I lose them during the switch? 
WorldCraftFULL has been sent if you want it. 
I Don't See Why You'd Loose Them. 
they're just textures, after all, and not really connected to the program at all, wc just reads the textures.

you should be fine. 
What happened to your tutorials on converting Terragen worlds into skyboxes: your old site links are dead and I can't see it on your new site? 
Troublesome Maps - I Want Some! 
Does anyone here have any troublesome maps? I'm particularly intersted in ones with clipping problems (terrain maps would be interesting) or ones where you have a leak, but the pointfile seems to pass straight through a solid brush. I've made some progress with qbsp, but I need some more real-world test maps.

If you're willing, please email zipped .map and .wad to:

tyrann - at - disenchant - dot - net

For the time being, I'll sniff around and see what's available for download from people's sites... 
If I remember, there's a leak in hull 1 or 2 in RPGSP1. I'm not sure if that's the sort of thing your new QBSP might fix.

AFAIK, all my other Q1 maps are pretty free of errors.

RPGSP1 source: 
Thanks RPG 
Yup, no more leak. 8)

It's looking promising. Does anybody have a link to CZG's scraps listed here (the links all give 404s): 
the original archive. (no text files) 
Detail Brushes 
In Gtk 1.4, there's an option to apply "make detail" to a brush. aperently this helps to lower r_speeds. Can i apply this to a Q1 map? 
make detail is not used in Quake, but you can do other things like make it a func_wall etc, but I think you must be a bit carefull not to go overboard with the amount of them you use. Plus you should be careful, because func_wall does not block vis. (I think) But someone else who can explain it better than I will come along. But in short, No to Detail Brushes in Quake 
Got It 
Thanks Necros. I'll run some test on these today. aguirRe has also done some testing now and there's a few things I'll need to follow up from there. 
Well I got the full version from VoreLord (big thanks) and the switch was simple & painless.

One thing: I have to set up the directories & settings every time I open the program. It just won't save the changes or something. I didn't have this problem with the shareware version.

Second: What does "WARNING: brush with duplicate plane" mean? 
maybe the config file for wc is set as readonly? 
Take a look at aguirRe's Q1 Tool Tips at

The short answer in this document is:
"Brush with duplicate plane on line x"
Non-critical since the reported brush faces are skipped. Usually caused by an editor error.

But there are many other cool informations and advices about tools problems, and how to avid them... 
If you're using worldcraft, usually loading the .map will get rid of the offending brushes causing the duplicate plane errors. But then if you save to .rmf (to overwrite the borked one) you lose your visgroup/camera info, though. 
My door is off-grid in my map. In GTK it's lined up perfectly, with Lip of "0", but when I compile it moves and stops like it has a Lip of "0.5" I've tried setting it to have Lips of 1, 2 and 4, but they're always off.

I'm not sure why this happens, it was working fine in earlier versions and only started recently. It's for the Lost Chapters mod, but I've had this problem before when I worked in Hammer, but I'm not sure how I fixed it there either.

Any solutions, or should I remake the door? 
when lip is '0', the code actually defaults to lip '8'.
the only real solution (barring code changes) is to make the door 1 unit taller than it should be then set the lip to 1. 
Well I don't but this seems pretty critical. This is what I get when I try to compile: "The file d:\games\quake\id1\maps\jatkuu.bsp was not built. Do you want to continue?"

If I click 'yes' it just prints the following in the compile window:

** Executing...
** Command: Copy File
** Parameters: "D:\WORLDC~2\RMF\" "D:\games\QUAKE\ID1\maps\"

** Executing...
** Command: D:\worldcraftFULL\Q1Tools\QBSP.EXE
** Parameters: D:\games\QUAKE\ID1\maps\JATKUU

outputfile: D:\games\QUAKE\ID1\maps\JATKUU.bsp
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush with duplicate plane
WARNING: brush plane with no normal
************ ERROR ************
Line 4478 is incomplete

** Executing...
** Command: D:\worldcraftFULL\Q1Tools\LIGHT.EXE
** Parameters: -extra D:\games\QUAKE\ID1\maps\JATKUU

----- LightFaces ----
extra sampling enabled
************ ERROR ************
Error opening D:\games\QUAKE\ID1\maps\JATKUU.bsp: No such file or directory

** Executing...
** Command: D:\worldcraftFULL\Q1Tools\Vis.exe
** Parameters: D:\games\QUAKE\ID1\maps\JATKUU

---- vis ----
************ ERROR ************
Error opening D:\games\QUAKE\ID1\maps\JATKUU.bsp: No such file or directory

So no BSP is created - I can't play it. Even the old bsp with the same name disappeared along with this problem. Any suggestions? 
Complete Line 4478 
that is what I would recommend doing.

Open up the map in a text editor. I would bet you a donut that 4478 is the last line in the text and it is lacking a '}' to encapsulate the worldspawn entity. 
I'm More Inclined To Say... 
...the six milllion 'brush with duplicate plane' errors aren't a problem, but that 'brush with no normal' error at the end is AFAIK a compile breaker. Fix that brush and you should be right. 
Could It? 
So I just have to find the brush first. Could it be a cylinder I created? The error occured for the first time a bit after I had created the level's first cylinder brush. 
I'm Not Sure 
but MapSpy might be able to find the bad brush. It's designed for Q2, but it's also great for finding BSP problems in maps for all Q-engine games. 
"State File Out Of Date" 
Any idea what this is?

---- Vis 2.29 ---- Modified by Bengt Jardrup

File: E:\Games\QUAKE\ID1\maps\opstart.bsp
166 portalleafs
645 numportals
State file out of date, will be overwritten
testlevel = 4

Using Bengt's latest tools, have checked the Tool Tips txt, doesn't say anything regarding this. it took 28 seconds to VIS a real small room on full, which is I thought was odd. 
is when the vis save is out of date w/relation to the bsp file.
usually happens when you compile a map again and the statefile for the vis processing is out of date.

you can safely ignore this. 
Ok Thanks 
Never got that before. 
If I were to bevel every rivet texture like this, and other textures throughout a map along the walls and floors...

What would that add significantly too, if anything? 

you're wpoly count will go up quite high as will clipnodes unless you clip _all_ those surfaces
marksurfaces will be affected too, i'm sure, but not by how much
it would look damn cool, but lighting may also be a little strange at times unless you use a high anglesensitivity setting un aguire's light program. 
I realized exactly how bad this would become doing this for every texture just to compensate for lack of bump-mapping and not forcing the player to use a custom engine...

It sure does look nice though:


Could be doable for a small map... 
Sorry, Dude, But IMO That Looks Pretty Bad 
that sort of technique works a lot better in quake3 (and quake2 probably,) where the inverse lighting model is designed to flatter it a lot more. Quake's lighting model seems to work best with big, simple geometry with high-contrast textures for details.

all this is my opinion of course.... 
And Btw... 
why do all your screenshots look so washed out? like you're using the old glquake -gamma feature or something. 
To Each Their Own 
Maybe the problem is the bevels are too big anyways.

Heres a question about Bengt's tools. I've checked the readme's and stuff and can't find any info on water transparency. I know you can type r_wateralpha x.x in the console, but apparently this only works for maps that were compiled with support for wateralpha, correct? Cause I tried it in a test map, it worked. I tried it in an id map, it didn't work. Would it not be wise to set the wateralpha in an autoexec for the player, or just tell them to type it in. 
Washed out? You must have a bright monitor, it looks fine to me. Screenshots end up as really dark TGA's, I up the gamma to about 1.5 to 1.9 depending and they look better. 
Skin Export 
What does anyone use to export Q1 skins? I have Qped which manages PAK files, it can view the skins properly, but you can't export it - just the .MDL. If I open the MDL with "MDL", the skin colors are fucked. Or if theres a resource for Q1 monster base skins... 
Yeah I just found it, thanks anyway :D 
So I'm testing my skin in progress, have added it to the MDL, then it's going in a custom pak. QME has a limit of 20 frames, cannot export Ogre.mdl and MDL 'Quake Model Editor' says 'floating point overflow' :| 
Skins, QMe And All That Stuff 
If you're just looking to swap the skin on a model, adquedit will suffice. But because it's such a handy program to have around in full, I'd recommend getting the full version of QMe. t's handy for editing the mesh or animations of a model, plus gives you a preview of the skin on the model straight off. Add to that the two click removal of any fullbrights, and it's more useful than anything else. The full version of 3.0 can be found at
You can use the patch that comes with the 3.1 demo to turn this into the full version of 3.1. 
Thanks about the full QME but the file is not at any of the servers linked there. I'll go hunt around for adquedit. 
Scroll down to the external mirror site link. 
Got it thanks. 
What is it that the doors are doing/not doing wrongly?

I can see that you have some multiple-triggers that seem to be unattached, but give us a clue and someone will help. 
Here's some shots of some terrain I'm working on using the triangle method. Generally I'm doing this in seperate groups of tris and then join all them together at some point.

In the 1st shot on the grey bit theres shadows, this is because that group isn't finished - some tri points aren't met with other points to provide a cleaner terrain - don't want the player getting snagged on this, although you could place clip brushes. 
in the last shot I can see a vertex meeting the middle of an edge in the top-down view; surely that's not a good idea, as it might not line up ingame? 
Could you circle the area you see this in? Worldcraft reports no problems, and neither does quake. I've made a flatter, bigger mound recently. 
A Good Rule Of Thumb 
When using the triangle method is to never have more than three triangles sharing the same point...otherwise it can look too artificial.

There's a good tutoral map at for doing the triangle method. 
"triangle method" is called 'trisouping'. 
"Hi My Name Is Sean, I Work At Raven" 
I am the definitive Quake resource on this board because they pay me to glue models together at Raven. But when the Bobs stop by Madison, I'll have the same fate as Michael Bolton. 
All Right, All Right 
"triangle method" is also called 'trisouping'

Is that better? 
Are you confusing me with Starbuck again? (Hint: same colour name != same person) 
Terrain With No More Than Three Tris Sharing Any Given Point? 
Good rule of thumb? Try "geometrically impossible".

Six, maybe (four is the minimum). I'd be more inclined to fuck rules of thumb off entirely in this case. 
Are you confusing me with Starbuck again? (Hint: same colour name != same person)

No, but if you have the same 1st letter and the same number of letters in your name, then you're the same person ;) 
Well I was only implying the confusion was caused by nick color and not.....
oh shit 
Try "geometrically impossible".

You just aren't trying hard enough 
I got a *** WARNING 22: Healing degenerate edge at (43 -168 224) in all 3 hulls in a map I'm working on. Your tooltips say to not really worry about it, but I'm wondering why I'm getting this error now when I haven't gotten it before. I have indeed changed a couple things, but none of them were in the region that gave the warning. 
That's Not Unusual 
having such warnings pop up or disappear while changing seemingly unrelated stuff. It can be the editor shuffling things around in the map file or qbsp balancing on the edge due to the float calculations.

Most likely you don't have to worry about it, otherwise check out the position in hull 0 and see if you can find any off-grid vertex. Hulls 1/2 will probably follow a fix for hull 0.

You could also try Tyrann's new qbsp; it has a lot of changed logic that might help. 
No, but if you have the same 1st letter and the same number of letters in your name, then you're the same person ;)

Starbuck is Shambler! 
OK Then 
I just wasted a good hour of my night trying to prove a point, but it was all worth it.

You'll notice that no more than 3 of the "terrain" triangles share any point. You'll also notice that you have the ability to move through some of the brushes, despite the fact that there are no func_illusionary brushes :(

It will eventually compile without those brushes that you can move through if you play with the size and style of the troubled brushes a bit. The .map file is included as well as a .bsp, so have at it.

P.S. I suspect that this map file would work flawlessly (i.e. without the move-through-able brushes, in Q2 or Q3) 
You'll notice that no more than 3 of the "terrain" triangles share any point

You'll notice the pertinent inclusion of quotation marks around the word 'terrain' :P

No more than 3 triangles share a vertex because this isn't terrain, it's a path
Thanks, AguirRe 
Triangle Method :) 
Hey - this solves many of my problems! 
OK, I retract "geometrically impossible", since I admit that you've got some "terrain" here, and that of it's vertexes, none has more than 3 attached triangles. But that's only becuase...

a) I'm a very sweet, lonely guy;
b) "Terrain" is a term flexible enough to encompass not only general solutions to the problem of tiling an area with triangles, but also freaky special cases like this;
c) You're cheating.

PS Nice maplet...especially the trigger_changelevel. :p 
This map compiles perfectly first time with the latest tyr-qbsp. No modifications required. 
Starbuck is Shambler!

Go map. 
Was the point simply to show '3 sharing a point' or were you looking at something else to do with terrain?

I have more than a passing interest in building terrain so am keen to learn anything even if it's not everything. 
You mean it compiles without the messed up brushes? 
VB6 Help Required 
This is mapping related...

I am writing a compiler GUI in VB6 as the one within my editor (BspEditor) is a bit long in the tooth and has only a very, very few options: it mainly works off batch files.

Can anyone tell me if, when I save a map just before compiling, that file information (specifically the file's path) is held anywhere in the Windows environment AND could be extracted/used by a stand alone VB6 program? A sort of this-was-the-last-file-saved variable.

I realise that I could 'hard code' something or let the user (me) select the current map from a CommonDialog1.ShowOpen command, but the editor has a save-before-compile option, which I always use. Also, as I save versions of the current map, I am looking for a way to automatically pass this information to the GUI compiler - or, more correctly, let the VB6 program 'grab' the file information from somewhere.

I know a little bit about VB6 and very little about Windows OS.

I hope this makes sense.

Your suggestions will be appreciated. 
Map Path 
That could be tricky, since only BSP knows where it saved the map and if it doesn't store this info immediately in the bsp.ini file, I doubt you can pull it out. This info is probably only updated when BSP exits.

AFAIK there's no "last saved file" var in the Windows environment (wouldn't make much sense anyway as files are saved pretty often asynchronously).

Is your frontend completely stand-alone or is it called from BSP at compile time? In the latter case maybe BSP could pass the path in the call. 
I can't find any files that BspEditor saves immediately other than the batch file that BspBuilder uses. I know that BspBuild is written in VB6 but looking at the history of the two programs, it seems as though Yahn B. and Tony B. co-operated on this point: BspEditor has a BspBuild option built-in so passing the data across would not have been difficult (but at present, I don't know how).

To answer your last point, my program is written as a stand alone .exe. However, BspEditor has the BspBuild option, and if I put my .exe in the same directory as BspBuild and rename it BspBuid, I can run my program from within BspEditor. And I wanted to use the the editor in this way to ensure that I always compiled the latest version of the .map.

Of course, I could do all this from outside of BspEditor, and in fact this was the original intention. But in testing, I realised that everytime that I wanted to increase the version number of the current map in the editor, I would have to update my compiler routines. It's not that it's difficult, but there is a 'nuisance' element and, knowing me, likely to be forgotten if I have to do it manually. And the result of that is that I will compile an older version of the map without realising it!

At present, my thoughts are; I know the directory where the .map file is stored, and I know that it has just been saved, so I could look at each file in that directory in turn and use the file with the most recent time stamp - no hard-coding and reasonably foolproof. But it adds to the time factor.

I am trying not to hard-code any directory information i.e. have not, but I do save all current selections to an .ini file and that gets loaded as a start position each time the program is run (I don't want to use the registry). Generally I am only working on one map at a time and during the course of (say) two hours mapping, will compile three or four times. I do not change the options much in that time.

You've seen the GUI, it's only a case of clicking check boxes and selecting the relavent directories and again, these do not change much. Also, if run as a stand-alone program, I do not have to exit the program: it can sit on the task bar until I want to compile again. If I run it from BspEditor I will have to exit and close it to avoid having many versions of the program running. Each of these scenarios has benefits.

Mmmm, bit of a long post again, sorry guys. 
I expect BspEditor is passing the name of the map file as an argument to the BspBuild program. This should be easy to test (VB must have some argc, argv equivalent). I don't think that there's any communication between the two programs after BspBuild is launched, so BspBuild won't pick up a change in the map's filename if you re-save the map in BspEditor with a different name. Myself, I always use batch files. 
Perhaps It's In DOS? 
Looking at the batch files supplied with BspEditor, the file name is passed to the different statements by the DOS variable %1. Perhaps that might work?

Slight pause....

Nope, didn't work.

Tyrann, what are argc and argv? 
Argc And Argv... 
are the commandline parameters passed to the executable, a la "-heapsize 48000". In VB the string of parameters typed in after an executable is called Command. Type Command in your VB code, highlight it and hit F1 for more details. You could use this and your mock BspBuild executable to test for any commandline arguments being passed from the BspEditor. 
Thanks for that.

The map name is indeed being passed from BspEditor to BspBuild in this way and I can now read it.

What a very helpful forum this is :-) 
I am glad I have finally made a significant contribution to someone around here :) 
Q1 Tools Update 
at . All engines are updated with many features/fixes, Light includes a new skill target check and Tx/TreeQBSP includes new clip hull code by Tyrann, especially beneficial for terrain maps. Please also see readmes for details.

Any comments are welcome. 
The clip hull fix in these (also in tyrann's latest compiler) is awesome -- not just for terrain maps, but also for maps where you have lots of miter joints, hollow pipes that bend, crazy spog-like cylinder stuff, etc. 
I Would Just Like To Add 
That using these new compilers, Marcher's #clipnodes dropped from around 32k, to 25k.

I'm tempted to restore all the stuff I had to chop out in the release version o_O 
Marcher SE? 
Funny Really... 
I've been using BspEditor for about 6 or 7 years and have just found out today that holding CTRL and LEFTCLICK allows you to rotate a brush in the map view in real time. And the degree of movement is shown on screen as you move the brush.

Up until now I've been using the RotateBrush button - you know, nudge it 5 degrees have a look; no, not quite right, nudge another 5 degrees have another look; no, still not right...

Obviously therefore, my next map will have plenty of leaning crates, haphazardly abandoned bricks, fallen beams etc :-)

Just thought I'd share... 
Splitting Faces 
if you split a brush in half, but the texture is the same and the sides are still coplanar, will they be split in game or will they be recombined by qbsp?

ie: you're using two sides of a brush for a wall, but one side has trim and the other doesn't, the trim side will obviously be split because the texture will be different, but what about the other side that has the same textures on both new faces? 
My next map will also have leaning crates, haphazardly abandoned bricks, and fallen beams, but unlike Mike it will not be on purpose. :( 
In general, they will be rejoined by QBSP if they are coplanar, have the same texture, and have the same texture stretch, shift, and rotation.

However, if you're just making a column in the middle of a room and split it horizontally so it has a cap with trim on one face, then it's quite possible that QBSP would go ahead and split all the other sides of the column, too. 
I Know 
Marcher: The Compiler's Cut 
In Case Anyone Needs Any Further Convincing: 
This is a shot of Marcher's geometry in hull 1 using the original brush expansion logic:

This is the same area, in hull 1, using the new brush expansion:

'nuff said o_O 
Forgot To Add 
Thanks to aguirRe for the above screenshots :D 
Kinn & Al. 
I've tested last week a "beta" release of aguirRe's new TxQBSP tool, and I noticed some improvement in VIS process.
Accordig to aguirRe, it seems it was pure coincidence, but.. I'm not convinced... so I just would like to know if anybody noticed this kind of effect ?
I saw that with this new expansion logic, VIS runtime process was reduced... For long process, winning some few percents for the "base start value" is a real gain in global runtime... So anyone noticed something equivalent ? 
bloody hell! 
That Should Be... 
... 'kin' 'ell! 
Hmm. Surprisingly, that second one actually looks like it's built correctly by QBSP. Who'd have thunk it? 
Terrain Expansion 
yeah, I have yet to try this out on my own terrain map, but it looks very sweet. 
GTK 1.3.12 Mouse Problems! 
I've posed on a few sites and havent gotten anything helpfull, i pray you can help.
I'm trying to edit for jedi academy, got 1.5.0 but doesnt load everything... 1.3.12 is good on the textures, but i have a worse problem, i cant move around in the 2d/3d window using the right mouse button (whenever i click/hold it and try to manipulate ether view it ether goes straight down in the 2d view, or straight up in the 3d view.) the last place i posted i was told that its possible to change/swapp out a config file or something... sounded pretty halfbaked, but if anyone can help me i will be in your debt! thank you for tryin =) 
Ice Quake? 
I've been trying to install the quakecapture_bin_20040801
This for making some demofiles editing.
I installed the programm, but when I touch glquake I enter an icy Quake world.
Only the sky texture comes through.

Is there a way to get the texture back? 
adding option -no8bit
That works. 
This Info 
and other engine problems are also listed in my latest ToolTips, Engine section. 
For Doom3 Mappers 
Just this on, some doom3 mappers may have missed it? Anyway it explains all the doom3 compile vars and their effects, very handy to know...

glview Not implemented
v Print extra information as the map is compiling
draw Render the level as it's compiling (not sure if this works anymore)
noFlood Don't 'flood' the level marking outside surfaces invisible
noLightCarve Don't carve geometry based light volumes (default)
lightCarve Carve the geometry based on the volume of the lights that touch them
noOpt Don't optimize (merge and cut) triangles
verboseentities Print extra information about entities (more so than with just verbose)
noCurves Don't process patches
noModels Not implemented
noClipSides For debugging, don't clip the sides of a brush to other solid parts of the world
noCarve Don't cut up any surfaces (like adding noFragment to every surface)
shadowOpt <n> Set the shadow optimize level:
0 - No optimization
1 - SO_MERGE_SURFACES (default)
noTjunc Don't fix t-juctions. (Triangle optimization won't work without t-junction fixing)
noCM Don't generate .cm (collision) information
noAAS Don't generate .aas (pathfinding) information
editorOutput Pipe status messages to the editor window

Might look into the settings and perform some tests too see if the different ShadowOpt <n> settings and LightCarve actually are worth doing 
i was using your light util today and all of a sudden, it started making my map pseudo fullbright.

what i mean is that it's not a 'real' fullbright like when you compile a map with no lights or do r_fullbright 1 in the console.

not clipping outside the map turns the viewmodel dark like it normally does, and overbright lighting in winquake and fitzquake is visible, but everything lower than 100% light becomes 100% and everything above that (overbright) remains the same.
if i turn on r_fullbright in the console in fq, the overbright lighting goes away.

any ideas? 
yeah, never mind, ignore that post. >_< 
C'mon Necros... 
...we all want to poke fun. What "silly" mistake did you make? 
i set minlight to 260. O_o 
I Set Minlight To 1024 Once And Started My Machine On Fire 
Might look into the settings and perform some tests too see if the different ShadowOpt settings and LightCarve actually are worth doing

Lightcarve is definitely useful - splits brushes along light volume edges, meaning that lights only increase passes on the the surfaces they include and nothing more. Would be even more useful if you could set it on a per-light basis instead of globally (often you'll want big fill lights to split geometry but not little footlamps).

As for the ShadowOpt settings, I have no idea. Nice of them to explain what things like SO_CLIP_OCCLUDERS actually mean. I get the feeling they aren't ranked in order of awesomeness, either - each one probably does some special thing that we can't fathom without more info. 
That using these new compilers, Marcher's #clipnodes dropped from around 32k, to 25k.

I'm tempted to restore all the stuff I had to chop out in the release version o_O

There is no reason why you shouldnt. :) 
anyone knows if you can make doom3 lights affect only specified objects\faces (flags \keys for geo or lights) ? 
Vis Frozen Like An Icicle? O_o 
H:\q1\maps>vis map
---- Vis 2.25 ---- Modified by Bengt Jardrup

File: map.bsp
3654 portalleafs
12249 numportals
Loading state file: map.vis
testlevel = 4

Base:100.00%, Elapsed: 1:23

Full: 30.72%, Elapsed: 52:16

(continuing from a previous vis session)
this has been like this for about 3 1/2 hours... usually isn't there the +---+---+ thing that shows up to let me know that it's just taking a long time to vis one portal or something like that? is it frozen? 
try inserting giant brush in the complex area of the map and let qbsp, cut it off the level and see what happens 
It's Unusual 
that it gets stuck in one portal already at 30%. The portal progress bar can be extremely non-linear, so not showing anything for 3 hours isn't strange (only discouraging ...).

I've seen one portal going for 12h without any feedback and another for 5h with only two updates.

To make sure it's still running, confirm with Task Manager that vis is hogging the CPU. 
it's still using up 90% of the cpu... i did switch it's priority manually via task manager to 'belowaverage' so it wouldn't slow down games and such, but i left the machine alone for those 3 1/2 hours so it should have been able to make full use of the processor.
does switching the priority do anything to it? 
There's Also 
a newer version of vis (2.29) where I've tried to improve on the linearity of the portal progress bar. Expect no miracles though ...

As for priority, there's not much to do if it's already hogging the cpu. Normally, priority is lowered for hogging, lengthy processes (like vis) or raised for non-hogging, brief processes (e.g. copying a file over the network).

Raising priority for a process like vis will only make the whole OS unresponsive or even completely blocked, requiring power cycling to regain control. Changing priority often have unexpected results.

If two or more processes are fighting over a single cpu, the total time will be a lot more than running the processes one by one. 
yeah, i know that. i was asking if lowering the priority has bad effects on vis.

anyway, i'll restart vising with the newer version... maybe it will work a little better... 
Quake With Realtime VIS And Light... 
is my dream. 
does both already :) 
something in there is messing up the vis... it got frozen at the same percentage with the new vis program too:
Full: 30.63%, Elapsed: 51:20, Left: 8h 58m, Total: 9h 50m, 8%
Full: 30.68%, Elapsed: 51:34, Left: 8h 58m, Total: 9h 49m, 8%
Full: 30.72%, Elapsed: 51:56, Left: 8h 57m, Total: 9h 49m, 8%

there is a lot of complex brushwork... would that cause a freeze with no error messages like this?

(also, i'm pretty sure it was frozen before because it was still stuck at 30.72% 4 hours after i posted... O_o) 
any software can theoretically get stuck, I've yet to see vis doing it. If you don't want to wait, I'd suggest doing what Vondur said; put in one or more solid brushes over the most complex areas and see if you can get a change in behaviour.

Lowering priority for vis only tells the OS to prioritize other processes, but since all of them should be blocking (waiting) for most of the time, vis will still hog the cpu. If you start another cpu hogging process (e.g. a game), vis will yield almost completely until the other process finishes. 
Patience In A Virtue... 
wow, it took a long time (4hours) with the new vis.

but now it's going on it's happy way towards completion. i'm just surprised that it did it so early on (barely an hour into vis). usually that kind of stuff is at the end. *shrug* 
WC 1.6a 
Anybody ever see this?

Doesn't work as expected though. I just thought you might want to know :) 
man, no real mappers use arch\shape generators - they create shite

(well, I did. But I cant map.) 
I Can't Map Either, But... 
It's just weird how I got that funny dialog to pop up:

In Worldcraft 1.6a -- with a map open, of course ;) -- I selected the Block Tool and in the New Objects toolbar, in a Category other than Primitives, chose the last Object in the list. I then drew my rectangle and pressed ENTER to create the New Object. Next, I picked the Category Primitives. This time I left Objects blank and drew my rectangle. When I pressed ENTER, Viola, that odd little dialog appeared!

While it doen't seem very useful, it was fun to find at least :) 
Arch Tool 
not that hard to find. As already said though, it produces crappy off-grid rubbish. Just do the right thing and read czg's curve guide. 
vis froze again, this time at a different point.

Full: 50.43%, Elapsed: 27h 49m, Left: 18h 44m, Total: 46h 34m, 59%
Full: 50.45%, Elapsed: 27h 49m, Left: 18h 44m, Total: 46h 34m, 59%
Full: 50.48%, Elapsed: 27h 53m, Left: 18h 43m, Total: 46h 37m, 59%
Full: 50.49%, Elapsed: 27h 54m, Left: 18h 43m, Total: 46h 37m, 59%
Full: 50.55%, Elapsed: 27h 54m, Left: 18h 42m, Total: 46h 36m, 59%
Full: 50.66%, Elapsed: 27h 54m, Left: 18h 39m, Total: 46h 34m, 59%^C (break)
H:\q1\maps>vis -level 4 -savetime 20 map
---- Vis 2.29 ---- Modified by Bengt Jardrup

File: map.bsp
3654 portalleafs
12249 numportals
Loading state file: map.vis
testlevel = 4

Base:100.00%, Elapsed: 1:33

Full: 50.58%, Elapsed: 27h 54m
Full: 50.66%, Elapsed: 27h 54m, Left: 3h 23m, Total: 31h 18m, 89%

i think it's when i play games... i was playing a lot of vtm:b... i hear there some kind of memory leak in that game... maybe that's what's screwing it up? O_o

oh well, restarting again. :\ 
before the ^C break, it had been stuck on that one for 6 hours, then restarted and it was stuck again for about 10 hours.

also, note the wierd jump on that final percent value... O_o ? 
When You 
run another cpu-intensive app like a game in parallel, one might think that vis should get about 50% of the time. But because the game is in the foreground, usually Windows boosts its priority if you haven't explicitly told it not to. Also, there's a potential risk that the game sets its own priority higher than normal.

The jump in estimation is normal when you restart. The estimation is normally sliding to even out sudden jumps, but when you restart, it has to start all over again with fresh values. The estimation will slowly get back on track after a while if you leave it alone.

Btw, you are aware of that interrupting vis inside a slow portal will set you back to the beginning of that portal ...? 
No, I Don't Think You Understand. 
i mean, it just freezes like that.

ie: no updates on the screen at all, even after the game is finished.

those 8 hours, i meant 8 hours not including time in the game.

it's not normal for vis to completly stop updating altogether so early in the process. whenever it would stay stuck at a particular place before, the screen would at least get updated to let me know that something was still happening. also, note that the place at which it froze the first time (30.xx%) didn't happen the second time. either the map is killing it, or running certain programs is breaking it. i've restarted this time and i'll not load up any games until it has paseed the previous point and then we'll see... 
What OS 
are you using? You confirmed before that vis was still using >90% of the cpu, was this true also in the other cases when it seemed stuck?

As I said before, I've had cases when having absolutely no screen updates for up to 12h when it's been processing a slow portal. But of course, vis should behave the same way each time you run it on the same bsp+prt.

If you wish, you could send me the zipped map+wad and I'll see what happens. 
I wonder why I am mapping and after a while my
map goes down by a bug.
I use Texqbsp and Quark63. For some rooms it goes well, but then it strucks down for some
idiot reason. merged textures,holes that don't excist...

But then, when I use Tyrqbsp, I get some warnings but the map compiles fine.

Can't get it, what's the difference between the compilers. Or am I such a fool I just map the wrong things? 
First, switch to last QuArK release (6.4), or just change of editor (while QuArK works fine for me... there are no reasons to change... even if QuArK sucks regarding some other guy's opinion...)
Second, use aguirRe's tools... that's the better way to map "correctly"..
Third, what options are you using with your compile tools ?? I think each tools have their own options, which are not obviously compatible between each other... so just check it.. and choose the right ones ;) 
I just wondered why Texqbsp compiles without giving me a *.prt file.(bad mapping?)
Then the same file compiles right with tyrqbsp!(good compiler?)

Doesn't make it easier to understand the problem. 
It is a very difficult problem to understand, so don't worry.

I spent a long time trying to improve qbsp due to problems I was having with my own maps. You probably do want to use aguirRe's tools - his are a little better tested than mine, and he does tend to include any improvements that I make into his tools also.

Try some different tools and just use whatever works best for you. If that happens to be tyrqbsp, then that's fine. 
Thanks, compile & compute aren't the same. 
It Is Possible 
to create first rate work with Quark as Mark Shan showed with Project Genoma for Quake 2, and it was the first editor that I tried, but for me, Radiant and BSP are both more to my liking.

I guess the biggest advantage to using Quark is that the team (or is just Armin?) are showing no signs of giving up on improving the editor. 
I Think Armin Gave Up Years Ago 
but I could be wrong (I know him via a completely different connection -- small world). 
Mark Shan was using the DeathMatch Maker (DMM) editor, not QuArK. 
one couldnt make anything remotley nice in it 
You'd get better results with Notepad. 
Doom3 Lighting 
ugh... this is driving me nuts. :P

afaik, you can't bake on lightmaps like you can with other games like Painkiller, or even q1, everything must be lit realtime in the engine.

ok, that's cool, but holy shit: how do you get the map to not have more than 2 lights on a surface without it looking pitch black?
(my first test area had only like 8 lights in there, and it ran like total shit) and all the walls were pink/white indicated 4+ lights on the surfaces. :P

are there any good tutorials that show lighting techniques that can give me double digit fps and not look fulldark?

also, is there any equivalent of the _sunlight like in q1 compilers to get sky brushes to emit light without any (or much) performance hit...
i mean, i have gotten the effect by placing a really bright light ouside the map... but is there a better way?

also, when you are counting the number of lights on a surface, do you count faces that don't get shined on (ie: they are blocked by another face)

and how do you get it to split faces so that each face is split where the light hits?

also, what would run slower: a large room, say 768x768x256 with each face with max 2 lights on each face, or a small room, say 512x512x128 with 3 and maybe some places with 4 lights per face?

/me is a total n00b at d3. O_o o_O 
More On D3 
i have a strange problem... in my map, you start in a room facing a door, and behind the door a monster is placed there, facing you. but it can't see you through the door, but regardless it awakens, walks through the door itself and starts attacking.

the strange thing is, when i turn on notarget, go into the other room, spawn a monster in manually, go back into the first room and turn notarget back off, the monster won't awaken until i open the door (which is what it should do)
so my question is, why does the monster awaken on map start like that? is there some kind of hidden value i need to put in? 
As far as monsters are concerned, there is no sound attenuation. So, when you make a noise, all monsters, regardless of where they are in the map, will awaken and come running to take your soul unless you set them to ambush, or set them to be spawned on trigger.

There was a good tutorial on monsters on doom3world, but I'm fucked if I know where that's gone :/ 
unclicking 'cast shadows', and using ambient type lights can help you a ton. But that's all I know cuz I've only messed with d3 engine a small bit :D 
Ambient Type Lights? 
so, then these would just be normal lights except they don't cast shadows, but still affect spec and diffuse, right?
or is it a different entity? (i haven't seen on like that)

but it tried making some lights not cast shadows, and they still did on the world, and i didn't see much speed increase... did i do something wrong? 
I'm Likely Making Shit Up 
but the way it seems lighting should work is that each area uses 1 'major' light, and it casts shadows. The rest should be detail lights that do not touch each other, and do not cast shadows. Depending on their use, specularity and diffuse is up to you. For an ambient, you just make a light, texture it with one of the no falloff or ambient or whatever they're called textures, and give it a dark color. 
Dang, You're Right, AquiRe. 
I confused Shan's work with Milhous who did use Quark for his XXX. 
there is ambient light shader (same place you set cubemaps for a light) - no shadows, no spec, lights backfaces - every poly that gets into the volume. Use with care (dark color) or it looks shite

some crap about lightmaps ( I didnt try) 
Stay clear of ambient lights, they wash out stuff too much. Instead place the lights so in the editor, that each face has only two overlapping lights touching. This might not be always entirely possible, but keep trying. And darkness is a tool just as lights. Areas with a lot of contrast can look very good. 
i'll give all these suggestions a try then.
i guess a lot of the problem is that i'm not used to having everything so dark like this...

i miss my q1 softshadows too. :P 
Ambient Can Work, IMO. 
You just need to be careful to leave it pretty dark--if you brighten it up much at all things do indeed look like ass. 
^That's Coming From A Q4 Mapper. 
And don't think of ambient as a full map thing, this is small, controlled ambient we're talking about in areas that would logically have a dim light all over. And to avoid some of the wash out, you just have your normal lights be whiter than others in darker areas (leaving lights full-on white for general use generally looks a bit too bright in contrast to the dark) 
Ambient Light 
The problem with ambient light in Doom3 is that it doesn't pay attention to normal maps (to my knowledge). All contours of the surface are shaded equally, which makes ambient lighting even more flat and ass-like than in in the Q engines. Even ambient light has bias towards a particular direction or range of directions - it's bouncing off of walls and crates and things.

I think a good go-between, if anybody who writes this crazy ass shader things is reading, would be to shade with the blue channel of the normal map as an intensity map. It'll show the contour of the surface still, looking as if the light were coming at the surface from directly in front of it, but still shade the surface pretty uniformly.

Not enough hours in the day, man. 
There's Also One Side Effect When Using Ambients 
You end up adding lightcounts by 1 on every surface at the area you are using the ambient light at. You have to be really careful about adding further lights after that. Same goes for fog since it's a light too. In my experience fogged areas tend to have lightcounts predominantly in green-blue, and i'd bet it's the same with ambients.

I don't think D3 mappers in general should worry about map having pillars, corners and stuff with 0 lights on one side or something. Place some materials with fullbright elements there for example. Looks kickass.

Also try using lights that go over the 1 1 1 RGB value scale. Some odd effects there. The doublebright cubemap materials for lights are quite nifty too. And remember to split brushes at light area boundaries when necessary (X or Y flip the texture so the bsp won't re-merge the brushes). Brush your teeth every morning and respect your elders. 
Isnt there a switch to make 'compiler' split according to light volumes?

btw there is interesting solution in the above d3w link (page 1) - shaders that add-blend the colormap
cheap (as in looks but in performance too) 
Yes, Lightcarve 
But you don't want to turn that on. You'll just end up with billion split polys. You get better results by splitting the most offending brushes (80% of time the floor) by hand. Gods... 
man, first i needed to align my brushes on the grid, now i need to align my lighting? O_o

hehehe, lol, so manual brush splitting it is then.

in general, how much of a gain is there on this? ie: is it really worth doing or just if you want to try to get an extra 1 or 2 fps here and there? 
More On Lighting... 
what about lights on models?

say i modelled a large structure or something like that and there were no brushes used at all (well, except the caulked ones behind to seal the map) does it matter how many lights hit a model?
and does the size of a model matter as well?

what about large swathes of terrain? 
Quake Textures 
Forgive my stupid question but are all the custom textures I have used for my Quake level (made in WC) within the bsp so that I could just throw away all the texture wads I have used and they'd still remain in the level?

It's just that this is all new to me - because I remember that when I made a map for Q3A you had to store the JPGs/TGAs with the pk file along with the actual level. The same with Duke3D for which I have been mapping lately (since -97) - you always had to include Tiles***.art file with the level or the textures vanished. 
Yes, you're correct. In Q1, when you make a map, all the textures are included in the .bsp so you don't need to include the .wad. 
Unreal Rock 
Great to hear - thanks.

Anyways - where to get that Unreal rock texture which has been used in Quake levels lately? 
from the bsp of that map perhaps?!!! :D

Grab a copy of texmex (google is your friend) as that proggy can open q1 bsps and save the textures to .wad 
boy, did this freak me out when i first saw it:
Full: 50.71%, Elapsed: 69h 10m, Left:13770h 29m, Total:13839h 39m, 0%

luckily, it eventually smoothed out to about 5 more hours. hehe 
Benefits Of Light Optimization 
n general, how much of a gain is there on this? ie: is it really worth doing or just if you want to try to get an extra 1 or 2 fps here and there?

It is worth it. The area pictured here went from 25fps to 40fps after aligning lights to minimize overlaps and splitting brushes at light edges.

And yes, keep the light on grid. It makes life much easier when you lights are on atleast 8 unit grid. If you are going to hit one brush with two lights, it doesn't matter if the overlap is 64 or just 1 unit. Result is the same, so keep the grid coarse.

Models behave just like any brush geometry when it comes to lightcount. If one side of the model is lighted and another isn't, the other side shows as red (1) and tris in darkness as black (0). Exactly the same if it was built from brushes. Doom3 doesn't care to what entity the tris belong to, they all behave the same when it comes to lighting. Terrain in Doom3 is made from models also (huge models), so it isn't a special case. Size is irrelevant.

Speaking of size.. Not many know this, but Doom3 models can be resized in the editor. The rotation of objects is defined via transformation matrix, which also contains the multiplication factor for size. See the rotation key/value pair. For unrotated model it is something like "1 0 0 0 1 0 0 0 1". Change it to "2 0 0 0 2 0 0 0 2", and see the model size double. D3Editor will reset these values if you rotate the model again, but you can re-type them should you need to. 
thanks for all the info! :)

looks like i've got my work cut out for me... this looks like it will take about 10x as long as a normal q1sp. O_o 
Prefab Textures 
I found some prefabs (for military stuff) on the web, but many of them don't have the related textures.
I tried to "self-create" the textures, but it was fully unsuccessfull, due to my lack of kowledge in this domain.. So where can I find full (.map + .wad) prefab ?? Or at least some cool textures of Jeep, Tanks, Missile, etc.. etc.. 
Hehe, five digit hours, that's 577 days ... 
I was just trying to experiment with different skies but I can only see one - the one I used first. Should every sky texture be the same? (WorldCraft) 
For Q1 
Yes, only the first sky texture loaded will be displayed on every skyface in the map, afaik. 
But I can still change the sky for the level if I replace every skyface with the new one? 
Yes, that is correct. 
Door Problem 
I would like to manage a door like this:

1/ First open the door with a button, and let it open
2/ After crossing the treshold of this door, close it definitevely behind the player..

I made many tried with "wait -1" field and "trigger_once" function, but I was unable to reach my expectations... Is there something I missed ? Can somebody give some good advices to achieve it please ?? 
add spawnflag 'toggle'
and trigger it with a trigger as soon as u enter the room, it'll close instantly 
and toggle is
spawnflags 32 
OK, I understand now why it was not working, thank you very much :) 
ClipNodes Producing Leaks 
I had yesterday night a ClipNodes problem i.e ClipNode Number (33015) exceded engine limit (32767)... and I found many informations about this kind of problem in the amount of previous post ;) For eaxample how to reduce significantly ClipNodes number...

Nevertheless, I have a question: Does ClipNodes number can produce a map leak ? Or is there something else I missed ? 
Not As Far 
as I know, but leaks in hulls 1/2 will increase clipnodes significantly due to no filling of outside in those hulls. So excessive clipnodes indicates that you might have a leak, but is not the cause. 
to make sure u have no leak but clinodes excess, clip some recesses/alcoves in your map, i.e. make less clipnodes (lower the amount which is supported by qbsp), if the number of clipnodes will be lower than critical and you'll still have a leak error, then you got the leak, go seal it. 
So there is something mysterious here: I only added some walls, and in order to test texture alignements, and how it looks with shadows, etc.. I tried to compile the map, and sunddenly, the map leaks, while it didn't before the modifications (and these modifications were not impacting the map sealing...)

Anyway, I will try to add clip brushes in order to reduce ClipNodes (particularly on terrain part), and I'll try to recompile and see what will happen... using your tools tips ;)...
BTW, when loading the prt file in the map, I can see the "point" going throught the middle of a wall... It's something weird because there is no "hole" in the map ! o_O 
Thank you, that's exactly what I'm going to do (see my previous post)... They crossed each other ;) 
like a leak in hulls 1/2. Check the brush and its neighbours and make sure they're aligned. If the leak is in hull 1, you can often verify the leak by walking/falling through the brush.

Btw, it's the pts (point) file you load into the game, the prt (portal) file is used by vis when the map is sealed. 
I didn't be able to walk/fall through the brush... I will check the map this evening (with your "magic" -hull <1/2> option)... Thank for your advices ;) 
Ooops I forgot to mentionned that, If I remember well, leak occured in Hull 2 (reached occupant etc.. after Hull 2 start in TxQBSP...), so what am I suppose to look for now ?? 
Leaks In Clipping Hulls 
can be tricky to find and fix. The first thing I'd do is to inspect the brush and its neighbours where the pointfile goes through the hull. Look for tiny misalignments (zoom in real close), especially in non-axial junctions.

Try expanding or otherwise change one or more of the brushes in all directions to find the culprit. Building with the -hull 2 option may help if there are HOMs in that area but it's mostly useful for finding clipping errors fully inside the map (which don't cause leaks), see also ToolTips. Use the -starthull 2 option to speed up the turnaround time (to quickly see if the leak is fixed; abort if not).

If you can't sort it out, send me the zipped map (no wad yet) and I'll see what I can do. Please also include what compiler options you're using. 
Missing Brushes 
Im having trouble with brushes dissapearing during compilation. they are in the editior (Gtk 1.4) but when i run BSP (treeQBSP v2.00 -- Modified by Bengt Jardrup) i spring a leak! i run BSP after mapconv. perhaps mapconv is screwing up? i donno. 
updating to 2.01 and adding option -q2map, this will eliminate the need of a conversion tool. I doubt that the conversion is at fault though.

From the compiler log, in what hull is the leak? 
i have the opposite problem. brushes that don't appear in the editor appear in the map!
Silly Necros 
Turn off editor hiding of func_wall brushes! 
they're normal brushes. :P 
it's some kind of bug in gtkr that makes the editor not load up a brush if it's 'broke' but the bsp compiler must fix the broken brush as it compiles the map. 
You've probably tried all sorts of things to fix it, so pardon me if this is redundant, but have you tried checking it with MapSpy? It's a really great tool that's useful in tracking down bad brushes in any Q-engine based game. 
Actually I Haven't. 
the problem isn't a large one and only shows up once in a long while, but the next time it does, i'll try it out. it's certainly more efficient than going through the .map file and removing the offending brush. 
if radiant doesn't load it, why don't you copy and paste all your brushes into a fresh .map? 
The leak occurs in hull 0 (i think) That is to say "processing hull 1" comes after the leak warning.

Ill try 2.01. 
Hey It Worked! 
guess it was the conversions fault. 
how would that fix anything at all? O_o 
The latest compiler versions have the new Tyrann logic that probably is the main reason for the better result, good to hear it worked for you. 
I think he meant copying and pasting the brushes inside Radiant, and not a text editor. If you can't load/select the brush in Radiant using typical means (i.e. making a huge brush and using Select Partial Tall), then you probably won't be copying it over into a new map and the problem would be solved. However, this would royally mess up all of the trigger/target combos since Radiant likes to rename those when you copy/paste them.

Going back to MapSpy: the way I get rid of offending brushes is to run the map in MapSpy, get the brush/ent number, and then use the Find Brush feature in Radiant to select the brush. Frequently you can't actually see the brush, but it's selected, so all you have to do is hit Backspace and it's gone. 
this would royally mess up all of the trigger/target combos which is why i don't do it. :) i takes ages to fix all of those again, and even after you'll find you missed something.

also, even if gtkr couldn't select the brush for deletion, once i know the brush number, it is simply matter to load the .map file in a text editor, search for that number, and delete it manually. gtkr seems to rebuild brush numbers once it loads or saves the map again. 
knowing how large your maps can get perhaps you have reached a limitation in the format structure of the file as it is read by the editor so it is doing weird things to your map.

Maybe it would be worthwhile to send the map as part of a bug report to the GTKRad team.

If this happens to be the case and GTKR reads Q1 and Q3 map files at different file struct sizes (like Dark Places recognizes no size limits on Q3 .bsp's but there is an absolute 32K one on Q1 .bsp's) then something as simple as converting from Q1 to Q3 .map and reading it into GTKR in that format may help. 
no, it has to do with when you vertex edit brushes.

sometimes, if you create a broken brush by vertex manip, gtkr doesn't seem to 'notice' until you move the brush around. under some circumstances (which i haven't been able to figure out yet) the brush goes from broken but not noticed to full on broken, maybe if you save and then reload the map before getting rid of the unnoticed but broken brush.

anyway, i don't really bother submitting bug reports or anything. nothing seems to come of it anyway. 
I submitted a few bug reports on Bugzilla, and nine months later I got a few notices via e-mail saying the bugs had been fixed. 
StarBreeze's Ogier 
has excellent brush vertex manipulation abilities. It isn't difficult to get a feel of its interface either. Perhaps loading the map in Ogier and correcting or even fininshing up the editing with it could solve the problem. Wrath is right about it though, it is about as good as a brush based editor gets. 
Any chance of you adding a -noambientsky switch to VIS that stops the level from playing the ambient sky sound? 
...RPG makes a fine request. Sky_void shouldn't necessarily make a noise.

In space, no one can hear you fart. 
I'll look into it, it doesn't sound so difficult. There are also several other variants (no ambients, no water/slime/lava), are they interesting as well? 
Yes, AguirRe 
Although I have no immediate use for them, they might be handy in future maps; particularly -noambientslime. So if you're willing to add them, that would be cool. 
OK, I Think 
I've fixed all variants now, along with hopefully better handling of the actual sound distribution. Before, you could hear some sounds almost everywhere in a level even if the source was pretty far off. Old style is still available if desired.

Also, the state file (.vis) will still be used to full extent, i.e. you can experiment with the sounds without making a new slow run as long as the state file exists. 
I need help figuring out how fast this level can be completed at 100%. @ <- CAN YOU BEAT THE TIME?

If you beat my time you get a kiss, no cheats allowed, I'm trusting you here. (Btw, no demos, too easy if everyone can see the 'super hard to find' secrets) 
How Is This Mapping Help? 
I managed ten. There's no way you can do it in less than nine without noclipping. 
I have a .qc file called ogre.qc where he fires only grenades. I have another one called ogre.qc where he fires only nails. (Where I use a single gender term, I of course relate to both genders.)

If I rename one ogre1.qc and compile them both into progs.dat, is that enough to identify and use two different ogres in the game without changing anything else in the .qc file. I do not want them to have different skins - I want the player to see two ogres one of whom fires nails and the other grenades. I do not want the player to see this until it happens. I assume I will need to name them monster_ogre and monster_ogre1 in the map file.

I do not know anything about QuakeC except how to decompile and complile.

Your assistance will be appreciated muchly. 
Also, can someone explain in easy to understand bullet points, what the pros and cons are for using models instead of brushwork.

I have a statue of Anubis made up of 450 brushes. If this was a model instead of brushwork, how would playability be affected.

My start point for this question is the tree in Marcher Fortress: why a model, why not brushwork?

Don't forget now, not too technical: play with me here, not against me:-) 
I'll start with your second question first...

In Quake, complex brushwork is very expensive in compiling terms, for various reasons. Quake has no support for detail brushes, so every bit of world geometry is is chopped up and merged with the rest of the world, and put through the same vis calculations (which can grow exponentially when you have lots of fine detail in large outdoor-type areas).

There are situations where turning brushwork into a func_wall can be useful. Basically, because the brushmodel is now an entity, it will not split up adjoining world geometry, nor will it affect vis. However, if a brushmodel gets too large, it can become a problem, especially if it straddles visportals. Also, brushmodels are rendered less efficiently than world geometry, so you will see an increase in polycount. I generally steer clear of this method, although I use it in a few instance in Marcher, such as for the torches in the upper cavern, where they butt straight into the terrain brushes.

.mdl models, like my tree in Marcher are most definately your best bet when it comes to those kinds of mapmodels - mainly for the fact that it would be very difficult to create that structure using brushwork, compared to how relatively easy it is to model it in a 3d app. 
Blagger - Part 2 
Regarding your QC question:

Well, if that really is the only distinction between the two ogre qc files, then the compiler will abort if it finds any redefinition of the same function (i.e. two functions sharing the same name). If you want a quick and dirty method to rectify this, just change all the function names in your second ogre qc file so that they are unique.

A better solution would be to let your second ogre call most of the same functions as the original ogre, but with a few changes to implement the nail-firing attack, although you may find this tricky if you're completely new to QC.

Note that the entity classname you place in the editor is the name of the function called in the QC that spawns the monster into the level. Scroll down to where it says: void() monster_ogre = to get a feel for this. 
QC Ogres 
Your method won't quite work, if you attempt it, you'll get lots of errors about functions being redeclared. This is because although the functions are in different files, they will still have the same names, and this is a problem.

The solution is to rename all the functions in one of the files, replacings ogre by ogre1(if that's the naming convention you want). Probably the best bet is to just do a find and replace on the string, and then just correct a few things like the setmodel command - as I expect you want the two ogres to both use ogre.mdl. No doubt somebody will point out the gameplay problem with that in due course...

Then compile and with luck yo should be fine. One thing to note is that the name of the QC file doesn't determine what entity name you need to put in your map. You could call the second file banana.QC if you liked. The thing that determines the name of what you add to the map is the name of the function right at the very bottom of the file. If you've done all the renaming I told you, this will now be called void() monster_ogre1
This is the spawn function. Whenever quake loads an entity in a map, it looks for a function with the corresponding name in the QC. This function sets up the entity, gives it the correct model and behavior.
If you renamed this function to monster_ogre_nail, you'd have to add a monster_ogre_nail to your map.

(A kinda unnecessary aside here, read only if you're quite confident with QC and understood all the ideas above. Creating all these new ogre1 functions is actually quite inefficient! Most of the time, for walking and pain and so on, both ogres will use exactly the same code, just renamed. If you were careful, you could make it so that for all the functions which they do the same, like walking, pain, death, they in fact called the same function(ogre_pain for example), and only had different sets of functions for the firing sequences. You'd then just make two copies of the monster_ogre function, rename one to monster_ogre1, and set the appropriate line:
(for example)

self.th_missile = ogre1_nail1;

You could, of course, go in totally the opposite direction and decide that, given all these extra functions, you'll make use of them and completely rewrite the AI for the nail ogre, make it more agressive or something. But it's probably not worth it unless the nail attack lends itself to it rather well.

If none of that made sense or sounds rather daunting, then just rename the functions like I said and all is good)

Well, the aside is longer than the real post, but the idea of making lots of types of monsters simply by changing a few functions in the spawn function has grown on me while I wrote it. For example, to make a beserker monster variant that never goes into pain, simply set

self.th_pain = SUB_Null;

The mind boggles(or shrinks in horror!) 
And Look At That.... 
Beaten, but I typed more! 
In addition to Kinn's comments, there are some other differences between polymodel and brushmodel.

The most obvious one is the 2D image applied across the surface. For brushes, that would be a map's ordinary textures, which are projected along the major grid axes. For polys, it would be a skin, projected front and back onto the model when you sculpt and arrange it in the editor ( qME ). You can specify almost any size for a .mdl's skin and have more control over what's shown ( detail, form etc. ). However, the skin has to be loaded along with the rest of a map's assets and all of it will be rendered whenever the model is in view. It's unlikely you'll have any problem with the size though - it's actually making the skin that will take a bit of effort.

The other obvious thing will be lighting: apart from DarkPlaces, Quake engines light models more simply than world architecture. A value of lightness is read from the point on the first surface directly below the model's origin ( i.e. the floor ) which is then applied across all its polys. A rudimentary shading effect is achieved by making one half of the model brighter than the other, but this is done without regard to the direction of any incoming map lights and is applied regardless of the direction the model is facing.
This means that a pmodel will always stand out as different from its surrounding architecture and is why mapobjects, such as trees and statues, are uncommon in Quake.

To address the question of framerate: unless you make Anubis high polycount ( over 600 say ) and/or you intend to place many statues in a wide open area, it will be far simpler.
For a comparison, Chthon is 555 polys, the highest polycount of the original id monsters. Even for Quake's original specs, id had no worries placing him in a combat area with, to be frank, no visblocking whatsoever. These days, I'm sure you could place a half-dozen Chthons in a giant boxmap and FitzQuake wouldn't even blink.

As long as you're up to the craftsmanship, a .mdl is definately your best bet. 
hi, has anyone got the dulight (q1rad & tyrlight) mentioned in this thread? Ive been looking for it for ages with no success :( 
would you like ? 
And Blagger, 
to add a fraction to the wisdom above, and so you don't learn the hard way like I did, mesh models are rendered with a bounding box; instead of the collision being detected per poly surface as the case is (ideally) with brushes.

You probably already know this but if you are as stuborn as I am about these things, you will be tempted to create something like an arched door way as a mesh model and place it up against a rectangular portal. If the mesh model is purely decorative and the player can't touch it, fine, but anything involving collision will look weird, though .mdl floors make for interesting skating rings. 
Yes, email to please!

Thank u very much! I wuv you! 
OK, Thanks For Your Comments 
That all sounds attainable even for a novice like me. If time is on my side, I'll be back with more questions later.

I'll work on the monster thing first, models second. The Anubis model is for a Karnak-like area so there will be several statues, in bright sunlight and they will be against walls, not in the open.

How would you, as players and not mappers, react to not knowing what a common monster (say, the ogre) was going to throw at you until he started doing it.

Also, that one ogre would take more damage than another, or that one would be more evasive than another?

I suppose I am asking should all 'different' monsters be skinned differently. I think not knowing until you are fighting them could add a more interesting aspect to the map (given that the map itself and other gameplay is of acceptable standard) 
I suppose I am asking should all 'different' monsters be skinned differently

I would say most certainly yes. I would imagine it quite frustrating having to wait for the monster to attack first before it can be identified. Knowing in advance what you're up against is cool because it gives you that vital split second to plan your combat strategy before the monster starts attacking - I think that's an important part of Quake (and shooters in general) and it would be unwise to change that. 
Not that I am disagreeing with you, but I do find that when I play a map these days I know that the ogre is going to fire grenades at me and that I can jump over them or side-step them, and I need nine shots with the single barrel shotgun. So there is no challenge.

But what do I do if when I side-step, he does the same? And what do I do if after nine shots he doesn't die? Now I have to think a bit and take stock and learn again.

If they have different skins then I have advance warning that something is different. Just a thought. 
trust me. don't do that. if you have new monsters, give them new skins.

it's not relearning, it's just annoying since you have no way of knowing what kind of monster you're going to fight. imagine playing quake again, with every monster looking like an ogre. it's an extreme case, but it helps to get the idea.

if you were to change the ogre itself, ie: make it shoot both grenades and nails, that's different. players will learn that they can expect different behaviour from ogres at the start, but doesn't attempt to 'hide' when those differences are going to surface.

also, sidestepping monsters that don't fly or swim look stupid, unless you were to animate some new frames for them. 
OK, I Get The Point 
I thought that some ogres firing nails and some chucking grenades would make a change.

I haven't seen the effect of monsters taking more evasive action but I read that it could be done. Also that you can make them run away when they got low on health, which would mean you had to chase them to finish them off if you wanted 100%.

I wasn't thinking of a new game, just some 'changes' to the existing format. I actually do not want totally new monsters as it would not be the same game anymore.

Just thinking out loud. 
Outdoor / Indoor (Tastes Good / More Filling) 
I'm working on an inside/outside transition area
in a Q1sp and I was wondering if anyone knows
of a tutorial that adresses Facades and/or
outdoor areas.

Suggestions of maps to look at as examples
would be a help as well.

(wow we have a preview button :) 
QuakeC Help 
I need some help again, please.

I am still playing with the code stuff and have been trying out some monster amendments. I am trying to get my monsters to duck when being fired on and have found a tutorial at AI Cafe. But when I try adding the code to the .qc files, compile fails. I can comment out various lines so can see which 'seem' to be causing the problem.

Can one of you coding gurus spot a problem here:

void() enf_duck1 =[ $paind4, enf_duck2 ] { ai_face(); self.solid = SOLID_NOT; };
void() enf_duck2 =[ $paind5, enf_duck3 ] {};
void() enf_duck3 =[ $paind6, enf_duck4 ] {};
void() enf_duck4 =[ $paind7, enf_duck5 ] {};
void() enf_duck5 =[ $paind7, enf_duck6 ] {};
void() enf_duck6 =[ $paind7, enf_duck7 ] {};
void() enf_duck7 =[ $paind7, enf_duck8 ] {};
void() enf_duck8 =[ $paind7, enf_duck9 ] {};
void() enf_duck9 =[ $paind7, enf_duck10 ] {};
void() enf_duck10 =[ $paind7, enf_run1 ] { self.solid = SOLID_SLIDEBOX; };

The above is in the enforcer.qc and then below goes in the ai.qc

if (self.classname == "monster_enforcer" && time < self.enemy.attack_finished && random() < 0.25)

and the above goes immeditely after the line:

enemy_yaw = vectoyaw(self.enemy.origin - self.origin);

Unfortunately the formatting is not quite right here but is OK in the .qc files.

Oh, I have written to the code's author but not had a reply so far. I have used other code sections from this site and everything else worked OK.

Any help you can give will be appreciated. 
i'd stay away from ducking...
in order for it to work, you'll need to change the bbox size during gameplay. i've noticed some very wierd and annoying things happen when doing this, most specifically, monsters become able to walk through walls.

also, don't forget, you'll need to actually animate some frames for the model to duck.

and you'll probably get a lot more help concerning qc things on the inside3d forums:
most of the dudes here are mappers. :) 
Late Appending: 
just read the code over again for the enforcer ducking frames,
you actually set the monster to nonsolid there, which, in terms of not fuxoring the bbox is good since you don't change the size, but you do realise this will cause the monster to become unshootable for what looks to be about 1 second...
if you do decide to go with the bbox idea, and not the nonsolid one (which imo is kind of lame) don't forget to reset the bbox size in the pain frame.

the bbox size setting is : setsize (e, mins maxs)
e is the entity to modify and mins and maxs are vectors coming from the origin of the entity.

finally, if you don't go with the bbox idea and stay with switching the self.solid states, don't forget to test to see if the monster is in something else before becoming solid again.

with the way it is, if the monster ducks, and you walk into it, it will become solid while you are standing inside it, and you'll get stuck until you kill the monster.
check out the zombie.qc for code on how to check if it's ok to get solid again (it has to do with when they fall. every 3 seconds, they check to see if they can become solid, and if so, stand up) 
Thanks, but I need to explain that the code is not mine so if there is anything good in there, I had nothing to do with it.

The monster has to unshootable 'cause when he ducks, you missed him :-)

I now know that the line -


is causing the problem as it gives an error in Frikqcc : Unknown value "enf_duck1"

ai.qc goes before enforcer.qc in the progs.src file.
The compiler will look for the void enf_duck1() function when it gets to ai.qc but it's not defined before it gets to enforcer.qc.

Therefore you need to define a void enf_duck1(){...} function prototype (I'm not sure it that's the correct name for it in qc) somewhere before the reference to it in ai.qc. I'm not exactly sure where it would be the proper place to put it, but if you put the text void enf_duck1(); just before the function in ai.qc that calls enf_duck1() function, you should be fine.

Hope this helps!
-love czg 
Thanks. I'll try that.

So, do you think that it would be a good idea to have a dummy .qc file that is made up of all the new functions one is adding to the various other files, and that the dummy file (only a dummy because it has no purpose other than to declare the function names that will be found later) is placed higher up the compile ladder? Or perhaps just list them all automatically at the top of ai.qc.

(I don't really know what I'm talking about here, I am just trying to follow the logic) 
to have a dummy .qc file that is made up of all the new functions one is adding to the various other files...

Or perhaps just list them all automatically at the top of ai.qc.

Both should work just as fine, but the question is which one is the neatest, tidiest and most correct. If that doesn't matter to you though, just pick one at random... 
OK, Thanks Again 
eenie, meenie, minie, mo... 
Clear Down 
Placed the function declaration at the top of ai.qc as I saw there were some there already.

Compiles fine now. Thanks czg.

The function works in-game but because it relies on you shooting the enforcer, when he ducks it looks just like he's been hit, and not that he's ducked your shot. Therefore, it works, but I won't be using it.

But a nice introduction into coding nonetheless and I am now looking for some more things to try. 
BlaGGer - Try This 
Is it possible to change the speed and color of laser projectiles shot by trap_shooter? 
Speed is altered by use of the 'wait' key from within the map editor: 1.0 is the default.

The colour of the laser projectile can by changed by using a program such as qME and painting the laser.mdl, which is found in PAK1.PAK. You can use a program like PakExplorer to unpak the file.

Hope this helps. 
The laser.mdl is in the 'progs' folder in PAK1.PAK. 
The laser.mdl is in the 'progs' folder in PAK1.PAK. 
I'm in a cave as I speak :-) 
Fantasy Quake 
Does anyone have the source code to fantasy quake, or the mail address of the authors:
fireball invictus shaper,

I'm interested in tidying up this cool mod.No releases made without permission.

stevenaaus - at - 
we'll rip monsters, textures and code from the Hexen series, Quake 2, Daikatana, basically any commercial ap we can get our hands on, but when it comes to other modder's expressed wishes, we tend to be more hesitant. I'm speaking generally, of course.

btw, excellent idea, steven_a. Good luck with that. 
we'll rip monsters, textures and code from the Hexen series, Quake 2, Daikatana, basically any commercial ap we can get our hands on, but when it comes to other modder's expressed wishes, we tend to be more hesitant. I'm speaking generally, of course.

That's because most companies will never see your work using their stuff, but a fellow community member might and get bitchy with you. It's the whole 'legal unless you get caught' type thing. 
that makes sense. From the Fantasy Quake readme, they really don't want their product tampered with.
I would suggest looking up Ultimate Quake
Looking over the .doc file, it appears it has the
most of the same features, spells, mideivel weapons and the like. 
Rotating Entities In Quake 1SP 
I have seen rotating doors in Quake 1SP. I have tried Google but keep getting redirected to non-English sites(?) so can anyone point me to a site that can supply whatever I need to incorporate into my map?

Worldcraft Prefab Crash 
I've never been able to create the Prefabs in Worldcraft since wc shuts down when I try. Can anyone offer a clue or convenient workaround?

I'll provide more details if you need but right now, I'd rather continue with my map then figure out what's wrong. 
Q1 Info 
Check out czg's tutorial on rotating ents here:

More general Q1 ent & prefab info here: 
you can't do it without a quakec mod -- try "custents" or the hipnotic mission pack for a progs.dat that supports them.

Also, i believe you need a qbsp that supports them, too. Modern treeqbsp and tyrqbsp variants should be fine. Original qbsp will not work. 
WC Prefab Problem Solved 
I should have done my homework. The Forge showed how to create Prefab libraries. If you don't have a library - which is just a folder in Windows, WC says bye-bye when you try to write out your prefab. I made my Library and all works fine writing and reading. Thanks for the pointer, aguiRe. 
Gibbed Teleport... 
... I'm trying to finish up a Coagula style level and want to use the sort of falling into void gibbing experience I received from ELEK in Coagula1. The experience involves being gibbed AND teleported high into the level. I've tried with various combinations of trigger_hurts and trigger_teleports but can't get the effect right. Anyone help? 
I believe all that's needed is to teleport two monsters to the same place at once. Telefragged goodness! 
... but I thought the player had priority in a telefrag fest i.e. that if the player and any number of monsters teleported to the same destination at the same time then the player survived but nothing else did.

I remember perceiving the series of events when I fell from structure in C1 as:
1. I'm gibbed
2. and almost immediately teleported high into the level

Not the other way round. 
Entity Number Vs Edict Counts 
I've seen that VIS reports entity number at the end of its log file. I had edict count problem in CMC map, so I just would like to know if there's any "direct" relation between entity number and edict counts ingame ?
In that case, what is this relation ? And so, can the VIS entity number report be helpfull in order not to exceed edict counts ingame ? 
You Probably 
mean the printout at the end of the Light log. AFAIK that figure is only an indication of how many edicts there are. Many edicts are created at startup and during gameplay and these are not included in that figure.

Example of temporary edicts are missiles from scrags or deathknights. You'll have to use the edictcount command or the new edict screen display of my upcoming engines.

The best way I know to provoke as many edicts as possible is to play on Nightmare, use god mode and play through the map without killing anything. Then the edicts will really pile up and then find a place where there are many scrags or deathknights and circle above them to provoke their missile attacks.

If you don't exceed 600 then, most likely your map is safe. 
My mistake! I thought you were just asking about making it rain gibs, not what you were asking about which I have no clue how it works :) 
Also, static lights do not count as edicts, so the entity count usually doesn't have much in common with the in-game edict count. 
Edict Count.. 
So, how is it possible to determine "approximatively" edicts count, in order to anticipate and avoid crash ingame??
When I see Kinn latest release with an incredible amount of monsters (final battle for example), I'm guessing there for sure a method to determine edicts count. I tested Kinn's "Bastion of The UnderWorld" and "Marcher Fortress" with FitzQuake, and I had no problem, while in the same time I had the problem with my CMC map...(I reach the limit in hard skill..), but I don't find a good method to determine edicts count max value...
I know Kinn is talented (much much more than me...), but even if there are some "tips" in his 2 maps (due to QC I suppose), for common mortal I am, there is certainly a good method to evaluate edicts count in map.. Any idea ?? 
You can see how many edicts are being used in game by bringing down the console and typing 'edictcount'.

edicts - lists info about all the edicts
edict N - lists info about the Nth edict 
Apart From 
the famous 600 edict limit in normal engines, there's also another related issue; the server signon buffer size.

This typically becomes a problem when saving the game and then reloading it. If there are too many active edicts, the signon buffer will overflow and the engine aborts with the also famous SZ_GetSpace: ... error.

In my upcoming engine versions I've tried to improve this check so you'll get a warning when you exceed the normal limit. 
How much is too much? How could it be made more interesting? I just realized I've got quite a bit good 'ol backtracking action going on here. 
Seven Times 
around the same general area would be excessive, unless you open areas up from new vistas or do neat Doom style room deformations then you could go maybe as many as twelve encircling routes. 
Q1 Tools Update 
at . All engines are updated with many features/fixes, e.g. more help to debug maps and reduced CPU load. RVis includes more ambient sound control and TreeQBSP has a minor fix. Please also see readmes for details.

Any comments are welcome. 
I get an error about fmod.dll. I have this file in the right place but nehahra will not start. 
thanks for info about the laser :) I should have known that by myself. 
Make sure you're using the fmod.dll from the Nehahra pack. Newer versions of this DLL (distributed by e.g. JoeQuake) is apparently not backwards compatible, i.e. there's a missing call entry. I wonder what reason they had for doing this ... 
That pretty much depends on the map and how it's implemented. As a vague rule, I'd say that backtracking for more than 1/3 of the entire map is probably a bad idea.

As mentioned Headthump, there are lots of things you can do to spice it up. Typical stuff is just spawning in a few monsters to surprise and toy with the player. For more varied and unique situations, you'd need to analyze what the player did before having to backtrack. Did he activate/deactivate a power grid? Maybe have that open some windows, turn off some lights, or activate some idle machinery. Are there balconeys the player can't get to? Maybe add a few scripted scenes for the player to watch; or perhaps have some lights flicker briefly as if there was a momentary lapse in power.

And if you're well and truly out of ideas, just make random things blow up and have pipes spew massive quantities of steam; that's always a thrill. 
Friction X2 
If you truly did "just realize" how much backtracking the player needs to do, then you might consider opening up a few new alternate routes for the player to get back to the previous area. Maybe let him crawl up into a pipe or onto a catwalk and go view some of the map from a previous angle. 
Friction X3 
Okay, that post was rather incoherent.

If you truly did "just realize" how much backtracking the player needs to do, then it's probably not too late to change the layout or route a little bit. Maybe let him crawl up into a pipe or onto a catwalk and go view some of the map from an angle that was previous inaccessible. This would also be fun for sniping on unsuspecting soldiers that have somehow re-filled the area. 
backtracking is ok as long as the gameplay changes significantly on each backtrack.

If a maps layout and architecture is OMG THE BEST EVER [like Insomnia for example], then backtracking can become "a wonderful thing" (TM), not just annoying. 
Any One Notice This? 
A working installer of Darkedit, an updated version of BSP has been found recently. 
Well, um. I have three alternate routes through upper maintenance sector. But player still has to go through it twice. Maybe I'm just being overtly sensitive about backtracking. However, the idea about machines changing state is interesting. 
I read PRG's ideas about backtracking and it forced me to ask a similar question.

When backtracking is too long to be replaced by teleporter?

In my map for arcane project player needs to backtrack thru a rather long part of map twice: the first time when he presses the button, the second time when he gets the silver key. So I was thinking about placing teleporter somewhere, but I like to make backtracking much more.

Any ideas? 
Backtracking is a good way to extend the length and monster count of your map, but it's not to be taken lightly.

First, there must be new monsters. Period.

Second, these areas must be designed well enough that the player discovers new gameplay, with new advantages/disadvantages, when he's coming into these areas from the other direction.

Third, don't backtrack too much. The map will wear thin if you make the player haul across the same stuff three or four times.

Fourth, make it clear where he's going. Unless the map has a really unique and varied design that the player can easily remember his way around in, make sure he's ushered in the right direction. The big obvious quake-arrows help. It's a pain wandering around a map where everything looks the same, finding a key, and going, "okay, where the hell was the door?" The player doesn't have a top down view like you do. 
One Advantage To Backtracking 
is that the player has already learnt from his previous experiences, what are the best ways to fight in a certain spot (or should at least have an idea anyway).
to this end, you can increase difficulty to what would normally be a little excessive. the player's knowledge of the areas he'll be fighting in, should give him a bit of an edge, and make that excessive situation just about normal. 
Backtracking Ideas 
- fighting your way down a pit and then fighting back up

- shift platforms or walls, reveal traps

- open up the ceiling to reveal the skybox or other inconsequential coolness

- block directions the player shouldn't take

- and of course spawn more monsters 
Quake C Question 
I have two progs.dat files. One is much bigger than the other and I am looking at the differences. I am looking at ogre.qc and see these two differences-

void () ogre_die3 = [ 114, ogre_die4 ]
self.solid = SOLID_NOT;
self.ammo_rockets = SPAWNFLAG_LASER;
DropBackpack ();

and the other-

void () ogre_die3 = [ 114, ogre_die4 ]
self.solid = SOLID_NOT;
self.ammo_rockets = MOVETYPE_FLY;
DropBackpack ();

Why should there be differences and what does it do in the game? 
Code And Decompiling 
MOVETYPE_FLY and SPAWNFLAG_LASER are both just constant floats within the QC, defined in defs.qc and in misc.qc. SPAWNFLAG_LASER takes the value 2, so that the ogre drops 2 rockets in that mod. MOVETYPE_FLY normally has the value 5 assigned to it, so in that mod the ogres will drop 5 rockets instead. However, the fact that either of those constants appear in the code you're quoting suggests that you got the code by decompiling. Are you sure that's the only difference between the two sets of code?

If it is the only difference, then the size of the compiled progs files could just be due to the compiler originally used on each one. More recent compilers perform lots of optimisations that reduce the size of the progs(the size reduction is a side effect of the intended aim, which is to make the file hit fewer limits in the quake engine and so on). If there are more changes in the code, then they are much more likely to account for the difference in size.

In short, the only gameplay difference will be the number of rockets dropped by the ogre, and I'd guess that shouldn't affect the progs size at all. 
Thank you for explaining. What is the benefits by using constants instead of entering the value you want?

Yes, I did get the codes from de-compiling and one of the versions was (I think) yours - spawning monsters by the use of the 'style' flag in the map?

I have since found some more differences which is to do with setting monsters health from the map file. And also to do with ogres shooting missiles instead of grenades but I can not yet work it out. 
Constants And Decompiling 
The advantage of of using constants is to make the code clearer, and the ogre code above is a really bad example of this, as it's made things more confusing not less. The quake engine and the QC code both remember a lot of properties, such as the way an object moves (it's movetype) as numbers. But if you want to code something with the flight movetype, it's annoying to have to look up a number, and when you read the code back:
self.movetype = 5;
isn't very clear; you'd have to look up what movetype corresponds with 5 to figure out what the code means.
self.movetype = MOVETYPE_FLY;
is much easier to understand, although once it's compiled, both lines are equivalent.

The equivalence causes a problem when you come to decompile the code. The decompiler can't see which constants to use where(to the best of my knowledge) and so it takes a guess as to which ones belong where. In the case of the ogre, it's guessed incorrectly that the number of rockets should be a constant. In the case of the ogre, there is no advantage in using a constant instead of just entering the value, and in the original code it is just a number:

void() ogre_die3 =[ $death3, ogre_die4 ]
{self.solid = SOLID_NOT;
self.ammo_rockets = 2;DropBackpack();};

As a recommendation, I'd try to not work with decompiled code where you can, I hope that the source to the mod I wrote is included with the mod, otherwise let me know and I'll send you it. If you're trying to merge multiple mods together, and there's no way to get the source code for the other mods, start with the clean source/source to my mod, then add just the bits of decompiled code that you need to that base.

Decompiled code also lacks comments, which are sometimes quite helpful. For the teleport mod, all the changes I made were commented, so if you wanted to add teleporting to another mod, you could simply find all the comments in the code, and follow the instructions to copy them into another mod.

Phew, that ended up long... 
Words of wisdom thank you.

I started looking at code back about front as I wanted to see how to compile before I had written anything to compile. So I decompiled some progs.dat to play with which is why I ended up with code without comments. So now I try to do it right.

I now have the source code and it is yours. What is the extension .$$$ used for? The code in these files includes shalrath_tele. Does the $$$ files get compiled just the same?

How does the game know that the code for monster_shalrath_tele as entered in the map file is in the shalrath qc file, is this defined somewhere else? I am not clear because you say in the readme file that if the shalrath is not to teleport away than use the ordinary shalrath so I think that both will be compiled.

I am really interested in learning about this code so I am sorry if all of this is too simple for you but will be pleased if you will help. 
Make $$$ Quick!!!!! 
Arrrgh, I shouldn't have left the $$$ files in there. They are backup files that get automatically generated by the program I use to edit qc files, you can safely ignore them or delete them.

The idea behind the monster_shalrath_tele is this: When a map is loaded, the engine looks at the name of every entity that is included in the map. It then tries to find a function in the QC with the same name as the entity, and runs that function(or produces an error message if it can't find the function). The function is usually designed to set up the entity in question, set it's model, it's behaviour and so on. The engine sets the entity called self to be the entity in the map, so by setting in the function you affect the health of the thing in the map.

When you run this mod along with a map that has a monster_shalrath_tele entity, it runs the function
monster_shalrath_tele();, which basically makes a vore in the right place in the map, with a special death animation that looks like a teleport.

Because there's a new function for this kind of shalrath, the old one is still present, and unchanged. So any monster_shalrath in the map will be just like the ones in the original quake. I could have programmed it differently, so that you just set a flag on a normal monster_shalrath in the map, that makes it teleport out on death, but I did it this way because that's what the original recipient requested.

If you wanted to make, say, a new monster, so that the entity you added to a map was called monster_troll, then you'd call all the animation functions and so on whatever you like(although it's usual to stick to the conventions in the existing code). Then just ensure the spawn function was called monster_troll().

Hope that clears up how the game knows what code to use for which entites. 
Great, I understand now. Thank you. 
Well, I am quite pleased because I managed to find your error tutorial hidden in the shambler.qc file ;-)


I stared at it for a long time before I could see it!

I didnot try the progs.dat supplied as I was adding some code so I cannot say if is OK or not. But it compiles good now and works fine. Thanks again. 
Well, I am quite pleased because I managed to find your error tutorial hidden in the shambler.qc file ;-)


I stared at it for a long time before I could see it!

I didnot try the progs.dat supplied as I was adding some code so I cannot say if is OK or not. But it compiles good now and works fine. Thanks again. 
Well, I am quite pleased because I managed to find your error tutorial hidden in the shambler.qc file ;-)


I stared at it for a long time before I could see it!

I didnot try the progs.dat supplied as I was adding some code so I cannot say if is OK or not. But it compiles good now and works fine. Thanks again. 
Well, I am quite pleased because I managed to find your error tutorial hidden in the shambler.qc file ;-)


I stared at it for a long time before I could see it!

I didnot try the progs.dat supplied as I was adding some code so I cannot say if is OK or not. But it compiles good now and works fine. Thanks again. 
Well, I am quite pleased because I managed to find your error tutorial hidden in the shambler.qc file ;-)


I stared at it for a long time before I could see it!

I didnot try the progs.dat supplied as I was adding some code so I cannot say if is OK or not. But it compiles good now and works fine. Thanks again. 
Well, I am quite pleased because I managed to find your error tutorial hidden in the shambler.qc file ;-)


I stared at it for a long time before I could see it!

I didnot try the progs.dat supplied as I was adding some code so I cannot say if is OK or not. But it compiles good now and works fine. Thanks again. 
Well, I am quite pleased because I managed to find your error tutorial hidden in the shambler.qc file ;-)


I stared at it for a long time before I could see it!

I didnot try the progs.dat supplied as I was adding some code so I cannot say if is OK or not. But it compiles good now and works fine. Thanks again. 
Well, I am quite pleased because I managed to find your error tutorial hidden in the shambler.qc file ;-)


I stared at it for a long time before I could see it!

I didnot try the progs.dat supplied as I was adding some code so I cannot say if is OK or not. But it compiles good now and works fine. Thanks again. 
Well, I am quite pleased because I managed to find your error tutorial hidden in the shambler.qc file ;-)


I stared at it for a long time before I could see it!

I didnot try the progs.dat supplied as I was adding some code so I cannot say if is OK or not. But it compiles good now and works fine. Thanks again. 
Well, I am quite pleased because I managed to find your error tutorial hidden in the shambler.qc file ;-)


I stared at it for a long time before I could see it!

I didnot try the progs.dat supplied as I was adding some code so I cannot say if is OK or not. But it compiles good now and works fine. Thanks again. 
Holy Fuck, 
a new record!

blaGGer, please don't hit submit a bunch of times, or refresh or whatever the hell you did. 
A dectuple-post!!
Hell yeah. If you're going to do something, then by golly, just go all out with your bad self.

I'm home sick today and feel kind of shitty, and that made me feel better. 
I am not in the trunc dreath?
I am not in the grunt breath?
I am not in the drunk thread? 
Blagger Is Just Simply Quite Pleased! 
Sorry, Sorrry, Sooorrrry 
So sorry times many times! 
I really think you need to take medical advice from a neurologist to solve your restlessness problem... believe me... ;) 
Flawless Victory! 
Trigger_teleport Sound 
I there a problem with the SILENT flag in the trigger_teleport routine as it makes no difference if it is set or not.

I am looking in the triggers.qc file and the only reference I can see is
if (!(self.spawnflags & SILENT))

Is that right? & or == 
Silence Is Golden 
It may be that the flag is working, just not how you expect. Silent teleporters still make the noise when something teleports in, they just don't make the ambient teleporter hum near to the trigger. It's intended for trigger_teleports that sit outside the main level, for teleporting monsters in, as the sound out there would be pointless, unless it spilled over into the real level, which would be confusing. 
What I am wanting is for no sound at all when I teleport my extra monsters in. I am happy for there to be sound when the player uses a trasporter. I have some triggers that teleport monsters into places the player has been to once and I do not want the player to know that by hearing sounds.

I thought that was what the flag SILENT was for . Can you guide me how I may stop the teleport sound? 
The Sound Of Silence 
Ok, the first function to look at is play_teleport, which selects a random teleport sound and plays it. However, we cannot change this function, because it is a think function for a temporary entity. This means we have no way to check whether it was spawned by a trigger_teleport that is silent or not. So, we need to look at the code that calls this bit.

The next function is spawn_tfog, which spawns a new entity s, who's only purpose is to play the sound in the right place in 0.2 seconds. Ideally we would have an if statement around that spawn function, but again we can't be sure what function has called spawn_tfog. If it was the trigger_teleport, then we'd know the trigger was the "self" entity. But another entity might call spawn_tfog, and so modifying this function might cause problems in other places.

So, we go back one more function, to teleport_touch. So, above this function add the line
float NONOISE = 4;
This is just defining a new constant for the flags on a teleporter; if you set flag 4 then the trigger_teleport, then anything teleported will be silent.

Then go down into the function, and find the lines

makevectors (t.mangle);
org = t.origin + 32 * v_forward;
spawn_tfog (org);

and replace it with

if(!(self.flags & NONOISE))
makevectors (t.mangle);
org = t.origin + 32 * v_forward;

spawn_tfog (org);}

Notice that this gets rid of spawn_tfog totally, so you get no flash as well as no sound. I assume that if the monsters are meant to teleport in without informing the player, no teleporter flash is needed.

If you did want silent teleports that included the flash, you'd need to add
makevectors (t.mangle);
org = t.origin + 32 * v_forward;

after the if statement, and make a copy of spawn_tfog called spawn_tfog_silent, which omitted the sound spawning lines.

As a side note for mappers, it turns out that play_teleport is a function like barrel_explode that can be called by the func_notnull trick. So if you want to spam false teleport sounds at the player, you now have the power! Well, I'll confess I've not actually tried it in a map, but it looks like it should work. 
[deleted by metlslime] 
I managed to change the v_shot gun mdl into a crosbow. Now I want to make it shoot arrows. So I made the crosbow.mdl of 7 frames, and one arrow.mdl for the arrow.

Now it comes to qc and I knew this would be a hard one for me. I've been looking to the 3Dinside for one, but I could only find thowing axe to compare. But the zip file link is lost. Is it really much coding to make it go? 
Bows And Arrows 
I'm not gonna do a detailed how to here, be warned, but rest assured it's not too hard. Have a look at the code for firing nails, it's pretty close to firing an arrow. Just copy and rename the nail functions, and change the model, the speed and the damage. Then in the weapon firing code, change the fire function for the shotgun from the current one to the new arrow one. Let me know if anything goes wrong, or if you wanted different behavior from that of a nail. 
I was allready looking to older examples of the Phenomenon CD. But with this I can go on for a while.
Glad to have this little help, because c coding for me is almost as hard as writing a full sentence without spelling problems! 
[deleted by metlslime] 
Are you trying to "rebirth" hexen weapons ? 
Knew It Won't Be Easy 
I don't think the shotgun has a substantive bullit?

By now my only progress is replacing the s_spike.mdl for an arrow.mdl
Then the supershotgun shoots arrows, while the nailgun still punshes nails.

But that's no true code afterall. 
I Understood That. 
Arrows And Stuff 
Ok, the full walkthrough on coding the arrow in.

void() W_FireSuperSpikes =
and duplicate the whole function, renaming the copy of the function to W_FireArrow

In this version of the function, replace the model of the spike with the arrow model and either find a suitable sound replacement or just delete that line. Change the line
newmis.touch = superspike_touch;
newmis.touch = arrow_touch;

self.currentammo = self.ammo_nails = self.ammo_nails - 2;


self.currentammo = self.ammo_shells = self.ammo_shells - 1;

Copy the function void() superspike_touch = and paste it about the W_FireArrow function. Now rename it as arrow_touch. Here you can set the damage you want the arrow to do, replace the two instances that say 18 with whatever damage you see fit : -).

Finally, go down to the function W_Attack. Find the line

else if (self.weapon == IT_SHOTGUN)
player_shot1 ();
W_FireShotgun ();
self.attack_finished = time + 0.5;

and change it to

else if (self.weapon == IT_SHOTGUN)
player_shot1 ();
W_FireArrow ();
self.attack_finished = time + 0.5;

Note that the weapon is using a single shell each time it fires. If you want to change what kind of ammo it uses you need to poke around in lots of different functions, even more if you want it to use multiple shells in a shot. So let me know what you had in mind ammo-wise and I'll get back to you. 
you took the time to give me some attention!

I was already working with a weapons.qc from "Freak" in his Firepower addition.
He had a progs.dat which was working right, but the client.qc and weapons.qc didn't work.

I'll try this code, and let you know how it goes. 
Thank you.

I like your training methods-

if(!(self.flags & NONOISE))

should be

if(!(self.spawnflags & NONOISE))

Just like last time I stared at it not working for a long time before I saw the problem. I found it so I must be learning!!

But I am still very grateful for your help and I am still thanking you and you are helping others as well. Well done. 
Oh yeah, all the stuff I write about QC should come with the following disclaimer:
Preach is to busy/lasy to actually compile the code he writes on this board, let alone test if it work. Use at your own risk. 
Nonetheless... are a great boon to this community.

I blow my own trumpet now.

I changed your transporting monsters progs.dat to have silent monsters if I want by setting Spawnflag 4 on the monster

void() monster_teleport =
if(!self.spawnflags & NONOISE) //blaGGer setup the if-then-else routine
self.think1(); //PREACH: set up the monster in place
spawn_tfog(self.origin); // spawn the effect
spawn_tdeath(self.origin, self); // and teleport as required
spawn_tdeath(self.origin, self);


I will hug a tree with happiness. 
What's On The Tele.. 
(...the goldfish bowl, like usual)

Looks solid, the only thing that I'd check is that spawnflag 4 isn't used for anything else on any monster - it doesn't look like it though. If it is, just change it to some higher power of 2, like 16 or 32.

In other news, I have been experimenting with what you can and can't do with a func_notnull, and the results are suprising to say the least. The teleport sound I mentioned a few posts earlier works, although it'll only play once per entity as it has a remove in the function. But I've found many more functions that work too...I have a little testmap made up, but I'm gonna see if I can't make something useful out of the entities before I let on. 
Exploding Walls 
I looking at a exploding wall mod by Ben Lehman (1996). It works good but the rubble bits flicker in the game until they disappear.

Does any of you know how to stop this? 
Double Check The Skin 
on the rubble model; It could be a number of possibilaties. It may need to have the fullbrights removed or the skin isn't covering the entire surface. Also if any of the surface normals are facing the wrong directions it could appear to flicker while in movement. Any of those problems can be corrected with a basic Quake modeler like MDL. 
Quake Models 
I have the rubble models in qME and I want to change the texture to match the wall that the exploding wall is in.

How can I overlay the city8_2 texture on the model? I have Adquedit, qME and I got Photoshop at work.

Does anybody know of helpful sites for these old programs? 
I did not understood the flicker problem at first time. I was looking at it with quad damage and it not flicker with normal looking. So OK now. Thank you for helping. 
I Hug More Trees 
In my rest time I used the company Photoshop and made new model skin.

I exported the new texture from TexMex in BMP
I exported the old skin from qME in BMP
I imported them two into Photoshop using layers
I changed the Mode to RGB and erased the old skin leaving the new texture to show through
I flattened the layers
I changed the Mode to Indexed
I saved it as BMP
I imported it into qME
I changed the old skin name to skin1
I changed the new skin to skin0
I saved the model into the program folder and run Quake and it works so now some of the rubble bits look like the wall that just exploded.

Now I get back to work and change the more rubble bits tonite. Is this the right way to change skins? 
Sounds like exactly the right way - good work. 
Not So Good 
I am now using txture Rock1_2. When I import back into qME I see lots of black pixels that were not in Photoshop view.

When I convert back from Photoshop RGB to Indexed my selections are Palette: exact, Forced: none, Matte: none. Are some of the colors changing somehow in my converting and qME thinks they are not Quake colors so just gives those pixels black color?

I was happy hugging the trees and now I boot them. 
modes with Photoshop have always given me a lttile fuss as well. I would suggest exporting in RPG and using Wally or TexMex (which is the simplest of the two methods as it does the conversion automatically; I like touching things up in Wally though) to convert back to Quake 16 bit indexed.

The root problem could very well be that Photoshop is defaulting the RGB mode to 24 bit though, in which case, instead of my above suggestion, convert the 24 bit RGB to 16 bit RGB and then convert it to 16 bit Indexed. The translation should be smoother. 
This works all the time for rubble bits:

export skin from qME - this is automatic BMP file
open in Photoshop - this is automatic Index Mode
change Mode to RGB - this is automatic 8 bits
copy to new layer
delete Background layer
Magic Wand in black area - Tolerence 0, Anti-alias off
Inverse selection
press Delete - this is the mask
export rubble bits texture from TexMex - use BMP
open in Photoshop - this is automatic Index Mode
change Mode to RGB - this is automatic 8 bits
use Move tool to drag texture into mask window - this opens as a new layer
swap the layers around - this puts the texture under the mask
Flatten image
change Mode to Index - Palette: exact, Forced: none
save as BMP - File Format: Windows, Depth 8 bit
Import into TexMex
do nothing - maybe drink coffee
Export as BMP
Import into qME
Save model into Quake progs
Play Quake

Time to work this out and type this 25 minutes
Time to do it now I know is 4 minutes each rubble bit

Thank you HeadThump 
More Quake C Help Please 
The exploding wall entity calls a function that starts a new entity (local entity new) that uses setmodel to define the rubble bits models (setmodel (new, "progs/rubble1.mdl");). I can set the skin of the exploding wall entity in the editor. I can read setting from inside the function but this is not the rubble bits so the rubble bits skin will not change yet.

How can I set the skin of that rubble model using the skin setting that I bring in from the exploding wall entity? I think like this - rubbleskin = and then set the rubble.mdl to use the skin rubbleskin. rubbleskin will be a number 1 to 4 being textured rock(1), wall(2), wood(3) and metal(4)

I try various = 1, = 1, to test the setting of the skin but get errors like - Error wall QC(17): expected;, found new.

new is the name of the entity that has been made to create the rubble bits and is the first part of the line after = 1

I hope you understand this Preach or HeadThump? 
From What I Gather From The Error Message just seems you forgot to terminate the line above with a semicolon; 
Dohhhh. I am the dopie one.

It now works as I wanted. No tree hugging now as my girlfrend has suspisions.

Thank you czg. 
Setting Monsters 
Can you explain why these are two separate functions and not all in one? Is it needed because there are more than one ogres in a level?

void() monster_ogre =

void() monster_ogre_set =

And what is void() monster_ogre_marksman =

Game, Set And Marksman 
Normally in quake the two functions monster_ogre and monster_ogre_set are just one function. They are seperated out for the purpose of the teleport code. This way, when the server starts, the monster_ogre function is called, and decides if the ogre needs to be spawned now or later. It does the precaches now, because everything has to be precached at the start of the server.

Monster_ogre_set is called either straight after monster_ogre for a non teleporter, or when the monster teleports in. This part of the code is seperated out so the monster is non solid and invisible when it hasn't teleported in. If the monster isn't a teleport monster, the code behaves exactly the same as if the two functions were one.

Monster_ogre_marksman is a monster that ID was originally going to make different to regular ogres, but then decided to make all the ogres the same. Rather than replace all the monster_ogre_marksman entites with monster_ogre in the maps they'd made so far, they just made it so both of them do the same thing, spawn a regular ogre. So basically it does nothing. 
Monster_ogre_marksman Does Do One Thing. 
Ogres will infight if they are marksman/not marksman. 
using different classnames like you describe will break the monster obituary code (unless you fix that, too.) 
Qeradiant 1.5 For Q1 
How do I first of all get the texture wads to work for qeradiant 1.5 for q1? The new radiant should "support" q1. Is there someone who uses this? There's very little documents in the net. :(

Or do I have to do _everything_ q3-style (meaning all the scripts and tga's and whatnot) and just compile the resulting intermediate files to q1 bsp's with aguirre's tools? 
All of your wads have to be in Quake/id1/

Easy as that. 
bambus, I suppose you're talking about gtkradiant 1.5? Make sure you go in under options and point your filepath to your quake directory. 
Setting Target_speaker States 
I'm mapping for Enemy Territory Fortress (, which is a mod for Enemy Territory, which uses the Quake 3 engine. I've got a target_speaker that I want to have on and looping at the start of the map, turn off while a particular info_notnull is active, and turn back on when the info_notnull becomes inactive after 30 seconds.

My understanding of target_speakers is that they can only be "triggered" which toggles their state from what appears to be "play" and "don't play", except just triggering the target_speaker using activetarget and inactivetarget from the info_notnull does not work correctly for some reason. The sound starts at map start, then shuts off when the info_notnull is active, but then it never comes back on again.

I've tried implicitly setting the target_speaker to ~active/~inactive, ~active/~disabled, ~inactive/~invisible, and pretty much any other combination that seemed to make sense, but either the sound plays at the exact opposite of when it is supposed to, or it works for the first activation and then never again.

Anyone have a breakdown of how to implicitly control the states of target_speakers? 
what it was,

I'm not sure, but I know someone who might know, so hold tight, and check back in about 6-12 hours :D 
Qeradiant 1.5 For Q1 
Thanks Blitz, it helped. But I'm sorry, I still have problems. Now I can texture fine in the editor, but the resulting .map file has no references to the used wad file (I checked it with a text editor) and thus the compile fails to put textures in the bsp (although it seems to work otherwise).

The settings menus are really spartan and there's very little documentation about q1 mapping.

I guess I could add the wad references by hand but it's a hack.
How are you doing all this? 
There Is Probably 
a better way of doing this in Radiant, but using my compilers, you can have a wad with the same name as the map file in the same dir (so called default wad). The compiler will use that wad if no wad key exists or the referenced wads can't be found.

You can also use wild card specifications in the wad key (e.g. "mywad.wad;*.wad"). 
Incompatible Demos 
Does anyone have a (preferrably small) Q1 demo file that is corrupt or otherwise unplayable in standard engines (e.g. FitzQuake)? I'd like some test material for a new demo conversion/validation tool. 
Add the wad information to your map's worldspawn with the following key/value:


Unless you already did this and it still isn't working, in which case I'm not sure what's up :/

Also: the line length limit on this forum is a fucking joke. 
I looking for new sounds for Quake 1SP. Explosions, breaking glass, avalanches, anything new and ready to play.

I do not know if there is a special format of if I can use wav files without change.

Is there sites that can help can somebody tell me please. 
There Is A Special Format 
As far as I know, the .wavs have to be 8bit/11khz/mono/PCM

You can convert any .wav you find to that fidelity as long as you have a proper audio editor...I'm sure there are freeware programs out there that can do it. 
Marcher Fortress 
Is the monsters in Ben Woodings Marcher Fortress in the public domane?

Do you know were to get them?

For God's Sake, Please!!!!!! 
The Imp Mr. Kinn Used 
is on this page if I am not mistaken 
Great thank you. Do you know of the gauroch.qc?

I think metslime and me want the same thing so I try to get my map finished first. 
I'm Sorry 
I'm drawing a blank. I don't recall what the gauroch is, from Necro-Kell's project maybe? Where is Necros these days anyway? 
He is a two leg creature that throws blue things at you in Marcher Fortress. There are two types. A white one you see first near the tree when you get up the stairs. And a brown one that is under the bridge. The brown on is harder to kill and he runs at you fast and he throws gold bombs at you. He is good and would like to yous him in my levels. 
Yes, I Recall It, I Just Didn't Know The Name Of It 
regardless of its origin, I'm sure Kinn coded the QuakeC for it so you'll need his permission though you could simply have the end user download the map into their Marcher directory so there would be no need for rebundling the pack file. 
Thank you for trying but when I place a monster_gauroch in the map it does not appear in the game.

The monster spawning works but exploding walls do not. I have other THINGS in my map that are not in Marcher Fortress. I have built my own progs.dat file from things I have found in the public domane.

I must try to talk to Kinn.

Kinn, are you there? 
The Marcher Gauroch, Imp and Spider are models originally from Hexen. Kinn reworked the skins and wrote entirely new code for them.

As a n00b mapper you can't always expect experienced members of the community to deliver their content on request.
Custom code is made available only at the discretion of the author, so unless it is explicitly stated somewhere - in a readme, webpage or tutorial - it is unlikely they want it available for other projects.

If you want to try making your own monsters by the same method - i.e. taking an existing model from a Quake-engine game ( such as one of the old mission packs or Hexen ) and writing new code - you'll get some help here from coders etc.

If you haven't made and released a map before though, it is adviseable to make your first project using only id content i.e. the stuff that originally comes with Quake. You'll avoid tripping up on a lot of technical problems and the like. Once you are more familiar with the basics you'll be in a better position to seek detailed assistance or, better yet, to start working on your own custom content :)

I understand your explaining.

I will take the monsters from Hexen and will write the code and will ask for help here if I stuck on code. I have demo of Hexen2 and will take it apart now. Thank you for patience with me. 
IIRC, out of the custom monsters seen in Marcher Fortress, only the Imp is present in the Hexen 2 demo. You'll have to "take apart" the original full game to get the others. 
Thank you. I could not find the gauroch so thought it may not be in the demo. I will not buy the game so I will not get the gauroch. The imp is in the public domane already also the spiders. I am looking at the archer as he might be good for throwing different missiles but I would need to take the bow away or maybe change it.

I have to learn qME first and I have to learn coloring. Does anyone know of sites to learn about converting Hexen to Quake - Google knows nothing. 
Lightwave Vertex Color / Weight Map + Q3map2 
Does anyone know how to get lightwave's vertex color or weight map into q3 maps via q3map2 and use them for rgbgen vertex or the like ? 
I Tried That... 
With ASE models with vertex alpha and vertex colour. I don't think it works. 
...I'm not sure anyone got back to you, but why not use two target_speaker, one that stops then one that starts? 
Vertex Color Stuff 
anyone one interested should look here

thanks for the input shallow. 
Quake Mdl 
I using 3dMax7 at work to make models for Quake1SP. They good I think. When I load those into qME I get a "numbers of triangles" not matching error message.

Can any one tell me how to convert from 3dsMax7 to qME? If no can you tell me the best ways to make new models or do I have to use the qME. 
Easy Fix (and Then 4 More Paragraphs For Good Luck) 
I suspect what you're doing is using the import frames command, which isn't what you want to do when starting a new model. There are two commands for importing into QME, "import objects" and "import frames"

Import objects adds the triangles in another file to the current model. It takes the pose it reads from the file, and puts the triangles in that pose in every frame in the model's animation.

Import frames takes the pose it reads from the selected file, and creates a new animation frame in the model. It then moves the triangles that are already part of the model to match the pose that it has read. Obviously, this will only work if there are the same number of triangles in the current model as there are in the file.

So, when you create a new model, there are no triangles, and so you'll get the error message you mentioned if you try to use import frames. Use import object and it should work.

However, be warned, QMe will not import any animation or UV mapping that you did on the max model, just the triangles and the pose at time 0. To get the rest of the animation in, export each frame to a seperate .3ds file, and use import frames(not import objects) to load them.

The UV mapping is another matter, QMe has no support for importing a UV map, and only allows you to create 2 sided planar mappings in the editor. This is because that's the way the original quake models were made, and when QMe was written nobody knew .mdl supported anything else.

So, how do you get a model with a nice UV map into quake? Well, it's a bit more complicated. Track down a copy of the pop'n'fresh MD3 exporter for max(polycount is a good place to start). Now, rather than export the finished model from max to .3ds, export to md3. Finally, open it in the latest version of quark and save it as a classic Q1 model. You should end up with one mdl, with identical skinmap and animations as the md3.

I make the last step sound easier than it often is, Quark seems to have immense difficulty loading the skin with the md3 if you don't set up the directories exactly right. I've been intending for ages to write a detailed tutorial on making this md3 to mdl conversion, so if you get stuck here just say and I might actually get round to it! 
so .mdl DOES support more than just two-sided planar mapping of a speciall-deformed baseframe?

Hmm, if you set every edge to be a border edge, i guess that means you could map each triangle seperately... would that work? 
Md3 -> Mdl 
From what I understand of the .mdl format through my own recent fiddlings, the UV map will appear in Quark because it must be splitting the verts on the model for each actual animation frame in order to correspond to the pseudo-UV map. The .mdl stores not only the location of the verts for each frame, but their relationship to each other in the mesh as a whole ( which is why changing an existing model cause the .ms2 to look utterly screwed ingame ).
What I suspect you're left with is a .mdl with many more verts than it actually appears to be made of, because any vert that has been split for the UV map must be made of 2 or more verts occupying the same coords in the animation frames as well.
I think.
Preach, would this be the case? 
go finish what should be finished

ya, what vondur said 
Quake MDL 
I know I am just a greenhorn in this case...but

Making new models in QMLE gave me a rather strange experience in extentions in which the models are imported and exported.

I used a AM2000 animation studio, which gave me the intention it would work good with Quake models, as it used the *.mdl extention.
This was not true, because one has 1-4-16 polygons per patch. I couldn't load them in the animator. So I went searching for a manner they would.

First I tried excisting Quake1 models to change in extention so they would be campatible.
The first attempts I made was with the Q2mdlr9b modeller. This was capeable to import Q1
models and export them to ASC and 3DS. This 3DS I imported in Milkshape and exported again to DXF. This was the right extention to import it in the AM2000 animator.
Then I could manupilate the model, give it bones, so I could give it all the animated frames
it needed to export them to 1 spline dxf frames to import them in QMLE.
To my advantage I could make a skin base model and tear it totaly apart, because theanimated frames were already made. This gave me a good oppertunity to skin the model at the best.
I know Milkshape has it own way of doing these things. I have tried, but never succeeded.
In this way I managed to transport the Q2 model grrll to Qmle for Quake1.
I could transport the Q1 models to Q2, although it would tale some time.(and *.qc knowhow!)

So what I intentionally mean is, why not try the extention import and export of the Q2mdlr9b
and Milkshape to transport your model from Max3D to Qmle? 
Multi-vertex Mania 
Yeah, that's pretty much it, the number of vertexes in your model is exactly equal to the number of vertexes you can see on the UV map. This could potentially cause a problem, as the original GLquake vertex limit is only 1000. If you're making a model that has that nearly that many verts already, you may be stuck with the two sided planar mapping. It also makes the file that much bigger, but generally the animations are smaller than the skin every time. I suppose if the model had lots of frames you might notice.

On the plus side it doesn't seem to hurt rendering by a noticable amount, so it's just a matter of making sure you don't ever break the vertexes when you're editing/animating. There are two ways I can see of safely doing this. One is to animate the whole thing as an md3, before you convert it. The other is to have two copies of your model, one with the uv splits, and one without. Since QMe imports triangles not vertexes, you can animate the non split version, then import the animations into the split model. You just have to hope that the order of the triangles doesn't change...go for option 1 is my advice.

But it's very much worth it by my reckoning, the skins are much easier to paint and they use the skin space far more efficiently.
Finally, very important skin tip of the day: Make your skins in power of 2 sizes, like 256x256. You might object and say that none of the original quake skins are like that. This is because they were made before the advent of glquake and all that. Opengl/your graphics card will resize your skin to a power of 2 size when it loads it, so your skins will be sharper ingame if you make them the right size to start. 
Preach: thx, that's cool. Though the issue with animating in Max and having higher vert counts is already relevant to much of what necros and I have been doing ( note: necros now does all our animating in 3DSM then exports the frames - one by one - over to qME ); many verts, many many frames...
Also, re: powers of 2. Right off the bat I endevoured to make our model skins PoT, mostly out of habit from tex0ring. FitzQuake, afaik actually solves non PoT skins by initially 'padding' the skins out the next PoT and using those. metl r0x0rz y'see.

Von/PuLSaR: mapping etc. is done. I'm just waiting on necros getting his elven ass out of WoW and back on the hotdog - I need my codemonkey to fix0r some things. 
preach: actually it's the application's responsibility to resize the texture before passing the data to opengl, but you're correct that you get much better results with gl engines if you make textures powers of two.

kell: correct, fitzquake pads the skins instead of resampling them, because they don't have to tile like world textures do. I also do it for graphics like the console background and menu images and status bar images, since those don't have to tile either. 
damn this blizzard fuckers! argh 
Um...talking of both Chapters and FitzQuake...
Since there are a few skyboxes used in the chapters maps, is FQ 0.8 likely to be released soon? It would be unwise for players to be using 0.75 due to the skybug, but I really want to recommend FQ as the engine of choice for Chapters.

Von: I know. Bastards. Curse them for making addictive games! 
I Lost My Brother To WoW 
he'll never get his pool open at the rate he is going. My summer social life is screwed. Damn, Blizzard. Damn them to Hell. 
Don't Worry... 
He'll be so into WoW in a few weeks, that he'll end up selling the pool on eBay to buy some rare item he needs in the game. 
well, maybe... i'm really close, but things are also going kind of slow. Maybe after E3 i can wrap it up. 
The pool is the only thing that gets the ladies to overlook my creepy outward demeanor that doesn't cost me an arm and a leg. 
Jumping in with both feet to the fore, what is it the causes us to need to limit vertexes to 1000? I am also playing with models and have strayed over 1000 and the model is not yet finished (super-strength warewolf type creature who spawns from dead... no, hang on, can't tell you everything!) 
Rock Textures 
Just watched Indie do his 'leap of faith'
and I swear that rock texture is a Quake original :-) 
I suspect the rock texture to which you refer would be rock3_8. It is similar.

re: 1000 verts - I haven't hit a vert or poly limit with Q1 .mdl, though necros and I did exceed the number of frames limit.
I guess it's just another limit imposed by the structure of the file format and how it saves the information. Don't really know what to suggest other than using a composite model i.e. two or more models coded to act in unison like Armagon's torso+legs. Not an ideal solution for what you seem to be making I'm afraid. 
I just popped a 2333 vertex model (it was a wall torch without flames that I downloaded from a 3DMAX site and it looked rather nice)into FitzQuake just to see what would happen and it crashes with a 'too many vertices' message.

Have you got a 1000+ vert model to play or is the 1000 cast-in-stone? 
no 1000+ vert models - the highest I have are in the low hundreds. I doubt it's a limit you'll be able to exceed in anything other than DP or the like. 1000+ is well above conventional Quake size for a model. 
OK, thanks. Clearly I am going to have to hone my modelling skills by some degree - perhaps if I made SuperWolf less hairy or give him less teeth and claws, or somehow chunkify him...

Damn, he was begining to look so good. Mind you, I hadn't skinned him yet! And when I say good, I mean I am the only one who has seen him, and he is the first thing I have ever created, and my mum said my scotch eggs were the best she'd ever tasted when I knew they tasted like soiled carpet. So for good, read 'partly recognisable'. 
well, at 1000 verts I'm sure there must have been some quality definition to the model. But yeah, take a closer look at the id models if you haven't already and see how they represent physiology in as few polys as possible. It's surprising how much you can achieve with only the basics.

And don't scotch eggs always taste like soiled carpet...? 
1000 Verts 
I've just checked that if a model has more than 1000 vertices then it can't be loaded in standard glquake. (although oddly enough dos/winquake won't crash until about 2000). Lots of custom engines bump this up, as there are a few mods that were released pre GLquake with 1000+ vertex models that won't run in GL.

As for the theoretical limit in the mdl format, I don't really know. I suspect it's higher than 2000 simply because that's a kinda odd number to be limited to, you'd expect a power of two at least. And QMe can load models with more vertexes in, and saves them without difficulty. So if you're using a custom engine you can up this one a fair bit. Then again, if you're gonna use a custom engine you might as well use md3 instead.

So, what other solutions exist? Well, what has been done in the past is to supply two copies of a model, one that works in GLquake and a better quality one for use in custom engines/winquake.
Bit on the messy side though. If there's an obvious break in a model, like a seperate weapon or something you could make two seperate models and just use the QC to tie them together. This doesn't work well with player models, but you should get away with it on a monster.

If you do, make sure you make the attached piece walkmove with the monster rather than teleport it to the monster's origin each animation frame. Frame interpolation moves the monster smoothly between animation frames if it's trying to walkmove, and if you teleport it per animation frame it'll look jerky. If you teleport it every server frame it'll be smooth, but also it's probably less efficient.

Finally there's good old optimisation - from cutting out unnecessary bits, to only unwrapping parts of the model with the UV split method, doing others with the planar mapping, then stitching the two together in a nightmare of fiddling and pain. Don't do the second one if you can avoid it, but if you must, try using qme3.0 rather than 3.1. For some odd reason it's actually better when it comes to editing skins. 
glquake has the max verts set at 1024 and dos/winquake has them at 2000 i think. I recently switched fitzquake to 2000, but in all cases, the reason for this maximum is just becuase they wanted to load models into a fixed-size buffer and since they knew how big their own models were, they set the number to be just big enough. 
Is your email working? 
yes I will reply your mail this morning 
Thanks for all the comments.

I am not clear about the advantages of md3 over mdl: I am only talking Quake1SP and the only engine I use is FitzQuake. I have tried boning-up via Google but so many links I come across are dead. Is there a simple statement to highlight the advantageous use of md3?

Meanwhile, the mistake I made with the first Scotch Egg was that I left the shell on. I fared a little better on the second one but it was a real sod trying to keep the yolk in place while I closed the minced meat around it. But hey, one lives and learns. 
You left the shell on? That's classic. :)

Anyway, a legitimate and all encompasing question.

Where do people think would be the best place to head to start learning the basics of doom3 mapping? I have fired up the editor and it scares the bejesus out of me, and figured people here might know where the most useful tutes are to be found.

Keep in mind that apart from using 3dsmax the most advanced thing I have used for game stuff is probably worldcraft. :) 
Finish TronDM3 first. 
Md3 features over mdl:
Supports a greater precision in storing the animations.

Probably has higher max limits on vertexes and triangles and stuff.

Allows you to do a proper UV map without having to seperate the faces on the mesh.

Supports 24 bit colour skins - although using all the colours for a model for Q1 will probably make it look out of place.

Support tags - markers inside the model that allow you to attach, for example, a weapon model to the tag. The tag can be animatited, so it could follow the motion of a hand throughout the animation.

Support multiple skins for a single model - so you could skin the head and the body on different textures, one 256x256 and one 128x128 if that's a better fit than all on one 256x256.

Supports some complicated method of changing the skins using .skin files. It's like multiple skins for quake, but more complicated. Not very handy in my book, for most quake 1 purposes anyway.

I think that's all the big differences. 
Where do people think would be the best place to head to start learning the basics of doom3 mapping?

Get your info direct from the developers at iddevnet:

If you get stuck, feel free to ask the gurus on this board, or in #terrafusion. DOOMEdit is pretty easy to get the hang of if you've used similar editors. (It took me about a week or two to feel fully comfortable in DOOMEdit after making the transition from WorldCraft/Hammer). 
fitzquake does not support md3. 
That's settled, mdl it is then.

Is the place to race.

Don't listen to the nay sayers, check it out for yourself 
Will there ever be a linux port of Fitzquake? I just converted to the ubuntu hippies and now I'm badly missing my favorite engine. 
Doubtful, becuase i don't have linux. 
Can Anyone Confirm 
if a Q1 trigger_counter is a point or brush based entity? There are many maps with either one, but it appears to me that it should be point based, just like trigger_relay.

In big maps the extra unnecessary brushes may put the engine over the bmodel limit. 
It's A Point Entity 
I noticed that your earlier maps used brush based ones and the later point based. My guess is that the WC fgd file suggested a brush based and that's why most WC created maps have brush based counters. 
Old, But If The Shoe Fits... 
Linux is only free if your time is worth nothing. 
What Frib Said 
and it's only good for servers, not for usual home puter... 
how to fugure out what brush causes a problem in terrain built by triangle method? Is is extended instead of its original size and covers all the floor in the room. It also wrote *** WARNING 03: Line 20930: Brush with duplicate plane.
But how to find that line 20930. I don't want to count from the top 
i use textpad.
you can skip to a line number. then look at the brush entry to find out what brush # it is, and then go into your editor, search for that brush number and delete it (or erase the brush entry yourself in the text editor). 
What necros said; use a text editor with line number handling like TextPad ( ) and find the offending face and brush.

Some map editors include comments in the map file that can help you backtrack to the editor, otherwise you'll have to use the tex info and (if you're up for it) three-point face definition to find the brush in the editor.

However, I doubt that this particular face causes any trouble as it's just a duplicate plane and discarded by qbsp. It shouldn't cause any infinite planes. 
after 5th attempt I found that problem brush and deleted it. Though I still have no idea what was wrong with that brush.

And thanks for pointing me at textpad, downloading it right now 
The GTKRadiant Team 
has a genius, nay, a profound genius for creating bugs for Radiant that did not exist in previous packages.

I use 1.4 (I wont use 1.5 becaues it requires downloading and installing a WinXP .dll that screws up my system), and I've had minimal problems with 1.4 working on maps previously.

Tonight, I reset it to use the Quake2 settings, and the surface inspector does something really off the mark. Pressing 'S' to bring the surface inspector up works like a Control-Z combo reversing my previous texture work. This is, of course, less than useless to me.

I've never seen this happen before, so I assume it is unique to their Quake2 settings. Any suggestions? 
Hopefully A Simple Question. 
Y'know Quake, right?

Y'know e2m6, The Dismal Oubliette, right?

Y'know the room that lead down to the exit with the pillar in the middle and the slowly sinking floor where stuff teleports in as you go down?

What kind of thingy is the slowly dropping floor. Is it a slow lift/platform? or a "train"? Or some other kind of thingy entirely?

I'm Pretty Sure It's A Func_door. 
Since it makes a door sound and all. 
i'm more than sure it's func_door
since it makes a door sound and all
(it might use negative 'lip' key to move that far) 
Thanks Guys. 
Yeah, it's a door.

It didn't occur to me that it might be a very big, very slow moving vertical door. :-)

Cheers, I owe you both one. (one of anything you desire...) 
hey good to see you man!!! will you finish tromdm3??? doom3 suck :) finish the map...look like will be a great one!!! 
Rats On The Run 
finally got it working so far. Adding new monster, but now...

they only appear when I use a brush substraction. Otherwise I can hear them, but they are invissible. In an empty map they squeek but are probably stuck in the groundbrush.
When I put in one brush, they come out of the brush, and dissappear(?)
When I use notarget in a brush substraction, they just sit and wait, untill I press notarget again, then they're gone.

help ! sinking ship ! 
I search for quake101.wad or qoole.wad ALL the Net for the last weeks but I can't found that files. I found some links but they are obsolete. If you can help me, please, answer.
Thanks Quake101.wad 
Also I post messages on almost ten forums. Finally, with your help, I found it. Thanks a lot.
Best regards,
Lost Rats 
then I posted the wad the same time on the Quake forum, Ciprian.

Those rats, could it be something with the MoveBox_Solid. As they vanish "into" the brushes? 
Is your email working? I haven't received anything from you for a very long time. 
It is, I just haven't been checking it for a long time, since Chapters dominated my communications, my sleeping patterns and my deteriorating mental state for several months ( I can't remember the actual penalty for seeing a polyp in the Call Of Cthulhu RPG, but I reckon both necros and I lost 1D6 Sanity Points just trying to make the damn thing fly )

Will check and respond. 
Rats On The 2nd Run 
How can it be a model sinks in the groundbrush,
and when this brush is substracted it becomes visible? 
Q1 Tools Update 
at . All engines are updated with several features/fixes, e.g. improved demo playback handling. Light now includes multi target support and improved trigger checks. There's also a new demo conversion/validation tool; ConvDem. Please also see readmes for details.

Any comments are welcome. 
does anybody have half life textures converted for Quake? 
used something in his maps i think, you should be able to rip them. 
OK, Quake question.

I have a very small map, < 150 brushes total, and yet I am having an issue where a brush is greying out in software/Winquake, and turning into sky in DP/GLquake.

The brush is a simple, 6 face rectangle, seen here:

I am using Tyrann's compile tools as well, if that helps.

Thanks for any help you can give. 
The brush next to it was causing the problem. 
What The Hell 
is that? The sword looks huge. 
Target Limit 
Is there any way to up the limit of entities with targets you can have in Quake 1? When I was working on PH8DM2 I wanted to have lights that you could shoot out. They worked fine, but I could only have about I dunno, several, instead of dozens. 
AFAIK There's No Limit 
on targeted entities, but you can't have more than 32 switchable (=targeted) lights. This means unique trigger chains; you can use same targetname on many lights. 
I See... 
So, might there be anyway to up the limit from 32? My idea is that you could voluntarily shoot out a light or 2 for effect, or maybe once you get into a firefight, your shots or enemies shots might hit a light and kinda play on the map's mood. 
Not Without 
both tool and engine/QC support, which may cause compatibility problems. They all use the entity style key to communicate this functionality.

If it's only QC, you might make it by adding new keys that are transparent to tools/engine but handled by custom QC. I may be totally off here ... 
Since I am too dumb to learn QC, I guess I am SOL.

I'll just have to do the cliche walk-into-room-lights-go-out-oh-no routine. 
There's Also A Limit... 
in terms of "lightstyles." There are 64 lightstyles, and 32 of them are reserved for switchable lights, and the other 32 are for things like strobe, pulse, candle flicker, etc. To go past 64 lightstyles would require an engine change to increase, and might require a network protocol change, too.

But, since there are only about 12 standard lightstyles actually being used, you could change the quakec to use the other ~52 slots for switchable lights. 
QuArK Mappers For Q1 
I've tried to fix the bugs and improve the help/hints for the Q1 entity definitions in QuArK 6.x; DataQ1.qrk. This is similar to the work of CZG's updated Quake.fgd file in WC and I've also cross-checked between this file and other available sources, e.g. the actual QC-behaviour.

This is basically a work in progress, but I think most of the stuff is in place. The file is here: . Backup the original and just replace it with this version.

Any comments are welcome. 
Q1 Killtargets 
Aren't killtargeted objects restored properly when just issuing an engine "restart" command?

I've an item that should float in the air and using a func_wall beneath the item that's killtargeted by a trigger_once surrounding the player spawn point, it only works properly when the map is restarted using the "map" command; "restart" or "changelevel" doesn't work (the item drops to the floor). 
i assumed these all caused the level to load the same way (with the exception that players carry over stats during a changelevel)

It may be a bug related to the order in which edicts are processed; if so, maybe adding a trigger_relay with a small wait will solve it. 
what's happening is almost certainly related to the very short delay - and variation thereof - occurring on map load.

The solution to your problem may simply be adding "delay" "1" to the trigger_once that surrounds the info_player_start. 
I also suspect some race problem, but it's surprisingly consistent. Also, most engines behave the same way, but DP always fail to suspend the item no matter how the map is loaded.

I'll try adding the delay. 
Delay Did The Trick 
Cheers aguiRe, very useful!

I'd gotten so used to some of the item_*s being positioned off center in game, makes a change having them sit where they should be.

The light attenuations in a drop-down menu and mouseover hints for _sunlight values in worldspawn definitely beats keeping an open text file of the light.exe -h output around.

What else is left to update or add to the definitions? 
it'd be things that I've missed or that I've decided not to add for various reasons. I've tried to strike a balance between completeness and clutter. I've also avoided keys that only exist in one tool or engine. 
Player's Width In Game 
If a player is on a walkway high above lava, and immediately in front of him is a laser trap (or a Drole firing whatever it is he fires), what are the critical dimensions to allow him to side-step the laser (or other nasty projectile) and not fall off the walkway.


what is the player's width and at what point will he topple?

is the weapon's collision detection based on the size of the laser model (or nail or rocket etc), or is it more to do with the bounding box of the player?

I am trying to work out the optimum width of the walkway to allow a side-step but with the proviso that it must be done carefully to avoid going over the edge. And it's not actually lava underneath so death will not be inevitable if the player goes too far and does fall off.

In experiments, I can go to the edge of a ledge and move sideways to the point where I expect to fall off but don't. Looking down, I am in mid-air. I don't want the player to have too much room but I want it to be only just achievable. That way death or injury is quite possible but not guaranteed.

Sounds awful, I know, but I am trying not to give too much away. 
the Q1 player bbox ( also the bbox for all small monsters e.g. scrag, knight...i.e. the second collision hull size ) is afaik 32x32x56. Could be a couple of units taller, not sure.
Because it's a box that slides around the map always oriented the same way, the player will not fall until the very edge of the bbox has passed beyond the edge of a surface beneath. So you can be standing with 31 units sticking out over thin air and you won't fall because 1 unit remains in contact with the walkway.
Just as a useful guide, textures that are 32x32 ( e.g. the E3 glowing rune plates, each of the chequer flagstones in the knave wad ) are the equivalent of the bottom of the bbox - what I refer to as 1 player footprint.
Projectiles, except in some very unusual cases perhaps, are points not volumes. Collision is calculated for a point hitting a volume. So as long as the projectile whooshes past even 1 unit away from the bbox it will miss, even if the polys of the projectile model in question ( rocket, drolebomb, vorepod ) pass through the bbox.

So, technically, you could build a very narrow beam - say 8 units wide, and that is fucking narrow - and as long as the incoming projectile was fired almost exactly parallel down the center line of the beam, the player could sidestep to hang over thin air by maybe 30 units without falling off and leaving a couple of units between their bbox and the projectile.
In practice, this would be essentially impossible to achieve. The determining factor here is not really the physical dimensions, but the movement. Try it and see - manuevering to an accuracy of anything under about 32 units is rather demanding in combat. 
Thanks for that. Now I understand - my 64 units is plenty generous enough then.

And I whistle while I work.... 
you can bunny zig-zag and use air control to stay over the void most of the time. ;) Ok, best not to design maps for that, but still, works vs vore balls on a beam. 
Quake Logo Shadowing 
There's A Room In The Sky 
made entirely out of SKY* textured brushes. Inside, some solids and a few powerful lights.

At least, that's one way I know of doing it. 
Actually it's not a room, just a single thick skybrush with the Q inside. I did the same in kdma, with a pentagram. Newer light compilers may deal with skybrush permeability differently though. 
That wouldn't work with my idea. See the light texes here?

I was gonna have light emit from inside them, essentially, so that even the little bits that make up the frame cast a shadow. At least that same idea with something more... I dunno. That's just an idea. 
the logo is placed above the sky texture, which is in this case a func_illusion.
the screenshot shows a picture with the func_illusion invissible because the viewer is in it.
standing on ground, it would look like:

has anyone yet a solution for my rats which got lost in a brush??? 
What kell said. See that floating brush in your second screenshot? Noclip inside there and see what you find. 
I Did Noclip 
And saw nothing. :| 
Can someone help MadFox as I do not quite understand his problem and would therefore benefit from knowing the answer - you know, reverse logic.

Besides which, I was thinking of using rats in my next level. 
It depends what engine you use. In a software engine the Q brushes are visible. In FitzQuake they're not. I assume this is related to the more efficient unseen face culling thing. But take our word for it, the brushes are there at least for the compiling of the map and therefore shadowcasting. 
I'm afraid I don't quite understand the rat problem either. Sounds like it might be to do with the position of the model relative to the entity origin, but I dunno. It may also be a qc thing, which ain't my field of expertise :P 
oops, yeah, i guess they're not actually visible in fitzquake, unless you set r_oldskyleaf to 1. 
Have you downloaded the rat model and .qc from somewhere or have you created them from scratch yourself? 
Too Many Light Styles On A Face... 
I have this really neat idea that I want to implement in my hangar:

as the bay doors close, there are 10 light entities that successively turn off. The 1st light turns off at 3 seconds (it's 2500 bright), the 2nd one turns off at 4 seconds (it's 2300 bright) and so on, for 10 lights that each decrement by 200. The effect would be vanishing light inside the hangar, since the doors are closing. While it works with smaller light values and less lights, I'm getting a bunch of:

WARNING: Too many light styles on a face
lightmap point near (-1032 -833 -152), tech04_8
light->origin (-2560 -1024 128)
WARNING: Too many light styles on a face
lightmap point near (-1102 -837 -175), crate1_top
light->origin (-2624 -1024 128)
WARNING: Too many light styles on a face
lightmap point near (-1102 -837 -175), crate1_top
light->origin (-2592 -1024 128)
WARNING: Too many light styles on a face
lightmap point near (-1102 -837 -175),

I guess I'm not surprised, but might there be any way of implementing my idea without error? It would be a dramatic effect I haven't seen used before. 
I made the rat.qc partly by observing the progs.dat from Malice, partly myself.
Just went on untill friqqc did.'t give errors.
Then Necros helped me with a part.

The model just sinks in the groundbrush, like

I first thought the rat.mdl wasn't well placed.
But I think it has something to do with the rat.qc
It also has a bite function, but apparently something in the rat.qc went wrong.

I placed it as a file, maybe somebody can take a look at it?

You can't have more than four light styles (including ambient) on each face. Too many switchable lights in one area saturates this very quickly. 
brighter lights reach farther, so they are more likely to overlap. 
Just An Idea... 
Do you know any QC? If so it could be easier for you to simply make a new light style which is a single light which starts off bright and gradually fades. 
No QC 
I have a grasp of programmming syntax and stuff carried over from some PHP'ing, but I'm too weak-minded and impatient to really pursue any coding, even QC (as easy as they say it is) 
Dodgy Rat 
I have had a quick look at this rat problem and can see that no matter how you place the rat, he always 'lands' in the map with his paws 8 units below the surface.

I have compared the rat.qc with the dog.qc but cannot see anything obvious (yeah, OK, dogs are bigger than rats), so my question is - what determines the position of the lowest point of the model?

This line

setsize (self, '0 -8 -8', '08 08 16');

can adjust the position but I can only get the rat to 'land' lower. What is the realtionship between the two Z vector values? Also, is there a relationship between these figures and the '$origin' value?

Like MadFox, I am also trying to learn QC.

As always, any help you can give will be appreciated.

Ah, hold on. I have just "aligned" the ents.qc
/*QUAKED monster_rat (1 0 0) (-8 -8 -24) (8 8 40) Ambush

the rat.qc entry
$origin 0 0 24

and the rat.qc entry
setsize (self, '-8 -8 -24', '08 08 40');

and the pretty little rat now sits on top of the floor correctly.

OK Madfox, all we've got to do now is figure out why the little bugger runs backwards and also why, when you shoot him, a corpse appears angled at 90 degrees and why the ghost of the rat continues to run backwards. But hey, we'll get there!! 
They Come With Dozens 
I just realized it had to do something with the placing of the rat.mdl
I lifted the rat.mdl with the Quark4.07 model editor, and now it is also on its feet!
I also turned all the frames 180 degrees, and now it is running good.

Great you found it that way Mike!
In the start rat.qc I changed

$frame squishb1

void() rat_stand1;


$frame squishb1

void() rat_stand1;
void() rat_run1;


You were right with the dog.qc
I was trying to compare something of the same origin. I know there were more tricks in the Malice convertion.
The rat could also jump and attack.
But I think that needs more knowhow of the Qc-options.
I always thought they just replaced the dog with the rat. But in Malice they come with dozens, without hitting the eddict-count! 
I tried your changes to the rat.qc, and you are right. Only I can't see the mouse walking.
But the model is then placed on the excact 0 grid of the ground brush.

I changed the rat.mdl in the download zip.
It now walks straight ahead, but there is always one I can't kill. Holy Mouse! 
double picture, the last one is ment
for seeing the change in height. 
Final Rat 
I think the rat.qc is better now.
They can bite too, only sound gets stuck.
Just 12 mouses, but they're hard to fight. 
Is the Malice QC source not available? I'm fairly sure that would be quite useful in this case :}

(I bet all the links to it would have gone dead years ago though :{ ) 
Cd Tracks 
Can I rip the CD tracks from the Quake1 CD and save them onto my hard drive and get the music in-game or do I always have to have the CD in the drive? If so, how? 
CD Tracks - Depends If You Like Darkplaces.... 
The more recent versions of darkplaces support replacement CD tracks for quake mods, by adding a file sound/cdtracks/trackxxx.wav or sound/cdtracks/trackxxx.ogg to your mod/base directory. xxx is the number of the track, so track004.wav would be the replacement for track 4.

However, if you
a) don't like darkplaces
b) don't like ogg
c) don't like huge .wav files that wipe out your disk space
then you're pretty much out of luck. I guess for the first one you could try to fiddle with the source code to add the relevant dpextention to your own favourite engine, but that's a lot of effort to save a bit of disk swapping. 
Thanks for the info. I am happy with .ogg, also happy with huge .wav files (I have obscene amounts of HD space) but unfortunately, FQ is my engine of choice.

Oh well, it seemed like a good idea at the time. 
Good To Watch Your Cheese Bowl, Necros 
I already search years ago for the Malice qstats. Only Rogue and Hipnotronics give their
SOA.qc and DOE.qc for free.

Could be illigaly of me distributing these rat.mdl! They belong to the Malice convertion,
which is: strictly commercial.

But I like to learn something from the qc programming. That's why I am glad I've got these rats running. I am searching for it a long time now.

Now I am so far I've got them running, there is one thing left.
When I use a Path_corner on them I get blacked out with a :

callo 1446 (?]
ai.qc : ai_run
rat.qc : rat_run1
monsters.qc walkmonster_start_go
(no function)
stack overflow
host error : program error
lol, of course, just start winamp on the background while playing?
alt-tab to switch songs if fitzquake doesn't support the mp3 menu (don't remember, probably not). 
Texture Problem 
I have some problems with light textures in my level. The textures look in-game like on the below pictures. They look better after brightening nearly lights, but I don't want too much light there. I have converted this texture with Texmex from ikbaseq3.wad. Maybe I have done it wrong. What do you think? 
Fullbright Colours 
The problem there seems to be that when you converted you used the full quake1 colour palette rather than using a palette which had the fullbright colours taken out.

I haven't used Texmex but have a look if it has a palette with a name suggesting it has no fullbright colours in it.

(In original software quake and later fixed versions of glquake, the last few colours in the Quake palette will always appear at full brightness regardless of the light level) 
TexMex And Fullbrights 
If it is a fullbrite issue then you can select the texture, right-click and choose Adjust Brightness, then click Remove Brites.

Don't forget to Save after you have finished adjusting the textures. 
if you make light textures (like a lamp) you actually DO want to have the a single fullbright color patch in the place where the lamp glass is. 
Water Lighting 
This reminds me... is there any way to turn off the "always-bright" factor of water, so that your lights will light only particular areas of the water? 
More QC Help Needed 
I want to have certain monsters 'see' further. I know I can change their range in ai.qc but this then affects all monsters, which I do not want.

Can someone point me in the general direction of the best way to achieve this - ideally by setting a flag on the individual monsters. I may give them a slightly different skin so could use "if skin = 5 then monster can see further" inside the particular monster .qc.

I am not yet clear about the relationship between the monster's own .qc and the ai.qc where the ranging seems to take place.

These particular monsters are to be used as covering fire to pin the player down whilst other closer monsters gang up on him/her. Of course, the better players will survive, and will eventualy get close enough to kill-off the long range slayers. Think of it like snipers shooting from a long way off.

Any suggestions? 
You have a valid point about fullbrights.

But I would note a conundrum about the use of fullbrights:

1. on light textures, fullbrights would spoil a switchable light as it would still be seen even when the light was off

2. many years ago (22Nov1998 to be precice, and some 35 years after the death of JFK, coincidence or what?) I incurred the wrath of Shambler (and him still a teenager) because I had used a fullbright texture on a shootable button. The button was in a dark area of the map but was clearly visible because of the fullbrights being used. Unless, of course, you were using GLQuake (and he was) in which case, fullbrights were not fullbright and therefore became effectively invisible.

So, I guess you pays your money and you takes your choice.

Now, who do you think killed JFK? 

To remove fullbrights from a Q1 texture in TexMex, go to View -> Preferences -> Workspace -> [Color Conversion] and uncheck Use Full Brites. Fullbright texels will be converted to other colors when the image is imported.
The Adjust Brightness -> Remove Brites function doesn't work properly afaik.




Not if you want a switchable light style associated with that texture e.g. turning the light off completely.


Lee Harvey Oswald 
I have two solutions for you, one of which I have actually tested.

The tested way:
Find the line that reads

r = range (client);

float() FindTarget =
and replace it with

if (self.classname == "monster_ogre")
r = longrange (client);
r = range (client);

You can use any test in the if statement to decide which function to use. The next thing to do is find the range function and, suprisingly, duplicate it and rename the copy to longrange. You can then change the ranges as you desire. As you probably know from you experiments, the last value is probably the one to change. Altering RANGE_MELEE and RANGE_MID will change how the monster attacks and cause odd stuff, but might be desirable.

This method is good if you only want two classes of monster vision. If you have lots of monsters for the second type of vision, but don't want to have a big, slow if statement in
FindTarget like:

if (self.classname == "monster_ogre"|self.classname == "monster_vore|self.classname == "monster_shambler...)

then add a line saying
self.lip = 1
on all the monsters that have this kind of vision, and check for self.lip in the added code.
(lip is a nice variable to use, as the original quake only uses it for lifts/doors. So you can use it on monsters without having to define a new variable, which wastes memory on every entity in the level)

If you want several monsters all with different vision, and you're sure that you only want to change the maximum viewing distance for each, there is another method. Don't make any of the changes in the first method. Instead, change the line in range from
if (r < 1000)
return RANGE_MID;

if (r < (1000 + self.lip))
return RANGE_MID;

Then set self.lip to how much further you want the monster to see, eg: self.lip = 500 would mean the monster sees you at 1500 units,
self.lip = -200 would mean it sees you at only 800 units away, not 1000.
You could have written
if (r < (self.lip))
return RANGE_MID;

Why do it the way I suggest above, and not this way? Because it means that you don't have to change anything for the rest of the monsters, self.lip defaults to 0 so they will default to a range of 1000. Be warned, a mapper could in fact set self.lip on the monsters that don't have a range specified, and it would be obeyed. To avoid this you can force self.lip = 0 in the spawn function of these monsters, but then you're back to lots of work modifying all the monsters.

Finally, note that no matter how negative you make self.lip you'll always have a spotting distance of 500 from RANGE_MID. You could complicate things by having RANGE_MID altered by self.lip in some way too, but this might cause odd behaviour. Since you're going for longer vision this probably doesn't matter, but you might want to consider it. Poke around in the AI.qc and fight.qc files to check what happens at RANGE_NEAR/RANGE_MID. You might find it useful to have these ranges extended somewhat, but probably not. 
Excellent Preach 
I have seen many a QC tutorial with less debt than what you provided. 
Thanks for this explanation - clear and concise. And you are right in that I do not want to affect the current monsters RANGE_NEAR and RANGE_MID settings. It's just the sniper effect that I'm after.

Kell: but what about the grassy knoll and the man seen running away. And what about the mafia who were clearly put-out by what JFK and his brother were doing? And what about the guy in Marseille? And what about Shambler, where was he at the time? 
Fullbright Buttons 
Mike: heh, I also incurred the wrath in my last speedmap because I did exactly the same thing with a fullbright button in a dark area. :) 
Info On Fullbrights - Thanks 
Hey. This helps a lot. Thank you all for such detailed information. 
Kell & Ankh 
I use TexMex 3.4 and unchecking Use Full Brites in Options doesn't work. I am not sure if it doesn't work at all or if it misses some conversions. However, doing the right-click thing I mentioned does work.

The first image is using Options with Use Full Brites checked. The second is with Use Full Brites unchecked. The third is Use Full Brites unchecked and then right-clicking on the texture and using Adjust Brightness/Remove Brites, which does the best job.

Images 1 and 2 are different, honest. 
Fulbrights And Knave.wad - Some Testing 
Yesterday I have done some tests with ktech_3 and ktech_4 textures from the knave.wad dedicated for quake1. There are always some fulbright pixels you can see in darkness. Don't know if it is intentional. I'm using Hammer,Joequake and aguirRe's tools. 
This is the same kind of thing as shown in my earlier post.

I have now cleared this particular texture of all fullbrights. You can see in the screenshot below that where the new texture is, the bright red pixels are gone - check the brick pier to the right of the shotgun (old version) and then the layer of bricks closest to the lava on the left of the shotgun(new version):-

I exported the individual texture from TexMex as a .bmp file, opened it in Grafixer, and immediately saved it without doing anything else. Then imported it back into TexMex and saved the .wad file.

I only wanted to get a little bit of colour on the bricks that were next to the lava. The two courses of bricks above the lava are the coloured version (minus fullbrights) and the third course of bricks is the uncoloured version of the same texture - they're from DktE3.wad.

Not too long-winded once you know what to do.
You'll find Grafixer here:-

Maybe someone knows any easier way? 
Qc Help 
Would you be so kind to look at my rat.qc and see why I can't lay a path_corner on them?
The download has the qc.script I tried sofar.
Could it be because it is an Add-on monster?

I've been looking all day, but I can't find the reason.
I finally got them ingame, but I can't see them jump, although I declared the options.
Also the damage impackt is far too high. 
Rat From A Sinking Ship.. 
Yeah, sure, either e-mail it to me or post a link here and I'll have a poke around. 
Just found a problem with Grafixer in that it only handles textures up to 320 x 200. Shame. 
Fullbrights Re-visited 
I have a sense of deja-vu here so if this is repeating myself, sorry.

TexMex has a problem removing colour 255. So, if after doing the above routine you still have a single fullbright (fuscia) you will need something like Photoshop to highlight the offending pixel and change it to another non-fullbright colour.

It is straightforward although long-winded but I don't know how else to do it. 
Hacky Way To Convert Textures 
You can use QME(yeah, the modelling program) to eliminate fullbrights at a pinch. Dunno if I'd want to do it on a large batch of textures though. Load up any model and change the skin size to the size of the texture. Import the texture, and go to view -> skin palette map editor. Then uncheck the last two rows of colours, and click ok. Finally, export the skin again, and it's done.

You can also use this to exclude other colour ranges, if the conversion uses a row of colours that look odd, like the grey/greens on a grey patch. It's also very handy if you're making a quake player model, since you can fix the shirt/pants colours easily with it. But yeah, fullbrights is the most useful thing it'll do. 
Great Preach! 
I posted a link above with the download zip.
It has a map, Qc, Sound and progs.
You even could game with it by what I sofar gained. Some functions won't work, like the bite distance is to far, as the damage is.

But when I try to put on a path_corner on it the game ceased as I mentioned in post 3713.
Maybe because it is not a monster replacement, but an add-on.

Here is the link once more: 
Basil The Rat(and A Few Further Things) 
The fix is pretty simple, the explanation a bit more involved. What you want to do is find the following code:

void() rat_run1 =[ $run1, rat_run2 ] {
if (random() < 0.2)
sound (self, CHAN_VOICE, "rat/eep1.wav", 1, ATTN_IDLE); ai_run(8);};
void() rat_run2 =[ $run2, rat_run3 ] {ai_run(8);};

and edit it to this:

void() rat_run1 =[ $run1, rat_run2 ] {
if (random() < 0.2)
sound (self, CHAN_VOICE, "rat/eep1.wav", 1, ATTN_IDLE); ai_walk(8);};
void() rat_run2 =[ $run2, rat_run3 ] {ai_walk(8);};

Why? Well, although these functions are called rat_run1 and rat_run2, they are actually the WALKING frames for the rat. You can see this by looking at
self.th_walk = rat_run1;
in the definition of monster_rat. And why does it matter? Well, ai_run assumes that the monster has a target, and so you get problems when that isn't the case. ai_walk is built for just one thing, and that's following path_corners.

A few other things that you might wanna look at which I noticed while testing. One is the hitbox you use. It's narrower than it is long, which would be a good fit for the model, except that hitboxes in quake don't rotate with the model. So it's always facing the same way, which makes it harder or easier to kill the rat depending on which direction you attack it from. It's hard to explain, but easy to see, get the latest fitzquake and set r_showboxes to 1, and then look at some rats with god or notarget, especially ones who are patrolling. The fix would be to set the size to something like

setsize (self, '-8 -8 -8', '8 8 16');

A further thing, the gibbing death you have in there is bugged. If you do enough damage to gib the rat, the gib gets thrown, but the rat doesn't get removed. So you get an invulnerable rat that continues attacking. Use ThrowHead instead of ThrowGib - ThrowGib creates a new entity for the gib, ThrowHead turns the monster into the gib. Or you might wanna just remove gibbing, it'd probably look better.

Finally, when your models are dying normally, not gibbed, they remain solid. Usually it's best to have make them non solid, change the last death frame to do that.

I wrote the above two paragraphs, then decided to try and test it. Looking more carefully, the whole death sequence is quite buggy. You have a loop where rat_die calls rat_die1, which calls rat_die again. This is why you get that repeated clicking sound from all the dead bodies. Rather than detail all the little fixes, here's what it should look like

void() rat_die1 =[ $squish1, rat_die1 ] {self.solid = SOLID_NOT;};

void() rat_die2 =[ $squishb1, rat_die2 ] {self.solid = SOLID_NOT;};

void() rat_die =
// check for gib
if ( < -15)
sound (self, CHAN_VOICE, "rat/squish.wav", 1, ATTN_NORM);
ThrowHead ("progs/h_gib1.mdl",;

//regular death
sound (self, CHAN_VOICE, "rat/squish.wav", 1, ATTN_NORM);
if (random() > 0.5)
rat_die2 ();
rat_die1 ();

Notice which functions are calling which other functions, rat_die calls one of the two frames, rat_die1 or rat_die2. The frames do not call rat_die again, they call themselves, because the monster no longer needs to animate - it's dead.

One tip for people in general, with a word of warning. If you want to test a new monster quickly without having to create a new level, you can cheat and have it replace an existing monster in all levels. To replace grunts with rats, comment out all the code in monster_army(), and add

self.classname = "monster_rat";

after the comment. The classname is very important, as if you don't do that the rats will be going around with monster_army as their classname. Some of the quake monsters have hacks in the AI based on their classname(knights are a good example of this), and so you might get odd behaviour that wouldn't occur with a custom map with rats in. It took me months to figure where that bug came from first time I met it... 
Thank you very much, Preach for your brilliant explanation of the qc periphericals!
I was looking to it so long now it realy became acracadabra to me.

I had changed something in the RatJumpTouch and then all my rats became earthbound, before they squished to the wall. Some of them kept flying at the skybrush.
It gave me the idea to make bats of them.

Now they're ok, and I can use them with a path_corner. I am very thankfull to you.

Last bugging question of me. How do I cange their damage. I changed ai_charge in the void rat_bite , but it doesn't change a thing. 
Damage Dealing 
The lines that do damage are

ldmg = (random() + random() + random()) * 8;
T_Damage (self.enemy, self, self, ldmg);

in rat_bite and much less frequently

ldmg = 10 + 10*random();
T_Damage (other, self, self, ldmg);

in Rat_JumpTouch. Since random produces a number between 0 and 1, the first expression can produce anything from 0 to 24 damage, but is much more likely to lie close to the centre, about 12 damage. The second is uniformly distributed between 10 and 20 damage. Reducing the numbers here is probably wise. You might also want to reduce the attack range, which is set at 100 in rat_bite in:

if (vlen(delta) > 100)

Because this range is measured between the origin of the player and the rat, you can make it smaller than, say, the same range for a knight, as the rat can get closer to the player with it'ssmaller bounding box. 70/80 would probably be good. 
Terrain Mapping 
Originally i had tried to just use straight vertex manipulation. This looked fine in-editor, but everything was hopelessly broken in-game. I then tried cutting my base structures into triangles before doing my vertex manipulation thing, and it ended up looking decent in-game.

Is this the right way to do it, or am i setting myself up for worse problems down the road? 
While time consuming, tris are the way to go. 
Thanks again Preach.

You helped me with a thing I was crunching for years with. So glad I found it yet!
Replacing monsters was a tough job, adding even more.

It helped me with understanding a little more
of the qc scripting, which in my opinion still
has something of pure magic. 
Clipping Hulls 
Is there any engine out there yet that lets you view the different hulls or is the "-hull #" option of aguire's qbsp the only option available? 
(Only implemented in the GL version) 
Thanks Tyrann 
I really miss fitzquake/q3 style movment in noclip mode though and I think the hulls would be better displayed as some kind of wireframe or semi-transparent representation. Shouldn't complain though since it is very usefull even as it is.

Now that I've seen the ones I felt and some additiional ones I just have to figure out how to get rid of the evil clipping problems... 
Glad my attempt, adding a monster, succeeded. 
Hickory, Dickory, Dock... 
Two things:-

1) the trap operates on its own once you have triggered it for the first time - about every 12 seconds. Is this intentional?

2) Huston, we have a dead mouse flying.

I shot this mouse and he flew up in the air and stayed there?

Other than that, they are good, nuisance monsters like spiders and vorlings. 
Fidler Of Hameln 
While the Quake engine can't collaps objects (in stead of the Custent) I made the trap like a func_train.
My idea was to hurt the rats, but as they have no pain-frames in it, that won't work.
The flying mouse you see, is one that has fallen on the trap itself. It isn't flying.

Took me some time to make them fall on ground the same way, as the h_gib1.mdl frame and the squish-frame in the rat.mdl aren't in the same position.
ThrowHead function make them land lower, reason why they just disapear.

Would like to make them jump and retreat. 
Q1 Console Gfx 
I looked inside GFX.wad and also the GFX folder of the PAK's and can't seem to find the big console graphic. Where be it? I saw one .LMP that might be it, but QPED said it wasn't viewable. 
It's Called 
conback.lmp and used to have a limit of about 64k in size, but some paks use larger and might cause some engines/tools to fail (or even crash) to load it. Carved in Flesh is such a pak. 
Thought So 
I found a tool called Adquedit and was able to extract it. So I'll have to keep it under 64k then? The original file is 55.9 KB. 
If You Want 
to avoid weird behaviour or even crashes in standard engines, you should keep it beneath 64k. There are also similar restrictions on skins and other texes (at least in GL-engines), but the limit is higher then.

In my next engine versions, I've added warnings when exceeding normal limits. 
Mini Chthon 
I wonder if anyone can point me in the right direction...

I remember seeing a mod where Chthon had been shrunk somewhat and could be killed with ordinary weapons. I am not sure if it was part of a larger map or was just an example map showing the mod.

I remember that there were two of these in little lava pools each side of a very small room and you could duck in and out of the room (it may have had a doorway at each end of the room) and lob grenades at them. The room was probably 1024 x 512, or at least that kind of proportion

I've Googled, Copernicked and even Asked Jeeves but only get referred to Chthon10 or Chthon! neither of which are what I am after.

Ring any bells with anyone? 
The mini-chthons in little lava tanks appeared in Mish Pak 2: DoE iirc 
Roger Bannister Eat Your Heart Out... 
Bugger me Kell, bit quicker next time please:-)

Thanks. However... I never bought DOE, so if that was it, it must have been released to the public OR someone used it in a map.

I have a lot of lava in my current map and thought that it could be a useful extra monster type? 
You can get the DoE QC source here: .

And the DoE map Kell refers to is probably Elemental Fury II (r2m3). 
Ogro Textures? 
Hello, It's my first post here... :)
I'm looking for the pak (zip) with all Ogro's textures but I can't find anymore. :(

the file on his site is down and I still don't had lucky.

can someone help me?

Ogro Textures 
Hope these are what you are looking for?

Try here

If you find files on PQ/fileplanet that seem to be missing/404. just add the following before the filename path,

for eg, the following link

would become

(func_msgboard will screw up the above example, but you should get the idea, hope so any way}

Not guaranteed to work on all occassions, but will for a lot. 
You Can Still... 
hover over the links to see what vorelord is talking about, though. 
And For The Life Of Me 
I don't know how I came to use 2 totally unrelated links in my example above, but I did, it of course should be,

If you find files on PQ/fileplanet that seem to be missing/404. just add the following before the filename path,

for eg, the following link

would become

// I'm going to go and have a lie down now 
Antilight Question 
I'm not yet really used with antilight use, so I would like to have a little bit informations.

I just would like to have confirmation that antilights are only lights with a negative value, or if there is something more in their description (additional field, etc...)

I also noticed that antilights didn't have effects on worldspawn minlight value, i.e it is impossible to have a zero light (like full dark) area around antilights... or do I missed something ?

Thanks in advance... 
antilight have the same keys as usual light, i.e. wait, etc (if u use aguirres light). and if i remember right it affects minlight turning everything to pitch black. 
Well, so it seems I set antilight fields correctly (i.e negative value, wait, delay, etc...) Maybe I need further tries to find the good use with the good effect..
Thank you Von' 
the only good use is to black out abysses like in numb nimbus level by czg. 
I would not like to be so "radical" ;) 
Antilights works basically like normal lights with all extra keys. But it can only affect light with the same style, e.g. you can't darken a flickering light with normal light (style 0). Also, you can't use antilight as ambient light, e.g. minlight.

In TyrLite (which I think you use) there are some other possibilities, e.g. you must add the option -nominlimit to make antilight force levels beneath ambient minlight.

Check readmes for more details. 
Thanks for the information, I will try it this evening: I now suppose this option was missing in my light process.. ;) 
Need Pointing In The Right Direction Again... 
/*QUAKED misc_fireball (0 .5 .8) (-8 -8 -8) (8 8 8)

Am I right in thinking that the second and third group in the above are the dimensional off-set from the origin of the entity based on the size of the model and that the bounding-box is therefore 16x16x16?

If not, what are they?
If my assumption is correct, is this how the entities origin is determined i.e. I could redifine the entities origin by altering the parameters to (say) (-8 -8 -12) (8 8 4) to have my origin higher up the model but still within a 16x16x16 bounding-box.

What is the first group relating to?

I have Googled but cannot find a decent definition of this anywhere (14000 entries offered, a couple of dozen checked, and then I thought that I would use my favourite search engine:-) 
Color Min Max 
These are all just fields to tell the QuakEd editor about the entity.
First group specifies it's color, the two following specifies the minimum and maximum bounds of the entity relative to it's origin.
This is just for the editor though, it won't have any effect on the actual in-game entity.
If you change the bounds, the box in the editor will appear to change, but the origin will still be in the same place. (Unless you move the entity, obviously, to acommodate for the change in the box.) 
Thanks. A couple more questions:

How does the Colour Group work - what are the three values telling the editor?

Also, if the other groups are there to tell the editor about the entity, how/where/why is the origin of an entity determined? I can see that the editor 'knows' the origin and passes this detail to the compile routines via the .map file, but this is only calculated from the *Quaked definition. So, is the origin only determined by the entry in the *Quaked definition and can I therefore change the origin simply by changing that definition?

I haven't a clue why I would want to do that but i am trying to understand the relationships between the editor and .map files, the .bsp file, the progs.dat and the engine. 
if you change the Mins and Maxs in qc, it would affect the collision of the entity against other entities, but not the model positioning (which is always centered on the origin, rather than centered in the bounding box. Back to the collision thing, it will affect its collision against other entities, but the collision against the world will always use one of three hard-coded sizes: zero-sized (0 0 0)(0 0 0), player-sized (-16 -16 --24)(16 16 32), or shambler-sized (-32 -32 -24)(32 32 64). 
Thanks for the explanation.

Is the world collision detection routine run three times, one for each of the hard-coded sizes, or does each entity have one of those fixed sizes 'allocated' to it somehow? (Of course, I don't actually know how collision detection is carried out as the game progresses - is it only after (or perhaps just before) each individual entity movement, or cyclical on every entity all the time or ???)

These questions have come to the fore because I have a model but no *Quaked definition. By trial and error I have created a bounding box and can fit it the map OK but do not know how to decide the origin for the entity: should I just use player-size or shambler-size according to the size of the model or is it a bit more complex than that? It is only a static model at present but if I ever get the hang of animation, it could become a 'monster'.

I notice that the Bounds dimensions shown for standard Quake models in QME 3.1 never match the *Quaked definitions - what am I missing?

Metlslime, do you map or do you just stick to programming?

Mmmm, a lot of questions again. Hopefully there are others who are as novice as I am and will learn from the answers as well. 
I can't answer you're more technical questions, but I can shed some light.

should I just use player-size or shambler-size according to the size of the model or is it a bit more complex than that?

In my earlier reply about the narrow beam, I was not entirely accurate when describing the player bbox. In fact, the player and monsters don't have a bounding box, they're just point entities that collide with the 'expanded into the map' hulls 1 or 2, which creates the illusion that they are in fact boxes.
This mechanism vastly simplifies the amount of information calculated for collision. The ( acceptable ) trade off is slightly longer compile times and larger file size of finished maps.

The other limitation however is that you can only have moving entities ( i.e. players and monsters ) that are the size associated with the collision hulls. In Q1 there are only two sizes: player and shambler. ( HL1 had more collision hulls afaik, allowing for a greater variety of monster sizes )

From my experience working with necros on monster creation, I believe that it's possible to specify the weapon collision box for a monster, which needn't be the same as the architectural hull1/2 box size. In the case of the vermis for example, because it doesn't move from it's location it only has one very wide and very tall box for calculating weapon hits, but no box specified for either hull 1 or 2.

For a regular monster that moves about and will bump into walls and stuff, you got player/knight/scrag size and ogre/fiend/shambler size. That's it.

I notice that the Bounds dimensions shown for standard Quake models in QME 3.1 never match the *Quaked definitions - what am I missing?

The information shown for model entity properties is not for collision, it's simply the maximum and minimum extents that the verts of the model occupy in any given frame and also over the course of all frames throughout its animations.
This is relevant because of the way the Q1 .mdl format saves the location of verts. Unfortunately, it is ( as Kinn helped me to crudely understand ) sort of a case of mdl being, like the Quake color palette, limited to 256. That is to say, the farthest distance apart the verts reach in any single animation frame is used to define the 'grid' into which all the other verts in all the other frames will be fitted. The max/min extents are divided into 256.
So for example, a monster with an insecty proboscis that it can shoot out of its mouth at the player a long way is going to have its front to back 'grid' stretched out because of the distance of the verts in that one animation frame. As a result, the rest of the verts will have to be fitted into the nearest grid locations along that length, giving rise to visible innaccuracies. In-game, this makes the verts wobble about a bit - it's called 'vert dancing' or the 'jello effect' for obvious and rather regrettable reasons.

Generally, the exact numbers are not of interest when modelling in .mdl format. Just try to keep the verts of your monster within a fairly defined space - don't have it reaching out to far in any direction in any frame. The more detailed the model - the finer the grain of the verts you've placed - the more of a problem vert dancing will become.

Metlslime, do you map or do you just stick to programming?

Metl has for some time been one of our community's illustrious professional devs. He used to map for Q1 and Q2. His first map was The Crawling Chaos, a nice bit of stygian horror. His most memorable map for Q1 was Rubicon, for which he also created a competition winning (?) texture set, still used for Q1 maps. One of the best base texture wads evar.
Rumours of Rubicon 2 are not baseless, but apocryphal or at least wildy innacurate.
He is a supremely talented bloke in all areas of game design, though he also suffers from an inexplicable aversion to bees.

Yeah i map, but i have a lot less time for it at home now that i do it as a profession. Since my homepage has been taken down temporarily, the only place to see screenshots and stuff is my portfolio, here:

Um and to answer your question, the choice of which of the three sizes to use for world collision (point-size, player-size, shambler-size) is based on the bounding box you specify in quakec. I don't know for sure if it rounds down, rounds up, or picks the closest of the three sizes. 
Setting Sounds 
I'm aware that you can set sounds by putting in a number in the entity's sound field (by turning off SmartEdit in Worldcraft, the name of the actual sound is referred numerically).

I'm basically looking for a list of available sounds and their corresponding numbers -- since I only get about 4 or 5 *named* sounds to choose from (or just 1, for func_train). 
Kell, Metlslime 
Thanks for all the pointers.

And here's a little story just to make all of those of you who know about these things smile knowingly: I just drifted around my MIP (map in progress) with r_showbboxes on to see what I could see, and came across a bbox where I knew there shouldn't be one. I thought it must be something I accidentaly duplicated and must be hidded in the brushwork.

So, into the editor and sniff around, moving brushes backwards, forwards, up and down, but no, I can't see anything. Back into the game and look again, and it's still there. I line it up in each plane and reference it to the nearest piece of architecture which, because it was a brick wall, enabled me to work out exactly where it should be in the map.

Back into the editor and I still can't see it. I then think that I will need to look in the .map file and look at the bboxes co-ordinates based on my lining it up in-game.

You're already there aren't you? Yes, it's 0,0,0. Oh, ha ha ha; how I laughed. Mmmm.

Still, that was a good way to waste a quarter of an hour whilst waiting to see if the Lions were going to pull a rabbit out of the hat. Fat chance - they didn't. 
Tex Scaling 
I read its a good idea to scale distant textures as in terrain textures, by 2x - so that there is um... less lightmap... er, whatever. Efficiency.

But is there any drawback to this? I know if you scale DOWN textures it's not a good idea for the engine, if done in large. 
Q1 Model Frames 
Can someone please explain a bit regarding Q1 model frames? I've noticed that pretty many paks seem to have problems with these; you'll get warnings about no such frame ....

I've tried using QuArK and repair the mdl files by just c'n'p frames, just like I do with missing skins and sometimes it works and sometimes it doesn't. The alleged missing frames are often way higher than the actual # frames in the mdl file.

I've managed to see that there seem to be at least two frame variants; single series frames and frame groups. This can often be seen in the mdl file as either one steady series of frame names (e.g. flame0-6) or several series which I assume are the frame group ones (e.g. fire0-6, firebig0-9).

The requested (and alledgely missing) frame in the engine seems reasonable when dealing with single series frames; then it's just a matter of c'n'p one or more frames to satisfy the request.

But when dealing with frame groups, the requested frame seems to be interpreted by the engine as the frame group and usually they're just a few.

If e.g. there was a request for frame 7 in the above frame group example, the engine will check against the # frame groups (here 2), warn about the missing frame, change it into group 0 and then proceed to render it (I assume the first frame of this group).

Is it possible that the requested frame should, at least when it's missing, instead be calculated from all of the frames in the mdl regardless of group, i.e. use the frame firebig0 as it's the eighth frame (index 7)? Does QC actually know about the frame groups?

And what are the poses, that seem to be some sublevel of frames? 
Model Frames And How QC Sees Them 
There are indeed two types of frame, grouped and non grouped. From the point of view of the QC, all of the frames in a framegroup count as one frame. Once this frame is set, the animation is out of the hands of the QC, it just plays at the speed set in the model until the QC sets a different frame.

As to whether the QC knows about the framegroups, the answer is maybe : - ). There are two ways to specify frames in QC. The first and simplest is by index, setting the frame of an entity to 5 will call the frame with index 5. This can be useful for cycling through an animation, by setting frame = frame + 1 at the right rate, for example in player.qc.

The second way is to use the frame names, but this only works some of the time. The QC files doubled up as control files for the model compiling tool ID wrote. If you look at the top of, say, ogre.qc you can see a load of lines about $origin and $base and $frame. All of this was information just for the model compiler, so altering it won't change anything if you recompile the QC files.

The use of it for the QC is the list of framenames. In ogre.qc, if you write self.frame = $stand1, the compiler will look up which index corresponds with $stand1 in the model header section, and replace $stand1 with the correct number. This is largely a readibility thing, but it also has the benefit that you cannot call a frame that does not exist, assuming the model you're using matches the frames in the header. If you tried to call $stand27, you'd get a compiler error.

The difficulty with calling the framenames is that different models often have the same names for frames, and rarely have the same index for that frame. The solution is that the framenames are only valid in the QC file that they are defined in. Since this would require a new QC file for each model you want to do this on, it's only really used for monsters and players. Most of the simple models are all defined together in models.qc, and any animation that they use is done directly with the frame indexes.

Which I'm afraid to say means I'm at a loss on how you'd call a framegroup using the framenames method in QC, as the only models ID made with framegroups are the torches, and they are defined in models.qc but coded for in misc.qc. Maybe I'll have an experiment and get back to you.

I was also under the impression that when you called the frames with numbers, all the numbers acted modulo the maximum frame index, so if the model had 6 frames, frame 6 would call frame 0, #7 called frame 1 again, and so on.

I now remember why I though this was how it worked - because of a server side mod I saw with optional client side models. The mod added lots of weapons to deathmatch, like pressing 4 twice gave you a flamethrower, that kind of thing. The trick was, if the nailgun v_model used frames 0-8, the flamethrower would use 9-17, and the next weapon 18-26. Then the client side models you could download would have a different model showing for those frames on the v_model. If you had the model pack, you'd see a different model for each weapon, but if you connected to the server without the pack you'd just see the nailgun each time, but it would still animate.

Do you have any examples of the paks that are causing these errors? I might be more helpful with a specific example than in general. It's possible that QuArK isn't reading the framegroups right, since it's designed to work with lots of model formats. Qme might be better for fixing those models.

Also, I've never heard of poses, unless it's the same as the base frame, used to generate the two sided planar map for the skin. Can't help you there... 
Hey Metlslime, is that realy the Floyd model in post #3792? Didn't knew it already excisted.

Here some screenies of my last model. Rather a heavy weight: 397 vertices - 1076 triangles.
Hard to find the vertices get messed by transposing them by dxf!
Only marginal textured. 
Thanks for the elaborate reply. From your answer, it seems as if there's no need to access specific frames within a frame group. This might explain why the engine uses the same parameter for either a specific frame in a single series variant or a specific group in a group variant. This seems to indicate that the current engine logic is still valid also for frame groups, so the real error is in fact the QC request (which anyway is the prime suspect).

I forgot before to ask about the frame names, but you brought it up anyway. As you say, the mdl frame names seem arbitrary and don't affect anything in the engine. This matches what I've seen in the code; the names are not used for identification, only the frame/group numbers are important. And the names used in QC source are only used there (i.e. by qcc).

I also know that QuArK is not the best tool here, but it has been sufficient before when repairing skins. As far as I can see, there's no indication at all in QuArK for the actual frame grouping, so I don't know if/how it reads/writes this info. At least it hasn't generated any obviously bad mdl files so far. Maybe it's using the names to generate grouping?

As for paks with these errors well, there are quite a few. The most recent one is the Chapters pak. Enable cvar developer 1 (should always be enabled when troubleshooting and IMO otherwise too) and load the map shamblertest. You will immediately get warnings from basically any engine with more or less helpful info.

With my current GLQuake beta, I get the warning R_SetupAliasFrame: no such frame 159 ('stand1', 94 frames) in progs/shambler.mdl. This tells me that it's a single series frame and requested frame index is way beyond the # frames available (94) in the shambler mdl.

Why such an excessive index is requested from QC, I don't know. A vague theory is that the shambler mdl is somehow mixed up with the drole (which has many more frames) and/or there's something fishy with the last teleporting shambler in this test map. It doesn't seem to happen in the actual pak maps so it's not a big problem here, just puzzling.

Otherwise, the pak I'm trying to fix right now is the old Abyss of Pandemonium. There are many problems here; get all weapons and try the new ones (6-9) out. You'll find that with at least three of them, there are frame errors. Use my latest engine to track models. There are also errors when breaking a glass window in aop1m4 to get a quad and when killing the Blud monster in aop1m6. Not to mention demos being royally screwed up ...

If you need more examples, just let me know.

The poses I mentioned before are variable names (firstpose, numposes) in the mdl/frame objects which I think are related to the modulo operation you mentioned; they're used together with a frame time interval. It's a bit confusing with the naming convention here; group vs frame vs pose ... 
I noticed a complimentary problem in the Xmen TC, with the quakec calling skin numbers that don't exist. In glquake this caused a white skin IIRC, but in software quake it just stayed on whatever previous skin it was using. I believe i changed fitzquake to emulate software quake in this case, except with a warning message. 
Yeah, that's Floyd. He's already animated, walks around, shoots people, and dies. I regret not modelling the gun muzzles, but at this point i am loathe to touch qME again after using real modelling tools. So i'll probably use him as is. 
Yes, the original GLQ had bad handling of missing skins; it displayed them in some psychedelic colours. I also just copied WQ handling (reset skin to 0) and added a warning. A lot of paks have skin problems too, e.g. the original Source of Power.

Often the pak author added new skins to the main mdl, but completely forgot about the corresponding h_* mdl (gibbed head). Gibbing a Custents' baby shambler could e.g. cause an engine crash. 
Is there a way to make a trigger_multiple be triggerable by monsters? 
If you mean 'by walking into it' then no, not in default id progs. Only by monster death -> target -> targetname.
With custom qc, probably. Monsters certainly can use trigger_teleports, so presumably a custom trigger can be created that allows monsters to affect it. Preach would be able to answer that question. 
Phait Re: Tex Scaling 
Overscaling textures does not, in my experience and as far as I know, have any negative effects on either the map or the engine. It's purely a matter of aesthetics. 
I have a door that, for various reasons, needs to be triggered by a custom-sized trigger_multiple. It looks strange when monsters can't open it, but other strange things happen if it's opened like a normal door.

Oh well, I guess I'll live with it one way or the other. 
Finger On The Trigger_multiple 
If you want to use custom QC, it's a pretty easy fix. The function you want is
void() multi_touch
in triggers.qc, and you'll spot right at the start the function says

if (other.classname != "player")

This, of course, locks out anything that isn't a player, so we want to change that. If you want it so that every trigger_multiple can be affected by every monster on the map, you could replace that line with

if (other.classname != "player" && !(other.flags & FL_MONSTER))

If you don't want a global change, just the option to toggle it, then you'll want to do this.

if (other.classname != "player" && (!(other.flags & FL_MONSTER)||( == 0)))

Then set the style of the triggers you want to be monster usable to 1, and leave the others with style 0. 
Thanks for your comment. Unfortunately, I would really prefer to stick with default Quake progs. Thanks anyway, though. :) 
...finally tracked him down 
Levitating Monster? 
Is there any such QC I might be able to implement to levitate a monster?

I figured I could take a crucified zombie and have it follow path_corner - but it didn't move. I figured I could place a func_door, plat or train beneath it and it'd push the zombie up -- nope.

My only other option is to make the zombie out of brushes and apply it's texture, then make that a func_whatever - which I'm going to try. 
Floating Monsters 
How active do you need the monster to be? If it's just a matter of having a crucified zombie follow a path/float up and down a bit, that's quite simple. If you want to make a monster that works completely, attacks and dies and stuff, while levitating, that's a much bigger change(you'd probably have to make it a full blown flyer like a scrag is). 
Floating Zombie 
Just a simple levitation - 2 paths for it to rise up and down to "hover" from, and a speed I can set. 
"Error 40: Portal Not Bounding Leaf" 
I am having some problem with my map, qbsp.exe crashes with an "Error 40: Portal not bounding leaf" error. What could be causing this? 
I Don't Think 
I've ever seen that error before. It happens during generation of the prt file.

Please send me the zipped map+wad and I'll see if I can at least add more info to the message. 
QME Full 
Does anyone have a working link to this? The previously mentioned Edgefile link doesn't seem to work (Invalid URL request). 
Try this:-

The .zip has a patch file to take the Lite version to the retail 3.1 version. I have this and there is no restriction on the number of frames it can handle.

It is now free, not warez. 
I already tried that file, but it didn't seem to work with the Lite version. However, I finally managed to find the full 3.0 via Google's cache of Edgefile. Now I could patch the 3.0 to 3.1 and all seems good. 
Weird, I have removed some complex structures and the error vanished. 
Trigger A Trigger 
I have a platform that won't be useable until the power is turned on to full. It's actually a func_door, and I have a trigger_once inside the plat cage that will start the plat only when the player is inside it.

I was wondering if theres anyway to, once the power is on (a func_button or something) - it will make that trigger_once valid - but until then, it wouldn't work.

Otherwise I'll just have to make a func_door in front of the plat that will be open once the power is turned on. 
what bsp, light and vis compilers are the beautiful people using nowadays? 

Compile utilities from Aguire aka Bengt Jardrup. 
muchas gracias. may your camel never stumble or fall. 
Other Things 
I've been searching around a few editing sites and can't find the answer.

1.) -- How do you switch a texture upon trigger? I have a set of lights that turn off, one by one (player passes through several trigger_once brushes), I'd like the light fixture's texture to switch to the less-bright light texture, once that particular light is switched off.

2.) -- Where/how might you edit the end episode text, or add such a thing to the last of a set of maps? 
1.) The brush with the texture you want to change must be a func_wall, the texture name must start with +#, where # is either a number or a letter. The texture will animate in sequence of the numbers/letters, and when the entity it is applied to, it will toggle between animating the letter sequence, or the number sequence. In your example, you'd need a texture called +0light_whatever for the on texture, and +alight_whatever for the off texture. Put the +0.. texture on a func_wall, and target the func_wall to toggle the texture on/off.

2.) Changing the text must be done in the progs.dat. Check out client.qc line 162 and onwards. There are if/then/else statements for the various endlevels there that print out the text. You can add your own text there. 
Thanks, works wonderfully. 
Logic Gates And Powered Lifts 
There is a way to have the lift inactive until you power it on with a button in standard quake, but it's the mother of all hacks. It involves constructing a 'logic gate', which is a trap_spikeshooter aimed at a trigger_multiple with health. In between there are a set of doors that block the shot when they are closed, and let it passed when open.

Toggling these doors open and firing the spikeshooter activates the trigger at the end. That description is a bit vague, but no matter, because I have an example map! Download it from , it shows how the logic gate works much better than my explanation could.
Try the lift before you press the button, then afterwards, to check it works right.

Also, I haven't forgotten about the floating zombie, but it's a little more involved than I thought. The func_plat uses the think functions to control it's movement, but monsters already hold the monopoly on think functions for their animations. It would be a simple hack added to the func_plat if you were willing to add an extra animation sequence to the zombie model, with the crucified animation in a framegroup - similar to the way torches animate even though they are static entities. Would that be a workable solution? 
I don't mind mucking around with the zombie model as long as I know what I'm doing ;)

I figured you could take the ability of other monsters to follow paths, and apply it to the crucified zombie as well.

Also your logic gate idea is kinda clever and interesting. I pretty much understood it from how you wrote it, but I'll give the example a look.

Appreciate the help! 
This is weird. I have a func_door with the name of plat1. I have a brush in front of it that is a gate, which is also a func_door with the name of gate1.

I have a trigger_once that is to trigger gate1 - which it does, but for some reason it triggers plat1 too! 
Apparently you have to check DON'T LINK - if the 2 func_doors are right against eachother. I still don't know why they would let 2 funcs_ that meet, to trigger eachother. 
It's Because Of 
Doors linking together so you'll only need one key to open a set of double doors, and possibly other reasons too. 
Hl Textures 
I'm messing around with HL textures in quake - I know some people will think thats sacrilige, but whatever...
Anyways, I have 2 questions

1) how could I darken the whole wad file in tex mex?
2) how do you get rid of the fullbright spots on some textures?
thanks alot. 
Some questions for ya :)

1.) Fastvis -- if I use this in a map that doesn't have cavernous areas, but maybe a moderate corridor or 2, might any software Quake users have grey-out issues? Also, I read somewhere through here I believe you recommended somebody use the parameters -fast -level 4 -- is that right? Or is -level 4 actually -full?

2.) Faces... heres what my process window reads:

9801 faces
1607 brushes
219 entities

I am apparently near my limit of entities (255 or 256). Um but generally, I have little details in the map - like floor trim, and inset lights and such, which will contribute to any VIS concern, regarding too many faces (as I read brush count isn't really the issue). Basically I am wondering, when might I want to start worrying about too many faces?

3.) Light -gate 1 -- I've read changing the gate can help issues with too many dynamic lights in one area or proximity. I have several warnings of "Too many light styles on a face" which I could fix manually if it gets excessive... will this just print to the player's console, and not crash the engine (software)?

Overall I am trying to be a little considerate of software users, as few as their may be. When I release all this I'm recommending Fitzquake though.

2) how do you get rid of the fullbright spots on some textures?
thanks alot.

Select a texture, right click and choose "Brightness", then click "Remove Brites". 
1. Software greyflash appears because there are too many things in view for the engine's default values of the cvars r_maxedges and r_maxsurfs. Doing only a fastvis just increases this risk. Level 4 vis is what's usually considered a fullvis and you either use -fast or -level 4, not both.

2. I don't know why you think you're close to the edge with any of those values, but I can't see any obvious problems. Faces are a concern for vis, but it's better to look at the vis leafs/portals values for hints. Entity limits are usually much higher than your values if not each entity is unique, i.e. has its own model.

For comparison, Lun's recent huge lunsp1 has 2275 entities and 20900 faces. I don't think you'll have to worry too much about entity/face limits yet and when you do, you'll probably hit the edict/portal/packet limits instead.

3. The Fade Gate in Light is mainly for cutting processing time significantly with basically no losses. It has cut times by up to 93%, but typically around 50-75%.

The problem you mention is a basic limit of the Q1 switchable light styles; you can't have more than four on each face, including ambient light. You'll have to reduce the overlapping of switchables.

This can be done by e.g. brushes, linear attenuation or spotlight cone. Disregarding this issue will in the engine just cause bad lighting (depends on switchables setup) in that area, nothing else.

To help software (i.e. WinQuake) players, just follow the classic rules for good Q1 maps. Many limits are basically the same in most engines, soft or GL. Greyflash can be fixed by just increasing the cvars r_maxedges/r_maxsurfs to 99999 e.g. in the autoexec.cfg.

In my WinQuake (and other engines), most limits are raised so it's more of a performance issue, e.g. having 2000 shamblers attacking you in one big room will probably be a slide show ...

Maybe the easiest rule is to make full builds of your map now and then, check the logs for errors/warnings and make sure it's loadable/playable in the target engine(s). This way you'll catch problems early on. 
don't release a map that's only fastvis:ed or the mapping gods will eat you alive 
And cyBeAr -- well, I certainly hope I don't come across a VIS that takes days or weeks, mostly because theres only one computer and I'm not the only one that uses it - and also, no feckin' way am I waiting that long.