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
How does it look just with -extra (not 4)? 
That looks like a fog error, doesn't it? I can't imagine that has anything to do with his lightmaps. 
Shots taken in the same session or different sessions?

If different, launched with the same shortcut or batch file, or different shortcuts/batch files? 
That's probably gamma or brightness or something like that. Both look terrible on my night time red tint and 0.8 monitor gamma setup. If I disable that, the first one is find. 
it really does look like 32bpp vs. 16bpp to me. Even the down to the discoloration on the statusbar graphics in fitz0001 
I See 
A similar thing when using the SetGamma utility - which I use so that the worldcraft 3d window isn't too dark. 
Not the same session of FZ. Because I was running from batch files, I closed the FZ session between maps.

You might be pointing me in the right direction: I will now go and check the two batch files for differences in calling the -game and -map. 
There Was I, Diggin' This 'ole 
From the config file:-

vid_bpp "32"
vid_fullscreen "1"
vid_height "768"
vid_refreshrate "60"
vid_vsync "0"
vid_width "1024"
viewsize "100.000000"
volume "0.7"

However, one of the batch files has -bpp 32 in the command line it produces, and the other does not.

If I run the maps from the same FZ session using the command line with the -bpp 32, NO BANDING!

Is it correct that the config file does not take precedence over the command line? And is it correct that with no -bpp 32 in the command line, the entry in the config file is ignored?

And I suppose the default -bpp is 16? 
default bpp is 16, yes (glquake legacy, probably should default to 32 now)

if any video options are on the command line (-window, -width, -height, -bpp, -refreshrate) then the config file is ignored and the command line settings are used.

Otherwise it should use the config file during startup.

You can always verify by looking at the console for something like "video mode 1024x768x32 60Hz initialized" 
Eeeee Eee Eee The Martian Hop 
Got there in the end. Thanks.

But now the end is near and so I face the final curtain...

Stand by onetruepurple, it's on its way of that I'm certain (well give me a day or so to recover from this trauma) 
Try Making... 
an autoexec.cfg file for your settings so it always uses the settings you want. (I don't know why it doesn't always save) 
Does anyone know why some editors have different texture projection axes which made it necessary to have -altaxis/-oldaxis on QBSP? Was it just a mistake or was there some reason for it? 
From Bengt 
Note : TreeQBSP behaves slightly different than other QBSP variants. To make it behave more like
the others, the following command line can be used :

qbsp -oldaxis -oldleak [mapname]

In most cases, the new style leak line (default) is considerably easier to follow in Quake,
but if it doesn't seem correct (e.g. the line goes right through solid brushes) you might
want to try the old style line. You can always use the "-leakdist #" option to reduce the
amount of dots in pointfiles. If Quake cannot load the entire pointfile, use the Quake
command line option "-particles #" to increase the capacity.

Also, transparent water is not default (like in TxQBSP), but can be enabled via the
"-transwater" option. Beware of the performance hit in some maps.

Some lighting problems might occur when using most light tools together with a compiler
that supports enhanced texture positioning (e.g. QuArK ETP or Valve 220 Hammer). Light 1.27
and TyrLite 0.94 (see Tyrann's site below) or later versions support ETP. 
I'm not sure about this, but I suppose it was a programming error on some editor. The algorithms for both variants are exactly the same except for a < in one and a <= in the other. This is TB's implementation which is basically the same as the one in the compilers and in Radiant:

unsigned int bestIndex = 0;
float bestDot = 0.0f;
for (unsigned int i = 0; i < 6; i++) {
float dot =*BaseAxes[i * 3]);
// no need to use -altaxis for qbsp
if (dot > bestDot) {
bestDot = dot;
bestIndex = i;

BaseAxes is an array of 3-tuples of vectors. This is the version to use without -altaxis/-oldaxis. The other version has dot <= bestDot. 
So it looks like the original treeqbsp had the 'wrong' projection code as well? Or the creator used an editor with the wrong projection and thought it was the correct on..? 
Angle On A Trigger 
I've just noticed that one of my trigger_once has an 'angle' set to '-2'. This has crept in somehow but is entirely wrong.

The effect is that the player does not seem to activate the trigger without "wiggling" at the place where the trigger is sited, and it will not be obvious to the player that a wiggle is needed.

Can I remove this field directly from the .bsp file - I do not want to remove the trigger? I seem to remember that you can edit the bsp provided that... you don't alter the file length, or something like that?

The player does not actually pass through the trigger, they simply touch the trigger (it's against a wall).

I can change it in the editor of course but this is the level that took a gazillion hours to compile so I am trying not to compile again. 
Mike Woodham 
You can remove the field and then run qbsp with the -onlyents commandline. 
I don't know who started this, but I suppose that some editor got it wrong and the original author of Tree tried to fix it. Or maybe he just got it wrong. It's super annoying, though. 
Remember to run light -onlyents as well if you have switchable lights in the map. 
Wow, now I understand why when I did onlyent compiles all the lights were screwed. Awesome tip, should be in quake wiki! :D 
Qbsp And Vis 
I thought qbsp ran on the map file, and output a bsp file that you then had to run vis on to optimise visuals.

If I run -onlyents on the modified map file don't I end up with a bsp that still requires vis to be run on it? (That's why I was hoping that I could just manually modify the entity in the bsp file and leave all the compiled visual stuff alone.) 
No, because the entity lump is seperate from the BSP lump. It can update the entity keys/values without throwing away the BSP info. 
Did It Anyway 
I found the entry in the bsp file, changed the '-2' to '00', saved it and ended up with the same file length. Ran it and it worked, so I guess the answer is that you can. 
I am clearly not understanding how this all works.

qbsp: takes a map file and turns it into a bsp file?
light: takes a bsp file and applies the lighting as defined in the entity list saved within the bsp file?
vis: takes an existing bsp file outputs a visually optimised version of the bsp file? 
yes, but each of those compilers puts their data into different parts of the bsp, so when you do -onlyents on qbsp, you're telling it to only update the entity list and not touch the lighting or vis.
and when you do -onlyents on light, you're telling light to only redo the lighting on switchable lights and update their connections with the entity list. 
The vis data is a separate part of the file, like the light data.

You can replace the vis data, just the same as you can replace the light data.

The vis data does not modify the BSP tree.

Or am I wrong? 
Input Or Output? 
Does that mean when I run qbsp with -onlyents, it isn't outputing a NEW bsp file, it is only updating an existing bsp file with the revised entity data?

Is there anything wrong with the way I did it, which was to directly edit the bsp file? Admitedly, the 'angle' field is still there but is now contains a zero value, which seems to have solved the "wiggle" problem straight away. 
Does that mean when I run qbsp with -onlyents, it isn't outputing a NEW bsp file, it is only updating an existing bsp file with the revised entity data?
Is there anything wrong with the way I did it, which was to directly edit the bsp file? Admitedly, the 'angle' field is still there but is now contains a zero value, which seems to have solved the "wiggle" problem straight away.
There's nothing wrong with that, it's just more work. 
also, btw, when you put an angle onto a trigger, it makes it so the player has to be facing 90 degrees to that trigger, so the wiggle is really just you accidentally pointing slightly downwards so that it was less than 90 degrees from the straight down angle and the trigger would fire. 
I Have Seen The Light And It Is A Wondrous Thing 
Thanks necros, now I've got it and your last comment is the last piece of what was puzzling me: I didn't even realise that triggers could angles. 
Map Optimisation... 
Are there any good guides around for optimising a map? My Deck remake is fairly detailed, maybe too detailed(!)... I'd rather optimise it than to start chopping detail down.
UT had occlusion brushes and such, will using skip textures on the void-facing brushes make a difference (is this what you're supposed to do??)... 
WC 1.6b 
Anyone got a copy? The link up-thread is dead. 
func_detail entities should help. As for optimizing the map itself ... is it actually slow? It's hard to make a machine run slow with Quake these days. 
It's hard to make a machine run slow with Quake these days.

It really isn't. 
Combining Lightmaps? 
Is there a way to add up 2 .lit files?

I've been playing around with Q1Rad a little and I like the area lights and indirect shadowing it gives.

I've got a light_environment for the sky and light emitting slime as ambient lightsources but I wonder if these can combined with lightmaps from Bengt's light tool for the pointlights?
I like the idea of having bounced area lights to supplement the crisper lighting from pointlights. 
Willem, Otp... 
maybe it's my machine? I find I have to tweak settings a bit on some of the newer custom maps. I've started using RMQ as my main engine a lot of the time because it usually always gives me a solid framerate (plus I love them coloured coronas) 
Not that I aware of. Lit files only hold colour data, btw.

think it might he cool to bring back radiosity lighting for quake, but in a more controlled and sutble way... 
It really isn't.
Maybe you need a better machine. :) I have yet to see a Quake level that gets my machine above "bored". 
Maybe you need a better machine. :)

You try playtesting somebody's 100+ monsters map without a fullvis and come back. But eat a bowl of dicks with deqer first. 
That may as well be just luck. Some Quake engines are not as optimized as others, and then performance depends completely on the driver. For example, I got severe slowdowns on my 2012 iMac before I patched QuakeSpasm to use a different texture and lightmap format. 
Wasn't trying to offend, otp, just fooling around. My machine IS a beast though. 
The Quake engine scales differently than modern game engines. So a large map can indeed make even a fast computer choke. Like Sleepy says, some ports handle it better than others (RMQ and DirectQ come to mind). For example, the unvised version of Tronyn's latest map ran quite poorly on my machine, at least initially, and it's by no means a slow computer.

And this is only about polys. If you take additional features into account, replacement graphics and real-time lighting, it's actually fairly easy to make the game run slow. 
I'm not aware of any distinct guides. There's always room for optimization. Func_detail won't help here, it only makes the vis complete faster. It's sometimes possible to bring down the wpoly count by turning certain things into func_walls and illusionaries or move touching brushes apart. This requires experimenting, however, as it can well turn out to be counterproductive. Check the map with r_showtris and r_drawflat to search for and investigate locations where unnecessary brush face splitting can be avoided. 
I Think.. 
part of the problem is due to Deck being simply a big atrium, plus the detail I've put into it also.

I can't seem to get r_drawflat to work, I think it's due to there still being a giant hole where I haven't made the ceiling work.

Am I supposed to use skip textures on the void-facing polys? (haven't done that yet either if you are) 
Void facing "Polys" (I assume that you mean the faces of brushes that are touching the void here) are ignored however putting a skip texture on them would probably confuse the bejesus out of any bsp compiler.

You might be able to make a big "Curtain" of additional skip brushes that occlude the faces facing inwards. I don't know if that's going to help or hurt you though. 
Re: Giant Hole & Void-facing Ploys 
Once you fill that hole, the compiler will automatically remove all void-facing ploys. This will cut your r_speeds in half, probably. So basically you can't accurately gauge performance until the hole is filled. 
skip on 'void facing' polys will not cause problems, but it unnecessary from a technical standpoint. (some people do that because it's clearer to look at).
The reason is that the compiler completely removes all faces on the outside of the map before the skip removal process runs. 
That makes sense. I wasn't aware of the order of the steps that qbsp does things. I do know that with other "Special" textures that mixing some of them with others on the same brush can be a bad idea. I was just extrapolating from that. 
skip was actually added into the whole compilation process much later on. it's a separate utility that runs after qbsp. 
I've only messed with it once so I'm pretty clueless on using hint and skip outside of knowing what it does in a very basic sense. I was fiddling around with it and made a Quake shadow like you can see in e1m3 (I think) using nothing but a skip texture and func_detail. The func detail made the shadow and then the skip texture made the brushes that cast the shadow invisible.

The latest tools (Tyranns anyway) have skip support built into them so no need for a separate step. 
Map Error 
I'm at the point now where I'm making the level air-tight so I can start testing some stuff (it's not 100% yet but it IS around 99% complete in terms of geometry).

The compiling error I get is in the pastebin -

The only problem is when I look up the the co-ordinates of the error message it's actually pointing to a light entity and not a brush!?

Can lights cause leaks?? 
QBSP doesn't pinpoint the leak precisely, only the point entity closest to it. You can load the pointfile (.pts) in TB or put it in the maps dir and type pointfile in the console, both of which will display a line that leads from that entity to the leak (=where it goes outside the map).

Note that a "leak" doesn't always have to be a hole in the brushwork, it can also be caused by point ents that are placed on the outside. 
How Deep The Rabbit Hole Goes... 
Well, I've got some wondrous screenshots here... - showtris 0 - showtris 1

I looked at the pointfile and I ran around the map looking for some clue, nothing. Then I typed r_showtris 1 and I found a massive line that is so far away from my actual map that when I try to fly towards it I get "teleported" back to where I started.

I thought maybe the entity was so far away that I would never find it, so I created a selection brush around the whole map and "locked" it, then did a ctrl + a & delete to see if I could delete it that way, no luck though...

Any ideas? 
Which lightmap/texture format was the problem and which one did you patch it to use? 
It Was GL_RGB 
And I patched it to use GL_BGRA. GL_RGBA is fine, too. 
That's likely a microleak. It's a tiny rift between two brushes that only qbsp can see. This is a result of TB being shit - sorry. I'm working on a fix for such problems. 
Select the brushes where the line passes through and snap their vertices. That might fix the problem. Also note that you can import the point file into TB. See the docs. 
I tried to load the pointfile into trenchbroom but the whole map goes black and all I can see is a very very tiny line that goes on forever, when I try to "unload" the pointfile it doesn't work. It stays black. 
Untill you find the leak you can just box the map and use fastvis. 
btw sleepy: this is likely because my videocard is shit, but if I load point file, it blacks out my 3d view except for 2 yellow lines and I have to load a new map to get it back. 
Thanks, will keep that in mind for TyrQuake.

Hopefully will get a chance to help out with TB a bit more soon! 
When you load a point file, the camera snaps to the start of the line, maybe that's why it looks black? 
Different Tactic 
Ok, so I decided to load up my map in the latest trenchbroom build (was running version 1) and obviously it said there was a bunch of mishapen brushes etc so I rebuilt them or tidied them up. Did a whole bunch of messing about with stuff, removed the slime (I know it's a portal and I was getting some weird portal messages) and I managed to get it to compile. But it still wont vis...
Here's the pastebin - 
Have You Tried TreeQ? 
It should give the line # in the .map file where the error resides. So you can just go into a code editor and delete the faulty brush. 
Or You Could Just Run A Search For Those Values... 
you could have provided a link! :P

I found it anyway, managed to plug about 3 holes by setting it to -noents (this has required some serious google research!!) and I reckon there is a whole lot more.
One of the biggest headaches is I found a bunch of curved walls that I have made where I can shoot rockets clean through the wall, in the editor the vertices look perfect.

Oh and my lovely tri-soup rock terrain is also showing up as leaky (after I fixed a bunch of brushes I noticed the leaks were gone but now I can fall through some of the faces, it's like I fix one problem and it creates another!) 
Why not help others by adding to the Quake Wiki with your new found solutions to a problem that you encountered? Your progress with dealing with various issues is exactly what it's meant for. Be verbose and complete. If needed the issue will be boiled down and answers given in following edits. 
This is very likely my fault. It's a bit too complicated to explain right now, but basically, I thought I could get away with how I am treating vertices and plane points. I did a bit of cheating to make the vertex editing in TB easier, but I recently realized that it's not a good idea.

So I have been working on fixing these problems for the last two weeks, but sadly, this whole issue is just a rats nest of more problems. It'll take a bit longer - sorry. 
Some of these problems are definitely my fault, I had left a few holes around but since I am using a generic brown texture on the brushes in these areas I have made it very difficult to spot.
The solution in this instance may be to use a bright pink texture for all my brushes and then just texture the surface on the inside of the map (should make it easier).
As for the vertex problem, are the vertexes handled any differently in version 1 than version 1.05 (ver188)?

quaketree, I have intended on doing a bunch of professional videos for trenchbroom and a lot of plans were made and I sat down with the guy doing the recording/editing and it looked good but we supposed to record the first few tutorials this week and it just never happened.
Starting to think it may never happen. 
The More I Fix... 
the more it breaks... Ok I thought that cleaning up the map I made in TB v1.0 using TB v1.05 would provide some kind of solution. But the more I fix the tri-soup the bigger and more numerous the holes become. I might go back to TB v1.0 and clean up the holes there instead.
It's becoming an issue to an extent where I may just release a buggy .bsp file and the .map src for people to mess around with.

SleepwalkR, I love the editor and I hope you manage to fix whatever the problem is. The real concern for me now is I may have to resort to Worldcraft again until it's fixed, which I really *dont* want to do. 
Tb is not magic, so the limitations of the map file format still apply. It would be interesting if you could post the map file and let me know which brushes are problematic. Then I can see where it's going wrong.

Vertex handling is different in 1.0.5, it will mask less errors. But it still suffers from problems related to floating point coordinates one the map file.

I would generally suggest to always seal your map even if it's work in progress. That way you'll see immediately if something breaks instead of getting overwhelmed by a sea of errors. 
But I Thought It *was* Magic! 
No that's understandable and to be honest this was a test/learning map that got out of hand and became a real map. I think my best option may be to remove all the fancy terrain style geometry (and box it up), and then fill all the normal leaks first. And *then* I can retry making that geometry with a more robust approach (or even starting that part from scratch in 1.05). Basically I thought I was pretty much done with map but it looks like we have to spend a little more time together before we move on. 
did you mean to say mask or make? 
TrenchBroom generally tries to hide the fact that vertices often don't have integer coordinates, but that approach is flawed and I'm working on removing it. 
Elusive Brush Corruption 
I noticed stuff like tetrahedrons or brushes with a lot of vertices lend themselves well to map corruption in TB. For rocks or terrain just mashing deformed cubes together is more work but seems more stable at the moment. 
my terrain is completely cube-based. I didn't consider making it any other way.

A lot of the problems have come from my work method of basically making the level in an open room-by-room fashion. I could have avoided a lot of problems if I had blocked the layout first and then added all the details second. Maybe... I dunno, I'm still learning. 
Maybe Necros Could Chime In 
He has the most experience with mapping with TB. 
State Of The Map... 
Ok, I chopped out *all* the terrain brushes, blocked in those areas to stop them leaking, fixed all the pointfile problems and got a build that vis'd... I have a couple of HOM's (that don't leak for some reason) and that's it.

So my todo is simply to try and remake the terrain without getting any leaks. I have a couple of ideas on how I might achieve this, I think the problem was the void-facing terrain were misshapen rather than nicely boxed and uniform.

It's a bit of a nightmare but I have definitely learned a lot in the last couple days. 
Quake is ooooold and rickety. Expect problems. :) But it's fun... 
If you can pull it off and learn some best practices, make sure to write them up on the QuakeWiki or here, please! 
Best Practice? 
The whole process has been a big ol' practice! That's what the map was about. I have keep a lot of the different stages of the map, so I can easily do a mapping retrospective.

As for the writing I don't really have a desire to write it up on the wiki, but I really want to have a go at making some youtube videos on the process I took, lessons learned etc.
I'll start pestering my film-maker friend until he caves in.

-box out your map/layout
-use trenchbroom 1.05 from the start
-get your hands on TreeQBSP from
-become best friends with the "pointfile" command and "r_showtris" 
TB 1.05 
*does* seem to have better vertex accuracy for more standard shaped geometry, after I did all my pointfile detective-work I selected all the brushes and did a correct vertices & snap vertices... seemed to sort out the last remaining HOM's on the map.

Only trouble now is I have no terrain in my map after I brutally removed them all. I'm going to do it bit-by-bit and *hopefully* the map will have it's finalised geometry! Then I can get back to the fun stuff, testing, item placement etc. :) 
I was talking about what to avoid specifically for TB. Apparently there are some things which will lead to bad brushes etc. and I'd like to know how that happened. 
The map design videos would be TB-centric.

In terms of how to avoid bad brushes, who knows? I never took off grid snapping and I almost never went below the standard 16 units. I think some brushes just "become" malformed if you play with the vertices too much or you make shapes that are just too crazy!
Even some of the (very plain) curved walls which were grid aligned had become very very slightly nudged off the 16 unit grid. It wasn't until I did the correct/snap vertice trick that it was fixed.
Again, the tools used for pointfiling and treeq really helped me to get to a water-tight map. Though I think whatever you fixed between version 1 and 1.05 obviously helped a lot. I just hope I can redo the terrain, that *IS* after all one of the big selling points of TB ;) 
Turns Out TB Was A Trojan Horse All Along 
A QuArK in disguise!!! 
Here's Some Advice... 
I was using the co-ordinates and the pointfile to find leaks (as is the standard procedure), and to locate them easier in TB I was dropping in a monster_boss entity and entering the co-ordinates in the "origin" key, then when the entity moved I would delete and replace it with a shambler (again with the same co-ordinates), and then with a rottfish. Only last night at 3am when I was looking for the leaks I had forgot to take the shambler out the map when I compiled the fixed map... It scared the bejesus out of me! I decided that was a good time to stop mapping and sleep. :D 
I Think 
those problems are mostly the result of imprecisions when loading the map. I'm working on an improved version of the vertex generation algorithm that will do a better job of avoiding degenerate edges and faces.

An edge is considered degenerate if it is very short (shorter than 0.5 units) and a face is considered degenerate if it is a triangle and contains such an edge. This should help avoid such problems, however I can't predict whether QBSP will do the right thing, too. But I think everything will be much better if I can switch TB to use only integer plane points. 
You're not too far off there, sadly. 
those problems are mostly the result of imprecisions when loading the map. I'm working on an improved version of the vertex generation algorithm that will do a better job of avoiding degenerate edges and faces.

That might explain why some problematic brushes (one that caused a crash for instance) look completely different when reloading the map?

In terms of how to avoid bad brushes, who knows? I never took off grid snapping and I almost never went below the standard 16 units. I think some brushes just "become" malformed if you play with the vertices too much or you make shapes that are just too crazy!

Pretty much my experience.
One thing I think can be problematic is adding new vertices, in certain cases those can create strange n-gons that almost certainly will get screwed up after a while. Also dragging planes on a non-grid-aligned plane tends to end up badly a lot of times (especially in conjunction with above case). I guess that kind of makes sense when you think about the floating point issue... 
That might explain why some problematic brushes (one that caused a crash for instance) look completely different when reloading the map?

It might ;-). I can't say without seeing an example. 
It Almost Sounds Like... 
you're running into the same type of problems that plagued Quoole 0.99 (creeping brushes). I hope that you can figure it out and fix it. 
I promise that I will find a solution, even if that means that vertex editing has to be dumbed down a bit. 
Dumbed Down Crushes Creativity 
That would be a great shame because this is one of the best features of the editor. It would be a shame to fall into the trap of GTK 1.5 and force mappers to only create limited brush shapes because of vertex problems. Personally I prefer the ability to push brushwork to the limit and then have tools that look for problems afterward.

I personally use SDRadiant 1.8.3 and when I get issues with brushes I take the brushes and cut them. This forces the editor to re-generate all the planes and this usually fixes most of the problems. One other solution is I use an editor plugin called Bob's Tools. This goes through the whole map looking for potential brush plane errors and re-creates any brushes with problems. When it is finished it highlights what has changed (selected) so I can decide if to save/carry on. 
I liked how Quest would allow me to make invalid-shaped brushes which I could sort out afterwards, whereas in GTK 1.5 I always have to go out of my way to create properly angled (rotated) or abstract stuff, because its validation system is so overly rigid and limiting. 
hi, was very busy today and didn't have a chance to check func.

i'd really need to see how the map is made to be able to tell, but a lot of the time, i found just snapping the vertices seemed to always fix my problems. i never really did anything special to get it to work.

sorry i can't be of more help. 
One Should Always Snap The Vertices 
But it's not obvious to new mappers. When TB was released, I actually expected it to do this automatically - making perfectly valid, grid-snapped trisoup terrain/brushes without additional user input. Easier said than done apparently. I suppose a notification popup ("Do you want to snap/validate brushes?") before saving wouldn't be the smoothest solution, either. 
Snapping Verts 
This is actually what I meant by dumb down. This would solve all problems, but there may be situations where the user wants off grid vertices? 
Wanting Offgrid Verts. 
most of the time I'd say you don't want off-grid verts, but I know for certain in my map there are a couple of instances where I *do* have them (on purpose). But you'd be unlikely to tell if you looked in the editor as they are clipped along the same plane as another brush that *is* grid snapped properly.

I think I'll stick with v1.05 and just run through the motions of checking at every stage. 
Fringe cases, certainly. Again, a Quest example (call me neqer): you could generate brushes of certain geometric shapes which would rely on lenient treatment of vertices/coordinates. Snapping them to the grid triggered a bunch of consistency warnings; leaving them unsnapped could make their vertices 'wander' with each save/reload sometimes. I used it to make trees
also arbitrarily rotated brushwork can be compiled correctly when the vertices are off grid. most of the cooler bits in CZG's honey are all off grid. 
I can't think of an instqnce where this would be beneficial. But then again I have my own boxy style of mapping.

Why not make it an option, default on? 
So you resave multiple times to get irregular spheres?

Maybe that could be a 3dsMax style 'noise' function...

Which could also be used to instantly generate terrain - and then tweak it to fit the level requirements with the vertex tools. 
Very Loud Ambient Noises 
Now that I have a map that compiles properly I have noticed that the ambient sounds for the water is very loud. What gives? 
What Compiler 
Are you using?

It shouldn't affect anything greatly, some of Bengt's stuff allowed for control over the ambient sounds from sky volumes as I recall.

Quake sounds function on visibility, more than audiable range. They're quite primitive in that respect. Maybe you don't have enough other ambient sounds? If they're drowning out weaponfire or monsters then something very weird is going on. 
to avoid confusion:

there are 2 types of ambient sounds:
- point sounds which are made with ambient_* entities and attenuate with distance centered on the entity.

the other type is area ambient sounds which are based on if specific vis leafs that contain either sky or liquid are visible to the player. in simpler terms, if the player can 'see' water, then a water sound plays, if they can 'see' sky, then a sky sound plays and this sound is full volume until you can no longer 'see' the area in question, at which point the sound just stops. 
Off Grid 
Would still be possible as the result of anything but vertex editing. Going into vertex mode would snap the veers however. 
Honey is all on grid; The 0.125 grid. 
It's the contrary, actually. The sounds function on range. Otherwise you would run around a corner and the all the ambient and monster sounds from the previous room would suddenly stop. More often than not you also hear sounds through solid walls when they really should be blocked for logic reasons. 
I Have Only 
used slime water portal/brushes but they're real loud. At the moment I'm just using Bengt's TreeQ alongside Tyranns light/vis, once the map is done I'll be using his bsp tool too. I tried using -noambient and -noambientsky but vis recognises neither of these things and it doesn't vis quite right. 
you guys are saying that snapping vertices usually fixes most brush problems? 
Version 1.05 managed to fix the more simplistic geometry in my map that I created in version 1 that was creating the errors. It didn't work on the really crazy terrain geometry that I had made. But I have yet to retry making the terrain, I have some ideas on how best to approach the terrain but my fear is that I will be fudging around the real problem (and I could still end up creating bad shapes that you can fall through), we'll see how it goes. 
Did You Trisoup It? 
Because the more planes you have per brush, the more likely it is to get errors. 
I made a grid of cubes and then selected all of them so that I could edit multiple vertices at once. I hope this is the right method. 
Czg: is that an important distinction? Maybe if TB snapped to a 0.125 grid? 
Which Compilers/editors Support That Size? 
Isn't that idTech4 resolution? 
Doesn't Matter Ricky 
The compilers don't give a shit because the map files only contain the planes. 
Sounds good to me. Necros? 
So it's an editor restriction?

I'm just asking because I've been dealing with 24 sided circles and curves, and there are severel limitations on what can be done with a 1x1 grid, at the scale of Quake. 
several? or severe? Take your pick. Was meant to be the latter.... 
It's an editor restriction. 
OK - So Obviously I'm A WC/Hammer User 
Come to think of it, I think WC allows for stuff to be off grid, so the real issue is the grid resolution in the editor because you need to use snapping to make sure that your faces are truely flat. If not then you get compiler errors when compiling your map, HOMs etc. So in theory I can create more complex brushwork in another editor and import it into WC/Hammer.

The Important Thing To Remember Is That 
Vertexes are not stored in the map file. Face planes are stored in the map file.
The editor derives the vertexes and edges by intersecting the planes in a brush.

Take a look at this: (modo)

Imagine that's a wedge brush to begin with. Ignoring the third dimension, it is defined by the planes A, B and C. Those planes are stored by storing the coordinates of three points the plane passes through. Traditionally, these three coordinates have to be integers. The two dots on each "plane" in my drawing show suitable coordinates for this. (Again, ignoring the third dimension here.)

Now if we clip that brush using the plane D, we are simply adding plane D to the brush definition. The coordinates for this plane is also easily stored using integers.
HOWEVER, one of the new vertexes that the brush gets, circled in red, is definitely NOT on grid. Its coordinates would be 2/3'ds of something.
The brush is still perfectly valid and "on grid" in a sense, even if its vertexes isn't.

SPoG wrote a really excellent document about the technicalities of the MAP/BSP format a while ago. It was hosted on PQ but then that died, so I rehosted it but then died, so now I have no clue where on might find this again.
If someone has it, please link it here because it is essential reading imho. 
On-grid / Off-grid 
As has been said, the compilers don't give a toss about whether or not brush planes/verts are in integer coords, or powers of two or anything like that.

That said, in terms of building a nice bsp tree, the less unique planes, the better. Being "on grid" generally means that more of your brush faces will share the same planes, and the bsp algorithm can build the tree in a nicer and more optimal way, minimising the number of faces that need to be split because they straddle planes, and the complexity of the bsp tree.

Of course once you start making terrain maps, planes will be all over the place whether you are "on-grid" or not, so the bsp tree will be getting all chewed up regardless. 
Ok I Found That SPoG Article

Seriously go read it. Some parts of it are quake 3 specific though. 
Also There Already Is A Quake Wiki 
Why don't you guys go work on that one instead? 
Re: 12656 
Sounds good to me. Necros?

You're asking about Fifth's terrain method? I would recommend triangles instead of cubes, but yeah, the essential method is the same. You build a flat mesh of stuff and then pull vertices up and down to make terrain. 
As has been said, the compilers don't give a toss about whether or not brush planes/verts are in integer coords, or powers of two or anything like that.

That is misleading. The compilers do not give a toss about vertex coordinates at all because they will recompute them (and try their best to fix any errors). And of course as far as the compiler is concerned, floating point coordinates for plane points are fine, too. But these have inherent problems in that there is always rounding involved. When the editor saves the map file, it will round the floating point coordinates and when the compiler loads the points, rounding may occur again.

So bottom line: The only way to accurately transport any brush through a map file is to use integer coordinates for plane points. Everything else will result in vertices not showing up where you saved them unless the plane points happen to be all integer.

That said, the errors introduced by floating point coordinates are usually negligable in the BSP - it will look just fine. However, it might be the source of two problems: Microleaks and wandering vertices. By the latter I mean that vertices don't have exactly the same coordinates after saving and reloading the file.

I think for TB, the best way to go is to keep the vertex editing as it is. The user already has a way to correct almost all errors. However, I intend to:

- Recompute all vertices when the user leaves vertex mode. This way, the user sees what QBSP will see.
- Let the user choose whether they want floating point or integer coordinates for plane points.
- Show warnings for brushes with off-grid vertices and floating point plane points (can be suppressed).
- Improve error handling when loading maps (auto-heal super degenerate edges and such).

I think that gives us the best of both worlds. You can use TBs vertex editing unrestricted, and the editor will show you have the geometry will actually look like in game when you leave vertex mode. Users with very old compiler tools without floating point support can also still use the editor. 
The suggestion of snapping the plane points (not verticies!) to a 0.125 makes the most sense - you won't get any rounding errors in that case. You could make it a configurable option too - 0 for no rounding at all, but place a warning on it or bury deep so only people who really know what they are doing will mess with it. 
you won't get any rounding errors in that case

No rounding errors during writing the file or reading it back, just to be clear. Obviously precision limits still apply to everything after that, but then the ball is in the compiler's court ;) 
Bad idea - that's not what I mean - you can still end up with bad surfaces, from a mathematical point of view. If you have a surface with four or more corners, then in order for that surface to be truly flat the corners have to be on the same plane. So snapping (even to a 0.125 grid) can still result in surfaces not being flat.

I just mean when I'm creating brushwork, for stuff like 24 sided circles and weird angled stuff, it would be nice to work at 1/8th of the scale I am currently limited to working at on a 1x1 grid. 
Can split a four corner face into two three corner triangular faces, I know that.... 
Automatically I Mean 
But it's only the plane-definition triangle that would have it's points snapped to grid, so it won't matter how many points there are in the face/winding ( see czg's post ). 
ricky - you can't make invalid planes just by altering the plane coords, and you won't make an invalid brush with such a tiny amount of snapping unless the brush is basically degenerate already. 
What if the snapped plane coordinate cannot be represented as a floating point number? I'm still a bit confused by floats, to be honest. Also, where did you get this idea? Does any editor do this kind of snapping? 
but surely any multiple of 0.125 within a realistic range (ie a range of values you'd find in a quake map) can be represented perfectly in floating point unless im missing somthing? 
With standard single precision, you have 23 bits of mantissa, so if you stick to 1/8 precision you will use 3 bits for the fractional coordinate and you have 20 bits left. Which means that any coordinate on the 1/8 grid will have a precise floating point representation with the coordinate range +/- 2^20 (1048576).

I'm not aware of any other editors that snap to a fractional grid, but I do remember looking at a version of radiant some time ago and seeing the code which always snapped their plane points to integers. 
Haha Yeah 
Well I have an algorithm that will find quasi-optimal integer points for any given plane, but even then it doesn't work too well. I could try snapping to .125 or an even lower value and see how that goes. 
Yeah, that only says how precise the final representation can be. You may (and probably will) need extra precision for intermediate calculations. It's tricky stuff! 
The Doom3 editor supports 0.5, 0.25, and 0.125 grids. 
Yes, Grids 
I can add that to TB in a jiffy, but the major problem right now is how to represent the planes with maximum precision across file saves. 
One option, and you probably don't want to do this, is to go the Worldcraft route. Store maps in your own format and export to MAP for compilation. That would retain perfect precision at all times and only need to snap once, eliminating drift. 
Of course, but it does show that even id ( and JC ) are fine with that kind of granularity.

And as others have stated already, certain fractional steps ( 0.5, 0.25, 0.125, 0.0625 ... ) should not cause rounding errors - as long as the absolute value "in front of the dot" is not too large.

This page is pretty handy to see whats going on : 
0.125 Plane Point Rounding != Vertices On The Grid 
If you limit the plane point coordinate precision, you will be unable to snap vertices to the grid in certain situations. 
It will eliminate drift, yes, but it leaves the problem of finding good representations of your brushes when exporting the map file. You must remember that TB will also support games like Hexen 2, where floating point compatible compilers are not available. I think it's better that the user actually sees what the geometry will look like to the compiler. 
But it would mean you don't have to use integers, but could use certain fractions of floats for your drift-free plane definitions - which could mean more accuracy to what the user intends - or am i seeing this wrong ? 
Sorry if I sound like an idiot for asking, but if a brush is just a collection of planes at a certain vector how can they even become degenerate? Convexity? 
The Brushes Won't Degenerate 
But if you limit the precision of the plane points, you limit the number of points where a vertex can be because not every plane can be represented with limited-precision plane points. As the easiest case, think of a plane that is parallel to the XY plane with a Z value of 0.4. This plane cannot be represented with integer precision plane points. The closest approximation is the XY plane itself.

The problem is that it is impossible to represent the many brushes which can be created with TB's vertex editing (or arbitrary rotation, for that matter) if you limit the precision of plane points. Of course, the smaller the value you snap the points to, the smaller the errors will become.

In any case, I feel the best way is to leave this to the user. I will add a setting to the map properties dialog that will allow the user to choose between integer coordinates and floating point coordinates, and to increase the maximum number of digits written to the map file to a really high value so that the rounding will be minimal. 
Well All I Can Say Is 'I Wish Worldcraft Could Go Down To 0.125 
That would help me a lot, without me having to learn a new editor. 
Well, Mine Go Up To 11 
Logic Gates In Quake 
I made a little tutorial about how to make logic gates in Quake. Currently I just wrote a text file and made an example map, but I plan to put a page on the wiki when I have some better pictures to use :)

It shows how to make AND, OR and IF ELSE. Using these as building blocks you can do all kinds of things (if else is actually two gates inverse of each other anyway).

What I didn't explain is that the single door logic gate is essentially a NOT gate. 
Very Cool! 
I'm sure there'll be many cool puzzles coming out of this. 
No Textures 
Hi guys, I just wanted to give this editor a try and read the docu but I don't have any textures loaded.
I am using DarkPlaces and chose the DarkPlace folder for my directory with the Quake stuff in it.
But I don't see any textures being loaded, what am I doing wrong <.< 
which editor?? trenchbroom?

edit > map properties > + button > find your .wad file 
need to download the .wad files. <--- the standard textures

There's a lot of different texture .wads in that directory too, they *should* all be quake 1 .wads 
you very much!

I used to make maps for Doom and thought that wads are in the main directory like DOOM2.wad (also because of the Quake.wad mentioned in the documentation ^^).

And I know this is a different topic, but can I also make maps for the Q1 expansions like SoA or DoE somehow? I'd love to make use of the entities featured in those games. 
SoA And DoE 
You will need to hunt down the .fgd files (the entity data that Worldcraft and Trenchbroom use) for them. I don't have them, sorry. They used to be over at PlanetQuake but that site is dead now. 
This Should Be The Right File 
the one. 
Thanks For The Link But... 
I get an error in the console line "Parse error at line 8, column 1: Unkown Entity definition class @ Main". Are other fgds not supported by TB yet? 
Open the FGD in a text editor and delete lines 8 up to and including 13. 
I Believe That... 
Trenchbroom has extra data in it's fgd file that isn't in the originals. You would have to add things like the colors and model info into it for it to work 100% in Trenchbroom.

And that looks like a problem with that .fgd. Try commenting out the @main lines down to the worldspawn entry by putting a \\ in front of each line. I'm not sure which editor uses that command but it's not a standard Worldcraft item. 
TB only adds the model info, and that's completely optional.

And yeah, the @Main section in that FGD file seems to be erraneous. You can comment stuff in FGD files with two slashes //. 
Was Testing Out Preach's Awesome Trigger Spawning Hack 
and made a very simple map to show it off. You can find the map here:

and Preach's article is here:

Very useful for those who are making a map for vanilla progs. 
I can imagine some clever puzzle maps for standard quake with this. I've been thinking about coop maps recently, I have noticed that many maps that are built for singleplayer have broken co-op support and I'm considering some kind of prefab solutions that I could use this for. 
To be fair, the chances of your map being played co-op are so slim these days it's really hard to work up the enthusiasm to set it up. 
You mean compared to the millions of people who play the standard singleplayer maps?

FifthElephant: Please do! Coop is great fun and some proper maps would rock. 
You know what I mean. If 10 people play your map in single player, you'll be lucky to have anyone who gives it a run in co-op. 
I know what you mean but so what. Is modding for Quake about popularity? I don't think so for most people. 
I saw your post on facebook via some friends! Made me smile quite a lot (I think/hope it was you)!

As for co-op, I don't see why mappers don't have it in mind before they start smacking brushes down. It seems like a huge oversight to me.
For example, I saw in the coop vid of Vondurs Nastrond situations where one player is in a room and 3 are locked out, why not make it a one way room by having a drop-down or lift on one side?
Why have it so the player has to run aallll the way through the map only to fall in the lava? Would it be so much extra work to have a teleport/checkpoint?
Why not have ammo closets that are open in coop?
What is the point of having keys break a map when you can just use a button?

I think quakes coop could be like Zelda Four Swords with guns! 
It's A Shame, But... 
there aren't really many players, so a really well done coop mode probably won't be played by many people.

That said, I think there is a niche of a niche audience who do still play coop. I love coop Quake, but I don't know who plays or how to play anymore (netquake?) More maps supporting coop, and especially a map tailored for coop would be welcome. Just don't expect everyone to be able to play it. 
"Is modding for Quake about popularity? I don't think so for most people."

Of course. And if putting in co-op support is what turns a mappers crank then go for it. I'm just saying that for most mappers, that's probably not what they're in it for. :) 
I always add coop AND dm support to my maps, even if dm is usually a token effort.

I didn't realise keys broke maps :/ I thought it was only a problem if you triggered stuff from key pickups. I normally put a trigger around the key, but that causes its own problems, since it is sometimes possible to get the key without hitting the trigger if the player is careful :(

What actually is wrong with keys in coop? 
Reason For Adding Coop + Dm 
My reason for adding support for coop and dm is simply that the community is so small, that it's nice to make something as many people as possible can play. I always release map source too for this reason, since although it's unlikely, maybe someone will want to tweak something in dm or coop, or perhaps even make a remix (see e1m1rmx remixes).

I totally respect people who are mapping for their own enjoyment though. New maps that only support sp are better than no new maps!

It's my opinion that you should always release your source though, since it's no effort to add it in the archive. 
Keys In Coop 
I've heard that keys can break coop, something to do with them being lost when someone dies and the level being uncompleteable (that's a made up word!)... also if you make the key stay on pickup then you can't have multiples of the same key in a map. I haven't tested it but I have *heard* it can be problematic.

If you're making a SP map I don't think it should be too much work to make it coop (unless you have very small 1-man sized trap rooms etc), I can imagine having a slip-gate style start area where each "checkpoint" unlocks a progressional shortcut teleport back to near where you died. It'd be nice to have a cookie-cutter copy/paste prefab or template that mappers could drop into their map with relative ease to setup coop. Some maps, like DM5 Remix, are so small that it doesn't take much time to run back but other maps (like Stark Monstrosity) are huuuuugge if you die. 
Well, I think every id map has keys in it so it must be something you can account for. 
Keys works fine in coop. But there's a bug that keeps weapons from firing their targets which can break a map if they're supposed to trigger something that's critical for progression.

I do add DM settings to my maps, too - for fun, the sake of completeness and a nod to the oldschool, not because I think they make particuarly good DM levels or expect anyone to actually play them. Good for DMSP, though. I've also made a few tweaks for coop in places, although not very sophisticated. I kinda consider DM more important than coop... because coop usually works just like SP most of the time (out of the box, unless there's a showstopper). Quoth has specific coop flags which makes it easier to create gameplay that actually requires cooperation, while in ID1 it seems mostly reserved to the field of hacks. 
it's not a conscious decision on my part to ignore coop, but it's just not something i think about most of the time. 
FifthElephant: Yee, that's me. Trying to get some more people interested in Quake again. It's hard to get them to do more than press "like" or leave comments though. But seeing hundreds of views within seconds is very motivating and encouraging. 
I did intend to make my RMQ maps coop capable, because I think it's nice to have your map not break outright if someone does play coop, it's simply good practice that way.

Willem is right though that quake coop is a niche of a niche.

Now for total conversions that might get a slightly larger audience (as if those were ever made), I do think coop is worth it but then you have to put some time in to polish it and advertise it as a core feature (similar to what Lara Croft and the Guardian of Light did - people were suddenly playing coop and enjoying it because the game did it really well and the two main chars complemented each other while solving puzzles etc).

So, I'd definitely go to great lengths to put in coop if it was a core feature of a mod that, say, got an audience via moddb somehow, but for Quake speedmaps I'd probably not.

An engine that supported splitscreen coop the old fashioned way would be an incentive - FTE might be able to do that, actually. 
and another point: today's huge sprawling maps aren't very coop friendly, because there is just a lot of running around. Would almost need vehicles to quickly reach the other player. Unless you stay together at all times, in which case coop is a bit pointless. It's more fun if the other guy takes a detour to open a door for you or something. Map has to be designed for it. 
Huge Map Coop 
which is why I suggested a slipgate hub where checkpoints activated a teleport shortcut... or didn't you read my wall of text? ;)

Also I would love to see splitscreen quake! :D 
Coop / DM Support 
I'd agree it's good practice to include it, a nice bonus extra. Like having a custom start map.

Big maps can be coop friendly - I made all of warp work like that, although I think there's one bit in warpb where a player can be temporarily locked out. But probably more than 1, my memory is hazy.

A nice side-effect of making the maps coop friendly in warp was that it meant adding lots of short-cuts as the player progressed, which had benefits in SP as well.

DM in big maps is trickier. The best idea I heard for that was just to use a small segment of the map and wall off the rest.

Kind of wasteful, but depends on how cleverly you do it I suppose, and for how many players. 
The best idea I heard for that was just to use a small segment of the map and wall off the rest. 
Func_illusionary That Can Be Killed? 
I was just wondering if it's possible to make something in standard progs that behaves like a func_illusionary, but is non-static and can be killed during gameplay. Anyone know? Any hacks? 
Self.use = Sub_Remove? 
i'm retarded.

killtarget makes that pointless 
I have a way, but I need to warn you that it is a hack. Negke often checks with me if a particular hack will continue to work in Quoth. The answer in this case is a definite no, and it won't be accommodated any time soon. This is because it relies on the assumption that monster corpses will remain after death, which is not true in lots of quake mods!

So add these fields:

"think" "demon1_die6"
"nextthink" "0.1"

It will then go non-solid after 0.1 seconds (so some items might come to rest on it before the transformation, if you aren't careful) 
Great Proofreading There 
Add these fields to a func_wall... 
A slightly more complicated but also more compatible way is to make the wall an info_notnull with its model and modelindex fields set to itself. 
That also gets around two of the side effects of the func_wall version: that you are forced to have the func_wall use function (which toggles the "skin" of the model), and that the texture might toggle a few times right at the start of the map while the hack kicks in. You can skip setting the model value directly as long as you make your info_notnull a brush-based entity (you do still need to set modelindex though). 
Thanks For Those 
interesting hacks. I might give that a shot, but working in Worldcraft makes setting modelindex a pain in the arse since I'm using rmf for my map. 
Out Of Order Useable Map Item Trick

I made an example map showing how you can make fake map items that the player can pick up and place at another point in the level. Picking them up and placing them can be done in any order as a moderately complicated trigger system is used to check if the player has at least one item and then places the item and reduces the count of items held.

However, I've just realised that you could do the exact same thing by having multiple keys the player must collect, but that doesn't allow for customiseable item models unless there is some awesome hack that allows that.

Meh, ah well. Use it if you like :) 
I Like It... 
I'd love to see a map that you collect a bunch of bombs and then place them, then you trigger an event as you pass through the exit which sets off a kind of cinematic explosion scene...
I'm surprised more mappers haven't made more stuff like this to be honest, I'm sure it'd be possible to do with a bunch of func_doors and triggers etc. 
That Wouldn't Be Difficult At All 
You could even use the spawning trigger hack to make placed bombs effectively shootable, so that you can blow certain parts of the level open. Of course, you could just use keys, but you can only carry one key of a particular colour at a time, and it looks like a key.

I definitely think using logic gates and other various hacks and tricks allows us to do a lot of interesting things that haven't really been done before.

czg's rocket/grenade locks are also fairly easy to implement in vanilla Quake I think. Should simply be a trigger_once with health > 0 inside a hollow tube with the brushes inside arranged to prevent the wrong kind of thing triggering it. I think the rocket locks also used trigger_push to keep grenades out.

Would be cool to see more maps using this stuff.

Of course, we can just make mods to do all this and more, but there is something sexy about shipping only a bsp. 
Honey Was All Vanilla Until Fairly Late 
hey necros,

two people have posted a comment now on my video of q1spcompilinggui, saying that when they try to compile the map it says map not found.

I don't understand how they could get this error, since I show exactly how it's done in my video.

They also find it a hassle to take a screenshot and post it somewhere asking for help, so.

They said they're on win8.

Anyways, have you had anyone report similar issues? Do you have any thoughts or suggestions for them?

Here is the quote: "I downloaded several compilers, including hmap2 but none of them work. Every time I try compiling my testmap the console says it can't find/open my map. Or says that there is no map. I'm selecting the exact path to my .map and really don't know what to do..." 
that's very general information, unfortunately. direct them to this thread and they can post more info.

the fact quake isn't finding the map can mean either compiling being aborted from errors or compilers not being found.

one thing is that if they are typing the name of the map into the text box, then it will not use that filename (because it's bugged); you have to select it through the windows open dialog box with the [...] button (all other dialog boxes work properly when typing in directly). 
I'm On Windows 8 Pro 
and I have been successfully using necros compiler since I downloaded it. 
Anyone Know Where I Can Get The Q3 Flavor Of The IK2K Texture Set? 
It's plans like this that make me wish I'd kept the Q3 version of that texture pack after all. All Google gives me is Sauerbraten (which links to the dead digital-eel site) or subsets of this forum - or a link to the Q1 version I made centuries ago!

(Yes, I could use my own, but they're a little too low-res and grainy for this.) 
Wait, Shit 
that's ikbase, not ik2k. ignore 
Ik2k_full_jpg Zip By Iikka "Fingers" Keranen

Than: thats pretty cool, I had thought of a similar system but with using a row of toggle shootable doors and 2 opposing shooters to store value and add/subtract in a linear fashion. A bit easier to handle larger number of inputs. 
Many Thanks Rj And Slapmap 
I'll take both; I might have a use for the base... 
Fat Controller Is Doing Things! 
Quake 3 Jump Pad Paths? 
Do any of the newer editing programs have anything like the old bobToolz plot path thing that will draw the arc player follows off a jump pad? I use NetRadiant, and there's a bobToolz plugin listed but there's no path plotting option. 
Making Floating Text (q1) 
I'm playing around with TrenchBroom editor and I'd like to make at some places floating text, like in main game (You can jump over ther, this hall selects easy mode, etc.).

Also I'd like to know how to make custom episodes. 
I think you can do a trigger_multiple with a message key -

I'm not certain though, never done it before. 
Re: Floating Text (q1) 
Yes, use a trigger_multiple and put your text in the message key. Be sure to add a delay so that the message doesn't repeat constantly if the player happens to be standing directly in the trigger. Somewhere around 10 - 20 seconds is a good place to start. If the message is long, you can make it wrap to multiple lines by inserting a \n where you want it to break. Also, the message key can be used with other entities that are triggered, like doors. 
Message Key... 
You can use the message key on various things to print messages when the player touches them or triggers them.

trigger_once - will print the message once
trigger_secret - will print the message when the secret is found
trigger_multiple - will print the message every time the player touches it
func_door - will print the message only if it is locked and the player tries to open it.
trigger_relay - will print the message any time something triggers it

There are probably a few I've missed, but those are the most often used. 
should the wiki or even a link to the mapping section of the wiki be added to the top of this thread? 
Finding Stuff 
It still amazes me how difficult it is to find stuff for Quake. I recently wanted to see how Rogue (mission pack 2) did there stuff and finding their QC files is really hard work. I even tried de-compiling their progs but had loads of problems with weird error messages.

After a long time searching I eventually found THIS and it is perfect! Loads of sample maps and all of the extra files needed to see how it works. If you want to use any of the mission pack stuff in your maps download this zip!

yes, it is pretty amazing. I wonder why nobody has really used it though? I mean, you can have funcs containing water ffs. How cool is that?

erm... I just realised that's not what you are talking about. Seems that I was thinking of this: 
Fullbright Removal 
I've made a few new textures for my map but I have some fullbrights on it that need removing, for some reason tex mex isn't removing them, are there any other programs that do this? 
You Could Try Wally

You might have to do it manually though, not sure..... 
I figured out a way to remove fullbrights using paint shop pro (yeah I'm still rocking this program)...
Just made all the bottom palette row a garish bright pink colour, all I have to do is load pink palette first and then the quake palette (whilst maintaining indexes) and it's all hunky-dory. 
TexMex can remove fullbrights - or at least show you which pixels are, for manual fixing. 
didn't work mr negke... infact the new way using PSP7 is actually fool-proof (can't believe I didn't do it this way before!) 
So I'm outta to make some textures for my maps. Do anyone have quake palette in Photoshop format?

There's a zip there containing the palette in several different formats 
as Negke says, it can remove fullbrights.

As far as I know, there isn't a fullbrite removal tool, but there is a "use fullbrites" option in the preferences that stops TexMex from using fullbrite colours during image conversions. To remove fullbrites from an existing texture, you might have to copy and past the texture back into the wad (shift+ctrl+c then shift+ctrl+v). 
By The Way 
I use Photoshop for editing id textures, and when doing so I make sure I use the pencil tool and disable any kind of brush dynamics or smoothing so that you know that the colours you sample are being replicated exactly when you paint. I do this, and then find that I don't need to disable fullbrites.

I guess if you paint with the Quake palette it's fine too, but I don't really know any good 8-bit workflow in Photoshop. 
again than, I used the remove fullbrights thing, even did the copy paste trick and it didn't work. It removed the bottom row but not the second bottom for some reason.

darkhog, my advice is if you're making your own textures then work at least 2x the size you need and make a swatch using the palette. I wouldn't worry about the brush type too much as it will probably get lost when you downsize anyway. And watch out for fullbrights! :P 
Hi Guys 
short question, how can the quoth-vermis be moved around?
or how can i spawn it. 
Before The Editor Opens Map Layout 
Found this tool. Might be helpful to put ideas down before you fire up the Quake editor. Built more for adventure game layout put looks powerful. 
will never replace my pencils and grid paper!!1 
Thanks Than... 
You can attach vermis to a rotating train... Google this site for posts by me on this topics. 
Hmm, I Don�t Get It 
Necros, all i want to do is to lift a vermis out of an area the player visited earlier.
Sorry but i�m really desperate about it, attaching it to moving entities don�t work.
Any help would be very appreciated, maybe an example map or sth.

Thank you! 
you make a func_rotate_train and set it up as usual, but instead of making a rotate_object and doing a target->targetname to it, you do the target->targetname to the vermis.
the func_rotate_train will move the vermis around. 
Quark is a bitch you dont want to **** with.
Advice On Layouts? (Singleplayer) 
Consistent problem of mine with mapping (for any game really) is being able to create some nice looking rooms/areas, and having no idea what to do with them next; any attempt at layout becomes quickly stale, flat and linear - simply uninteresting. I've spent a long time examining existing maps, offical and custom, what makes them tick and why they have nice layouts with interesting flow; but I still have trouble doing the same myself despite having ideas for gameplay and themes etc.

Any pointers? 
Some layout ideas:

Layers: Take your room and slice it into layers and then create height differences based on the layers. Once you are happy with the height difference connect with stairs/lifts.

Purpose: Design each space with a theme and a purpose. Plan out the layout based on what function or purpose the room is going to have. This will often dictate height and shape considerations.

Texture: Use textures to define shapes, like lego panels. Cut and slice the brushwork based on texture lines, works best for industrial stuff.

Intersection: Take two spaces at different heights and mash them together to form a combined version. The intersecting area will be perfect for letting players see the next space and where they are going. Also good for forcing transitions between architectural styles.

Monster: Create a space specific for a monster which gives the monster a crazy good advantage over anything else in the room. Always allow the player a chance to see the room beforehand so that the only surprise is the monster not room + monster.

Humans: Define the space by door and window dimensions. Will give a location a realistic sense of volume and create a natural foot movement through a room. 
draw on graph paper what kind of layout or idea you have. Better to run out of ideas on paper than to 2 weeks in the editor, you can quickly flesh out your layout before you get hit with the dreaded mappers block.

Don't just draw the overhead layout! Draw a front view, this helps especially if you are making a castle or base that you have to get into.

Make a brush palette! Spend some making various brushes, columns, walls and general themes you want to incorporate. Not only will this save time but also help to maintain a cohesive theme!
I usually make various different brushes with different texture combinations too to see what fits nice.

Inter-connectivity, no-one wants to fight on a map that has no z-axis, make good use of different floor heights, stairways, walkways, overhead and underfoot platforms and bridges. Think of a snake eating itself or the infinity symbol, making your level go back into rooms that you have already visited (perhaps at different heights) will allow you to increase gameplay without increasing workload.

Lighting, make sure your lighting is interesting. No flat-lighting, make use of beams and architecture to cast interesting shadows. Plus a good way to help players not get too lost in your map is to give visual lighting cues, Portal 1 and 2 use this technique a lot!

Take a break from your map! Sometimes I will take a few days abstinence from mapping, sometimes I will have a nap for a bit (some of my best ideas come from that moment just as you're going to sleep)... it'll give fresh perspective! 
Does anyone actually do that stuff? I mean, I know that's the advice that gets given every single time ... draw it out on paper, plan every route, etc. I have never done that in my entire game dev career. Ever. 
I suppose I could scan my graph paper book for you if you need evidence. ;) 
Personally I gave up using graph paper for level layouts years ago. I believe 2D visual devices = 2D maps. If you want 3D level sketch the route in a 3D editor with blocks and ramps. You can always carve up the shapes later for textures.

One thing I find useful is imagine the flow of your level first. Think of the map as a roller coaster with high and low points. Nobody wants to play constant combat maps, allow for negative space. If you don't have empty spaces you cannot create crescendo gameplay moments because the combat intensity is a flat line. 
I pre-plan layout with a flow chart (bubbles connected by lines.) Each bubble is a space with a unique identity, defined either by the gameplay i want in there or the setpiece/visual idea i have.

For the contents of the bubble I draw isometric sketches of the room or area. Sometimes a top-down floorplan is cool too, but that lends itself to 2D rooms so it's better to draw isometric or draw both plan view + elevation view. I usually have too many bubbles and cut some of them during development.

My oldest maps were grown organically with no plan, but both Antediluvian and Rub2m2 were both built using the flowchart method. My professional levels have also been built this way -- with the exception of DM maps since they're so tightly integrated. For those I draw the entire map as one bubble so the isometric sketches include the entire map.

For pro maps I take the next step of blocking out the entire level with rough shapes first before detailing anything. For home-built levels I still do the entire room up to final quality before moving on. 
Yeah, we do the block out thing which is a clear win since moving a few BSP blocks around is a hell of a lot faster than a bunch of meshes and volumes. But the whole sketching it out first thing ... no, never done it.

I was just curious because it seems like such a time sink. I can't imagine it being faster than just getting in the editor and throwing blocking brushes around. 
For me, without hand-drawn sketches, I don't know what I'm building. I guess it depends on the individual, it sounds like you use the brush editor to do your "sketch." 
love to see an example or two of your sketches from Rubicon 2 or Ant. 
Yeah, I just think better in 3D. I'm very visual so I can feel an area better if I can see it in front of me ... By the time I sketch out a version, I could have blocked out 3 versions in that same amount of time. :) 
Yeah Me Too - Please Post A Pic Metl :) 
I am terrible. I'm getting better, but I tend to just build the layout in the editor, almost completely linearly. I also do most detailing as I go. I can totally see the benefit of drawing pics and sketching layouts beforehand though. 
Cross Post 
Pro Habits 
I pre-plan layout with a flow chart (bubbles connected by lines.)

A lot of games companies do that method. Some call them 'action bubble', 'encounter' or 'scenario' they are a very good way of grouping a chunk of gameplay together.

it's better to draw isometric or draw both plan view + elevation view

Lots of design tests still expect Level Designers to be able to do this at interviews on whiteboards or for written tests. Being able to represent an encounter space isometrically is a good skill to have, but this is different to 2D floor plans. 
Is important yeah, I usually draw concentric rings somewhere and label what I want to happen in each loop.

When I sketch stuff its usually something that'll tie the level together, like a light fitting, pillar, bunch of crates or something.

Sock's got a good list there, I'd also add:

Keystone Texture
Choose a single texture, then base the entire level around it. Make a few rules for yourself, some examples:
Use the keystone texture in every room
Use the Keystone Texture only on vertical Trims
What texture you use is obviously important, but in various ways - slime is going to be a different challenge to a flat metal without detail, for example.

If you're feeling particularly adventurous try choosing it randomly.

This is a rescue thing more than anything. Once you've built your 'uninspired' level, rotate it 15 degees on the ZX or ZY axis.

Difficult to get it on grid, but I guarantee you'll have something interesting afterwards.

Choose a series of events and build seperate areas for each one. 'A bunch of marines crash in a ship into a netherworld castle. They fight their way out of the crash site and reach a deactivated slipgate. They then fight their way across the castle to a key but are mostly slaughtered trying to reach a missing gizmo to reactivate the gate. The lone survivor is killed by some big monster.'

Arm up each of those instances as a set-piece scene, then link them up and bang a start point in there for the player (who isn't the lone survivor). You could try showing them to the player in sequence, but it's a pain in the balls to get right. Just the act of you telling the story for yourself will give the level a much stronger sense of place. 
I never said I just draw the plan, I also draw the outside or the look/feel of the area too... having a plan allows me to play with ideas without having to lay down brushes (which for me is really the time sink part, plus I find if hate an idea then I'd rather hate it at the sketch phase than have to redo a bunch of brushes)..
Having the plan view *and* the profile view, plus my pre-made brush prefabs allows some much nicer workflow and consistency.

I'm really surprised that some of the great mappers here just work in the editor. Like RickyT, StarkMon was a pretty beastly map... I can't imagine trying to make such a complex map without something on paper.

I guess I draw much quicker than I map, but I have been drawing for about 20 years longer than I have been mapping. ;) 
i draw nothing. maybe this hurts my design process a little in that there is less context and cohesion, but i'm too impatient for that kind of thing. if i'm sitting down to make a map, it's because i already have an idea in my head and i want to start building it right away. 
I can't draw for shit, so when I do draw it tends to be 2d - isometric sketches of even rudimentary quality aren't really in my purview...
So i'm pretty Necros style, I guess... Except, you know, I don't actually finish my maps.

Even as a student I only end up pulling my act together because of extrinsic motivation (aka deadline).
Hence only speedmaps being produced, I suppose. 
On personal projects, I never preplan. I'm a big believer in the Cerny Method in game design, where you do lots of preproduction and iteration until you have something like a single level that is shipable that you are happy with, and then enter production from that point. For me as a level designer, that fits how I work as well, I make 1 fully detailed area and theme, generally something like a central hub, and then plan from there.

I also really like reusing spaces. I think it helps give a sense of place to enter leave and return to an area several times. It takes a little bit of thought how to connect things, but I think it's worth it in maximizing how much gameplay you get from a space. The trick can be to make sure it feels natural.

scampsp1 is a good example, the room I made first (with the spiral stairs and angled walkways and gold key door) I basically stuck a bunch of doors at what I felt were natural places, and then thought 'how would I get from that door to that door', and just mentally decided between a few different options until I had a clear plan.

At Raven, I had to draw layouts or use sketchup drawings and write documents of a plan for the level (based from a paragraph blurb for the level from the master Design Document) and then present it to design / art / project leads who would ok or modify the plan. Honestly hated these, often they would be a giant waste of time because sometimes you would get blindsided by random new plans for your level that were decided in other meetings... or the art lead would just randomly decide that some cool centerpiece would need to happen that you had no plan for... or some crazy storyline encounter would be decided on the fly... yattta yatta yattta... and then once you built the map, you'd go through much the same process and likely have to revise several times again anyway! 
Actually that's one of the larger stumbling blocks for me as experience has shown that the original plan for a level is almost never how it actually ships - so why bother? Get something going quickly because you're going to throw it away anyway. It's just how it works... Iteration will eventually result in a fun level. 
Is the best way - start by slapping down big coarse chunky areas, move them around, refine and iterate. Eventually you'll end up with something good.

Nothing worse than spending ages drawing something out on paper then realising it doesn't work when you've built it. 
This Convo Reminds Me Of My R.A.D. Module 
At college!

(Rapid Application Dev. for anyone who isn't familiar).

I guess I use the dated Waterfall methodology.

Should be using an Agile methodology.... 
I Feel 
like I'm a bit of an anomoly here... With Deck it's easy since the layout and plans are already in my head (and made in UT) so I have no need to lay anything down. But I have a blue map (it may be the next one, maybe) that I drew some above and sideviews to get a kind of feel (the idea came to me when I was going to bed, so I drew it so I wouldn't forget)...
Once it's released I'll scan the plans too for fun. :)
I deviated a little, plus the actual map itself is way more detailed. 
I Prefer 
a pragmatic approach. 
Me Fool 
I start,
then I'm lost,
I fall,
then I crawl,
I cry,
then I fly,
I wrench,
then I drench,
I choke,
then I'm broke,
I wind,
then I'm blind,
I carve,
then I starve,
I map,
then its's crap,
takes time of miles,
I flute,
then I salute. 
Haven't Tried That Method. 
I really have to stop reading func_ when trying to finish a map. I can get a basic layout done then I find something cool on func_ and get lost playing with it. Teaching old progs.dat thread is a good example. Quoth has so many tricks, now func_detail is here. Redo the map now to optimize vis? Go to The Tome of Preach find more tricks and must have models, spark a new idea for the layout. Map gets larger, more complex, larger add features and never actually finish. ohh wait look Fitz V can now do this or that, new idea! more complex larger map. I really need discipline! 
Where has ZealousQuakeFan been? After TyrUtils release I thought we would see that massive map with func_detail optimization. 
That would probably help him a big deal. Though maybe he's given up on the whole thing already. 
What Would Be Good 
is if all engines had support for quake 2 style brushes (trans33, trans66, monster clip, current, flowing)...

And TB had native support for Quake2/3 etc. 
I Was Just Wondering About 
ZQF the other day. 
Hope He Returns 
Monster Clip, Current, Flowing 
Don't need engine support, just QC
Pox's qc extras have moving/flowing water already. 
Radiant Build Menu 
I can't seem to customize the build menu in radiant. It keeps resetting itself to default? 
I never ever managed it either, I just stuck to using .bat files or the most basic options in the menu 
I use bash scripts, but MadGypsy has some posts about the Radiant build menu @ He seems to have it working. 
to high-res textures or not to high-res textures? that is the question 
Absolutely NOT. 
Hi-Res Textures 
Should be an afterthought at best.

I made my last map using entirely vanilla Quake textures to ensure that if someone used hi-res textures all of the surfaces would be hi-res.

But it sure would have been nice to use the numerous custom textures available. Ultimately most of the people here anyway like the old-school look. The hi-res monster skins look weird for exmaple because the models themselves have such low poly counts. The game is generally more convincing at it's orginal resolution. 
High resolution textures can look absolutely gorgeous, especially coupled with no texture filtering (or the items look out of place).

If you were asking about fan-reimaginations of the Quake texture though, I join the choir (apart from Debaser of course). 
People outside this forum might like the option to have hi-res textures. I see no problem with them. Perhaps provide the hi-res textures as an optional addon pack. 
i've found the greatest enhancement that external textures provides isn't high res, it's freedom from the 256 colour palette. 
Texture Density 
I personally have nothing against high res texture (I have produced enough of them over the years) but and I mean a big BUT, you have to consider the bigger picture.

If you upgrade something with better textures then the rest of the game has to match as well. I like to call it the Domino Effect and it has to do with texture density not resolution. The key to good texture work is maintaining texture density across all assets.

As necros said, the best upgrade to Quake would be to free all assets from the 256 colour palette and finally have a rich colour environment. 
The Biggest 
Problem with hirez is that its usually done badly. Ugly normalmaps and very busy diffuse maps.

When they're nicely drawn they look great.

Unless they're stretched over the lo-rez meshes of monsters. 
Textures In Trenchboom 
I decided to try out Trenchboom today but I am having problems getting textures to show up. Is TB supposed to load the default textures? I have the editor pointed at my Steam install of Q1 and the models in the entity tab show up correct, but no textures show up in face tab. Under the map properties window its set up for Quake.fgd and looking under id1. I see you can add texture wads here but all of Q1's default stuff is loaded under .pak files.

Is this behavior normal (no textures under face tab) or should I have all of Q1's textures show up in my list? 
Textures should be loaded separately. Go grab some .wads from here
This Is Why... 
I'm doing a video tutorial from absolutely zero aka can't map, don't know how to set up directories etc...

Hopefully the first part will be up soonish (I'm only doing the tutorial, it's being edited by a friend). 
i've found the greatest enhancement that external textures provides isn't high res, it's freedom from the 256 colour palette.

Fog Colour 
when setting a fog command in quoth - how does one set the *colour*? 
try sth. like
fog 0.037 0.23 0.22 0.21
were the first number is the density and the last 3 values
rgb ranging from 0.....1. 
Got It 
By The Way 
The fog setting isn't just for quoth, it's supported in most engines on all maps that have that parameters in the worldspawn. I don't think it's a standard parameter though (i.e. not supported in glquake and definitely not winquake), so I don't know why it's not _fog. 
in that case you would just add 'fog x' into worldspawn? 
Public Domain Music? 
Anyone know of a decent website or resource where I can download pd music that would be suitable to use in games? I'm looking for sort of a orchestral ambient type sound but really I'll take anything as long as I can use it without hassle :) 
PD is hard to find, I would suggest creative commons instead. And for that check my recommendations in the music thread or be more specific. 
This -

I'm pretty sure Mike Woodham used it on his last map. Not bad stuff either (egoraptor and harry patridge have both used his music) 
Database Error :( 
I'll check it later! Thanks. 
Outdoor Lighting/fake G.I. Tut 
Wrote an artice/tutorial on outdoor lighting/fake G.I. with Tyrlight
click Hope it's helpful.

Daz: Jamendo ofcourse, tonn of CC licensed music. 
Warped View 
When the player is inside of a liquid (water/slime/lava) the view screen warps in and out (probably not the right term) is there a console command to enable this effect if not in a liquid content? I know about screen tint console command v_cshift. 
r_waterwarp in some engines. 
oh... sorry, this isn't what you need. You want to enable the warp in air, this variable can only disable it when in water. 
I recall there's a power up in Quoth that does it... 
But you can make the player drunk with some console commands I can't remember just now. C shift and Bob speed or something.

I usted them in a�n e3m4 remake During the posponed section. Will dig them out and post in a bit. 
But you can make the player drunk with some console commands I can't remember just now. C shift and Bob speed or something.

I usted them in a�n e3m4 remake During the posponed section. Will dig them out and post in a bit. 
Completely Wrong 
It's a single one - v_idlescale. 
I recall there's a power up in Quoth that does it...
This is not quite correct. It appears this way in Darkplaces, because the engine automatically applies view warping when v_cshift is used, but this is not true in all engines. 
Didn't know that. Is that for the Trinity? 
actually, on second thought, my last post might not be entirely correct.

I noticed it on a different powerup I was making, but that powerup uses the same cshift values as stock liquid 'haze' colour, so it might be that DP is trying to fake waterwarp on 'fake' water effects (ie: if a mod tries to fake water with cshift). 
Thanks for all the feedback, I went through the Ftiz source looking for clues. I found all the v_cshift stuff but could not work out where the warp effect was coming from. I assume it is a point content check somewhere and a special routine to do the warp effect.

@ijed, thanks for the console command, that is very cool, I will try that on lower settings so the screen is not completely static. It is a shame there is no console command for the warp, it would have been the icing on the cake for my setup. 
Look Forward 
To seeing whatever it is. 
What's the best way of having a message pop up? Let's say like 2 or 3 times with a little delay between beeps? 
Skill Levels 
I was wondering... A program to read the .map file. Assign the quake monsters a difficulty rating of 1-10. Have the program count each using the appear flags. You could get the relative difficultly at each skill level.

Another idea. Is there a way to keep score? Count up total damage done at the end of a map or even have running total. 
That would only give you a very general idea.

Consider an ogre on the same height as the player vs an ogre on a ledge above the player.

Consider fighting a shambler with LG vs fighting a shambler with a DBS. 
Has This Ever Happened To Any Of You? 
Resuming, Worldcraft 3.3 + qadapter by Baker doesn't save.

Actually, it's more like it reverts to a previously saved stage.

Example: just yesterday, i was mapping all the evening, saving over the old archive always and testing the changes frequently, and closing the program 2 times on that time frame without reseting. But after seeing that it's going to be dark soon, i save again and close the Worldcraft. I remember i forgot something to do, i load the program and the map again, only to see that the map is at the stage that it was in the middle of the evening. It just choose one random one. I don't think it's related, but if i try to load the .map on Quark to check if the truth is that the last save is still there, it gives me an error and doesn't let me check it. I'll try with Radiant next time. B the way, the .bsp is fine.

I do think it happened again some months ago, when i copied a different map to another computer. This time it reverted to a stage one week previous to the last one when i copied it back into my computer. But i'm not sure about this last one. I still have to check into that other computer.

If anyone knows of this, it would be a great help some advice, if this keeps on, i'll have to quit WC.

Thx in advance to anyone that answers. 
i save again

I call BS!

I have lost work before from not saving. You're not the only one. 
Maybe I Haven't Explained Myself Well 
I'll be more precise.

What im trying to say, it's that EVEN if I SAVE the map a LOT of times, it goes back to a previous save, not the penultimate, one or 2, 3, ... even before of that one. Not that it happens all the times.

I'll repeat the first example:
- 0) Run the WC
- 1) Work in my map.
- 2) I save the map.
- 3) Close the Worldcraft, completely.
- 4) Run the Worldcraft again, the map is there as i saved it in 2), no problem.
- 5) Work again on it
- 6) Save again the map
- 7) Close the Worldcraft again, completely.
- 8) Run the Worldcraft again. Load the map, and the map is like it was in 0), but we know that WC saved it in 2) because in 4) we saw that the map was saved.

Is it clear now? :) 
Count Up Total Damage Done At The End Of A Map 
Yeah, wonder why we still don't have a QC or engine mod with more elaborate stats a-la DM: damage done/ received, accuracy for each weapon, items picked up etc. Would fun for players and helpful for designers. 
I have no idea! That's fucked up. Are you sure you installed Worldcraft 3.3 and not Witchcraft 3.3? Have you tried using Worldcraft 3.4 instead? I don't know, but if that's a bug, maybe they fixed it in 3.4....... 
Open a dropbox account and save your levels there - that will give you an extra backup if things get lost or broken.

In fact, let me invite you so I can get more free space! 
Mind You 
Might not solve your problem.

Personally I find it's better to save everything to the cloud in any case, just in case. 
necros: I was thinking just for level design a quick way to see whats going on enemy wise at various skill levels.

RickyT23: "Witchcraft 3.3" :) it feels that way sometimes late at night when you should have just gone to bed.

slapmap: We should have stats. Might make SP more competitive. 
The only advantage to Worldcraft that I see now is the extra texture information, and making very accurate (non terrain) large brush structures. Other than that I find the workflow is very slow in comparison to TB and it doesn't really support complex terrain (amongst many other things).
Personally I haven't used WC since trench came out. 
Thx For The Answers 
I'll probably try to mend this by using ''save as...'', for making different versions, and saving things to another places. I use to do that when working on 3d modelling so i could go back to a previous stage, not that this give an noticiable advantage when mapping, but can be useful.

Fifhtelephant: i should try at least TB, i did try Quark back in the nineties but i didn't like it, but after so many ears with WC is hard to change.

Ijed: that's a good idea, i'll think about it. And i'll do too about your offer :)

RickyT23: about the 3.4, i read that it doesn't provide anything useful for quake mapping. I looked too at the changelog and haven't seen anything about bugs. I read too that 3.4 is considered Hammer, and Valve doesn't give permission to make maps outside HL with Hammer.

Back in the nineties i thought too that it was Witchcraft 1.2, with so many errors and issues at the compiler that i didn't know about.

Now i know most of them thanks to so many useful documents on the net. There is still one that i don't know how it works, after checking everywhere and in the document that is provided with issues for Beng Jardrup tools too: it is the ''can't find /id1/maps/yyy.bsp, there is no such file or directory'' that shows at the compiler and stops it. I usually fix it by removing the last brushes i put in, but it's weird, it shouldn't be related to that. 
I Have The Hammer 3.4 Exe 
You can drop it into the Worldcraft 3.3 directory and it works well.

I can confirm one difference - the pointfile loads and is visible in the 3D view of the editor. This feature does not exist in WC 3.3
You can load a pointfile but it is only visible in the 2D views. 
I uploaded this Hammer 3.51 the last version of Hammer 3.x I found. I converted Quake models to HL format to have them show in editor (not very good conversion). The leak file support is good. Saves time because you don't have to do a complete compile to find leaks. Stop the batch file after the leak is reported and load the pointfile in WC. 
Glass Hacks 
A lot of people are going to great lengths to hack in support for glass in the their levels, usually this requires setting water alpha or some other such thing and also using skip textures. And coupled with this much larger than normal polygons you will almost guarantee that a new engine is required.
So this begs the question, why go to all this trouble when the most popular engines support alpha brushes? I literally just found a post on inside3d saying fitzquake supported this, so does directq and RMQ...
I must have spent a good half-day this week trying to implement glass in a hacky way when I could have simply applied a key to determine the alpha of a brush.
Is there something I am missing here for all this hacking trouble? Why not just use an alpha key? 
Would be the biggest reason I suppose. The water "hack" works on all engines, whereas the .alpha key works on most, but not all.

The joys of custom Quake engines and all their different standards :D 
It Seems To Work 
in RMQ, quakespasm, directq, fitzquake and darkplaces (afaik, untested but apparently it works).
It doesn't work in Quake Pro and Makaqu (and qbism by that extension).

I understand that it's a compatibility thing but if you use a texture with alpha then if your engine doesn't support it then at least you get a nice texture instead of a completely flat coloured surface. I seem to be missing the point in catering to bad engines with a bad solution.... 
Setting Brush Mirror 
would be awesome if you could set up a brush with a mirror in the exact same way you can set up a window. Coupled with transparency and coloured lighting you could effectively mimic Unreal. :P
(all we'd need after that would be uv motion textures and in-map skyboxes) 
Far Concern 
I understand your concern for the wicked way to add glass in the Quake1 world.

I remember I was already glad to add a trigger_once with health 999 to propose the glass feeling of a space where there was nothing, but didn't let through.
Caught up in the old times of the QuakeLab on BBS in 1996.

I'm not a perfectionist and I'm sure there are lots of ways to use the alpha channel in a brush and tell the engine to add water_alpha 0.4
I think it's more like not suspecting an 18 year old engine with primary limitations can do things like that.
There's the console command, or the autoexec.bat for in use.

Also there is a slight feeling I get that in time of the quake area like medieval, glass was quiet a rare object.
It would be the same like wondering why the knights don't caugh frozen breath in icy environnements.

But I won't break you up in your search to engine upgrading, that was not my intention. 
You make a good point about glass in Medieval periods however the Wizard, Stucco and perhaps the Base levels (although I'd rather do the Hipnotic \ Custents Force Field effects if given the choice on Base levels) all have window textures in the original levels so the idea of glass is already there so it may not be all that out of line with the environment.

Besides that it's supposed to be another world with some familiar aspects relative to Earth so a little bit of mix and match is to be expected.

Or maybe U;m over thinking it... 
U;m - I'm 
...whatever. Note the icon. 
Preach You Are A Genius! 
Post #3923 worked perfectly for a switchable trigger_teleport entity I wanted. I seriously hope you got the essence of that post on your site.

Also is it possible to safely kill a monster_jump entity with a killtarget on a trigger_once? Is there a way to stop the touch function of the monster_jump entity and then kill the entity next frame? I am looking for a map hack solution. 
Oh Man 
That's a bit of an out of date method, the following post has a much more concise way of achieving the same thing:
And yes, you can safely kill a monster_jump to turn it off, it's just a pity there isn't a way to toggle one instead. 
Monsters Spawning Monsters 
Works like that in schism, thanks to the precache insight. They have separate precache functions that are called from their classname, and I'm still not sure I understand how it works.

Gb did the work, based on Preach's stuff. Now much later I'm using it for splitting tar babies and enforcers spawning their own defense drones... 
That Was Interesting! 
Did not know that. So I can trigger a trigger mid map using vanilla progs! 
Ex-rmq Monster Spawning 
I think the RMQ monster spawning was based on Scourge of Armagon, Drake and some of Necros' stuff in Chapters.

Not sure how much Chapters / Quoth has taken from Scourge of Armagon, but I reckon SoA was the first mod to do the monster spawning stuff.

I believe there is some SoA and also some custents in Quoth, or at least in Chapters.

By the way, some of that code is horrible, especially where it clones an entity. There are engine extensions MUCH more effective for that purpose... and faster. But it depends on the target engine. 
... just like entity alpha. :-p 
The original spawning code borrowed very heavily from hipnotic.

I used custents for that first map I made. It's a great mod with a lot of interesting things in it, but you are better of picking and choosing things from it rather than using the whole package because there is so many things you probably won't need.
it's also a great mod to see some things that are not in stock progs.dat and can give you some ideas for other things like the mechs and security cameras, or the new gun. 
Q3map2 Sunlight Entity Problem 
I'm stumped on this.
So I've made a light entity and pointed it to a info_null with targetname "pointsun".
It's got the _color and _sun tags set. No spawnflags.

At first it flat out refused to work, and now suddenly it turned into a big pulsating light out of nowhere? What the hell am I doing wrong? 
Okay, apparently I had something else pointing to it. It's a sunlight now, but it's still flickering. I thought vanilla Q3BSP didn't support lightstyles? 
Hmmm, seems like a compiler fluke in the generated shaders. No idea how this got in here.

// Q3Map2 custom lightstyle stage(s)
map $lightmap
rgbGen wave noise 0.5 1 0 5.37 // style 32
tcGen lightmap
tcMod transform 1 0 0 1 0.00000 0.50000

Bah, that took too long to fix :( 
Use a sky shader for sunlight. :) 
Alpha Mask Textures 
I know RMQ engine supports masked textures (to make fences and such), but which other engines support it? 
And FTE, I just checked. 
I had a look anyway after I posted. It seems this is a standard feature of RMQ and anything that forked from fitz after a certain point. 
Yeah, using sunext and skylight now with all the bells and whistles :) 
Deathmatch Map 
While waiting on the Quoth update. I'm thinking of doing a DM map. I want bot support because I don't DM. What would be the best bot to use? I want to use waypoints. 
Has a nice waypoint system.

You build it in-game by placing points then dump it to an external .way file that you bundle with the level. 
Sounds good. I think I played with that on a few years ago. 
GTKRdiant 1.4/1.5 Elevator 
Hi iam just wondering if there is anyone can tell me on how to make an elevator lift that i make? I know it is a noobish question but you can contact me on x-fire blueultima thank you for anyone able to get back to me. 
Build the elevator in its extended position (up) and make it a func_plat. If it has a cylinder to the bottom, you're set. If it's a floating elevator, set its height key to determine the moving distance to the ground.
With the plat_low_trigger spawnflag, it can be made to only start moving when stepping onto it from below, otherwise it will also start moving if you jump down the shaft. 
The Power QuArK

This is really interesting 
Any tutorial that starts with 'set the grid to 1 unit' should be cause for alarm. Nothing about those pipes are done correctly. 
awesome scamps...

I have to say I really should get some pipe prefabs made up (especially if I do any more base maps). It'd be nice to have a 2d brush shaper/rotator tool like in UED. 
I didn't see anything wrong with the tutorial's end result though. Quark users should check out:

follow the links, could be useful. Grid at 1 unit shouldn't be a problem. I'm making brushes at 0.2 units max thickness, all on grid for .bsp models. 
i didn't know arghrad had phone shading:
Arghrad's Phong shading feature allows smoothing on rounded shapes. Two conditions are required to obtain this effect:
- each face must have a light value >0
- the texture must be wrapped without break

I think better criteria would be to have some critical angle on which phone shading would be applied (let's say 45 degrees). I wonder if that could be added to other light utilities? 
that's how q3 light tools do it.

Arghrad works but is very manual, you can effectively make any edge "soft" or "hard" by carefully setting adjacent faces to have the same or different light values. 
Apparently Quark doesn't fuck up on rounding float-point like most other editors do.

Necros: Q1rad does that (essentially a HL light compiler made to work with Q1 BSPs) 
yeah that�s neat! 
i was hoping to get that functionality in a modern light util though... i'd really like to keep all of aguirre's enhancements as I couldn't do lighting without them. 
Quark has the same problems with floating point coordinates as other editors, unless it knows magic ;-). What does Quark do better than other editors? 
Quark doesn't mess up brushes on non-90� rotation. As that tutorial in particular shows it works fine, but wouldn't work in any editor I know - Radiant, WC or BSP - the rotated brushes would be slightly distorted and unaligned. Apparently Quark has better precision.
Also Quark has 3-point float texture coordinates keeping the textures aligned even with rotation.
I'm not a quark guy, don't know what else it does better. 
is also very well implemented. 
You're talking about two different things. I'm not sure about BSP, but neither WC nor Radiant support floating point coordinates at all. That's why brushes get distorted when you rotate them.

Quark allows floats for the plane points that define a plane, but that comes with its own set of problems. It can cause microleaks. It's not a problem for pipes, but as soon as you have brushes with floating point coordinates which are supposed to seal the map, you can run into all sorts of problems. But maybe Quark fixes these problems somehow?

The texture alignment thing is actually because Quark implements the Valve 220 map format, which later versions of WC also support. 
Marksurfaces Are Evil 
and that's all I'm going to say about that.

When I started this map I made a promise to myself that I wouldn't exceed any of the normal Quake engine limits. I figured if I had no limits, I'd probably never finish the map (been working on it since 2007, so maybe that logic was flawed).

I've been re-texturing the map and in the process I made a few (very few) changes to the brush work. I'm absolutely certain that the changes reduced the number of actual brushes and visible faces, but the marksurfaces increased from 31763 to 31892. That's over 100! I only changed like 6 brushes. Very annoying.

Some adjustments to the geometry are unavoidable in order to work with the new textures, and I'm probably less than halfway done at this point. I sure hope I don't hit the limit before I finish the re-texturing. 
Skirting The Limits 
I think the issue is that the number of marksurfaces can be affected by the order in which brushes are compiled into the map. It's an unstable algorithm. Deleting a brush might move another one higher up the compile limit, where it doesn't fit as efficiently.

Has anyone ever tried permuting the order of the brushes in the compiler, either according to some design (like sorting on the x axis or largest to smallest volume) or even randomly? Given how much faster bsp is than vis, I'm sure that running the former a few dozen times with different orderings would not be a big burden. If you have a target like marksurfaces in mind, you can then take the ordering which maximises it.

I suppose what with the map format being basically text, you could even do it with some kind of script. Generate a bunch of permuted map files, compile them all in turn, and keep the one with the best output... 
Yes, the order seems to matter. Already ranted about this for my MCE map. There were times where I had to move newly inserted brushes further up the list to bring the count under the limit. But it's also about the brushes' 'relationship' between one another, so to speak.
For, at other times, moving the monster teleporter room up and down in 8-unit steps would influence the marksurfaces.

Even supposedly neat or clean brushwork sometimes turns out to be counterproductive in this sense. It's really strange and really annoying.

The QBSP in rebb's BJP mod features an experimental switch that changes the algorithm somewhat which can reduce the marksurface count considerably. In my case, it was around 1000 lower - I didn't notice any issues this may have introduced. 
that -forcegoodtree switch you mean?
seems to work. 
Interesting Urgent Needed 
hi, not the proper thread but haven't found any better

Quake Gpl exploit for my own commercial game:

1)what if I use Quake original �knight� model base and animations(idle,stand,attack,..) on my own model ??
frame coordinates numbers are proprietary assets?!

2)And, a bit paranoic I know, should I delete original Quake references (frame names, monster names, sound wav,..) from .qc files ??

of course with my game I would do myself all graphic assets(monsters,textures,levels)

Liquid That Moves 
One quick question. How do i make a liquid brush that moves, like the one at the start map of Scourge of Armagon?

Everything i tried until now makes the brush solid. 
I Have No ID, But I Like Caramac Candybars.., 
1)if you only change the tex set and keep original animations or even base models, I don't think so.
If you make your own mmonsterarium, own animations and textures, why not

2)For code I think it smart to write your own, rather than keeping originals.
New monsters are reliable when standing on own ground.

don't forget your own weapons and callibration. 
First level of Scourge Of Armagon - The Pumping Station -

Tell me where are the liquid brushes that move? 
it's one of Hipnotic's feathers in the qc.
you can use it by using the progs.dat from the Scourge of Armagon,
or be clever and extract it from the hipnotic.qc and use it in your own mod.

Source Scourge Of Armagon => hipnotic.qc
download the Hipnotic DevKit. 
all you need is the HIPWATER.QC and add it to your own qc file.

If you open the start.bsp you can see it added as:
model func_bobbingwater 
But for now i'll have to pass on using it. I'm an almost complete newbie, the hipnotic.fgd that i got from Quaketastic isn't loaded by WC, and this is for SMP_170, and i'm short with time already.

For the next time i promise that i'll check better the list of entities in the Forge, that entity is there and explained.

Madfox, check 12914 again, i said start map, not hip1m1 map. :) 
/*QUAKED func_bobbingwater (0 .5 .8) ?
Used to emulate water. To use, create a thin water brush and center it
on the water line of the body of water to bob. The amount of the bob
is the depth of the brush.

The hipnotic func_bobbingwater QC code is NOT moving water. You can create moving liquids but you will need a special QC/entity and extra functions in the client.qc file. 
Staggered Teleport Times 
if I wanted to stagger when monsters teleported in would I be best using trigger relay or something? I tried putting a delay key on trigger_teleport but it didn't seem to work :-/ 
I have a really complicated way of teleporting monsters into a fight in the map I'm working on. They're on a door that moves sideways slowly when triggered and they're separated by small walls that keep them from moving. As the door slides out from under them, they fall into the teleporter brush. Sounds complicated but I can teleport in pretty much any number of monsters with an adjustable delay using just 4 entities. Can be tricky to make sure they don't telefrag each other though because they all go to the same teleport destination. It could be set up to use multiple teleports though. 
@Cocerello - I compiled the hipwater.qc file with the bobbing thing, and original Q1 v106Qqc a new progs.dat.
I made a map with
classname func_bobbingwater
and copied a polyhedron tex +water02 in it.
It works fine and you can find the progs.dat down under.

@Sock - I'm not sure what you mean?
I compiled the hipwater.qc with old v106qc and proqcc, and played with a classname func_bobbingwater, and all goes fine.

you can find the hipwater progs.dat here 
Moving Water 
I used the Pox Extras moving water in FMB-BDG2 that I released recently, and it was quite effective for giving the effect of flooding an area. There were some issues regarding viewing the surface from within the moving brush i.e. when you're swimming under the water, but this was eventually fixed within the map quite easily.

Search for 'moving water' in the Mapping Help thread for some details. 
@MadFox, func_bobbingwater is not a liquid, it is just a moving brush model with a liquid texture. If the player touches this entity they will fall through it.

@Mike, This is why I wanted to see your qc source, I was curious to know what stuff you used. I had a look at the Pox stuff and the func_water is very interesting. I like the idea of switching gravity to emulate being inside of a liquid, I have a different solution luckily! :) 
Is great, we included it in RMQ as well.

func_watertrain and func_water not only work, but also have other controls like giving the player drag or force (flowing river) and a custom c-shift for mud / blood / whatever. 
Sure, the pox mod has these advantages also.

But it doesn't have the easy-way of extracting one qc file and add it to your own. At least there are three other files involved, so the tweaking gets harder.

I used the func_movewater in several maps but it only works for small sized brushes.
Also sad the watertexture doesn't animate.
I made a special texture for it.

Adding the pox mod to my own map included a large quantum of other funcs I didn't need.

And afterall.., I got curious after Cocerello's question and then I started investigating.

Didn't knew the water effect of the hipwater.qc was only a fake for eyecandy. 
Staggered Teleport Times 
In the original Quake they used a bunch of trigger relays with delays (in e1m7 for the gibs fountain effect in the episode closing scene). To see it being used you can download the released map sources from Romero and see how they timed it. It's mostly set up in the room that the player cannot get to. 
Moving Water 
The Pox moving water is not animated the same as standard Quake but it does move.

I used a brush that was 2496 x 960 x 272 without any problem.

I didn't use the 'mangle' (current) as the player has to turn several corners whilst under water.

The easiest way to use the Extras is to incorporate them all if you don't want to fiddle around. I think my progs.dat ended up at 750 - 800K, and I had most of the Extras in there even though I ended up not using much of it in the game.

I thought it worked quite well (although that's only my opinion). I don't recall anyone making any comment about it, so it must have been acceptable to everyone - can you imagine someone here NOT saying something if it was tosh? 
[Darkplaces]Help With Sizing Textures In NetRadiant/q3map2 
Hey guys, sorry if this thread already brought this up before, but I'm making a new game and I want to make some new map textures. I can get as far as getting all the textures into netradiant but for some reason they won't size properly.

They do connect and cover the whole brush in a pattern but they are way to big. I tried experimenting a bit by including some PK3s from Xonotic and they sized correctly with no modification, but when taken out of the PK3 they did the same as my textures.

I also tried the surface inspector but that only downsized them to a certain degree. Any help? 
Anyone Got A Fix For The Timing Issue With Path_corner's?? 
Apparently there is a 0.1 sec delay at path_corner's due to this pesky bugger in SUB_CalcMove:

if ( (tdest == self.origin) ) {

self.velocity = VEC_ORIGIN;
self.nextthink = (self.ltime + 0.100);
return ;


and it's adding some stutters to setup. :) 
Early Over 
The only way I can see to do is use some kind of hack to run SUB_CalcMoveDone on the func_train as soon as the new destination is reached. The difficulty is seeing where you might stuff the hack! There's no way (I know of) to set a custom "use" field on an entity which is SOLID_BSP, as all the functions which make an entity SOLID_BSP change the use function at the same time. Have I forgotten a way where you set SOLID_BSP as an entity key and then find a function which runs setmodel without changing the solid status? Negke?

th_pain and th_die are easily applicable to a standard func_train, but you'd need some way to prevent anything else inflicting the damage. Similarly touch is going to be useless if you need the player to stand on it. think and think1 are used by the func_train anyway, so they're out.

Best bet I can think of is trying to make one func_train style entity which surrounds and follows another, damageable func_train. Then you. The inner core is damagable but the outer core protects it from general attacks. The only thing which ever gets a chance to attack it is a hacked info_notnull which goes off inside it when you need to skip the delay. The details there are a bit vague though, like how to make one func_train follow the other. 
press 'P' - brush - default texture scale
.shader scripts can change default scale of individual textures 
I Think I'll Just Resort To Qc, Create My Own Version Of SUB_CalcMove 
and a custom func_train_qma or something...only problem is that I want support for a handful of quoth monsters too. I guess I can decompile the quoth progs and create my own mod and scavenge the models and sounds. Anyone done that before? Not exactly ideal though. 
It's Just That... 
I have to have an exact number of path_corner's for set1 in order for it to mesh properly with set2. Having an exact travel distance is no issue, but I really really don't want to have to recalculate the whole setup again to get rid of the hiccups on what would be a smooth operation. 
Entity Precision 
How many decimal places does qbsp retain in entity fields. For instance I'm using a wait value of 5.639025 (Don't ask) and I'm wondering if it's getting rounded because I'm getting some wierd behavior. Also, do all objects start on the same frame? Like monsters on walkpaths, func_trains with no targetname, etc.? 
Forget it! Don't even try to pair func_trains up when their travel paths aren't exactly the same length and same # of corners. Must be some sort of engine rounding bias because at first it will work perfectly fine, everything all lined up. But after several loops it gets out of sync one side or the other. I managed to zero in on a figure that works for about 10 loops: 5.6390295 but I can get almost 15 loops out of 5.65. ???

Back to func_door 
qbsp saves all entity fields as strings; and i'm pretty sure it just copies whatever is in the map file without changing it. (though there is a limit of 1024 chars per string, but you're definitely not hitting that limit.)

In-game the wait time is stored as a 32-bit float, which should almost store your exact value. According to this page, your value of 5.639025 will be rounded to 5.6390252 or floored to 5.6390247, both of which are very close. 
Floating Point 
Quake uses standard 32 bit precision floating point values for all entity fields. That's 23 significant figures in binary - good enough for about 7 places in decimal. So yeah, not nearly enough for what you're trying to do. Also remember that your set-up will break if one of your trains gets blocked by a player for a few frames, and the other doesn't. Custents has a synchronised func_train entity which is designed for keeping multiple trains in lock-step - the example they build is an escalator.

Interesting side note: the engine does track some quantities in double precision. One of the most important is the server time. Since it's constantly having small increments added to it, there's a need for higher precision. QC of course can't access the value at the higher precision, but it still benefits from the better tracking. 
But what's Custents?

Player Blocking: Not an issue for most of my...super special stuff. I do have some timed crushers though, should these be func_doors? I haven't had time to mess with the crushers yet. 
A classic mod with a mixed bag of custom entities:
Warning: 1998 web design.

The downloads page points to a dead ftp, a live mirror can be found at 
It sounds like you're jumping through a lot of hack-hoops when a bit of qc will solve most of it.

There's also extras r4 (mentioned on another thread recently) which also has custom entity extensions. 
There's nothing wrong with jumping through hoops if you so enjoy. On the other hand, I'd say that something which is evidently hard to get right even in QC is probably not amenable to entity hacks. As opposed to yesterday's currency challenge, which is easy to do in QC and so seems ripe for a hacking challenge. 
And I do appreciate the challenge of figuring out a puzzle. But with time I've got more impatient, often preferring the direct solutions over the more complex options.

Horse for courses I suppose :) 
Hoops, More Like Jumping Through Q's 
I just want to get it working smoothly any possible. :D It's a pain enough having to calculate distance-between-corners/train-speed to get time-travelled in order to know how much wait to give path_corner's for these trains to meet up properly. 
Are you trying to do?

From what I can gather from the posts it sounds something like these:

Though they didn't do anything apart from go in a straight line :P 
seriously, you should check out custents, it has everything you are talking about.

you can specify a train to move so that it gets at it's destination in a specific time instead of telling it to move at a speed, and there is a setting to remove the delay when it hits a corner. 
Got It! 
Thanks! Looks like it might work!

ijed: shhhh! It's a surpise! No nothing as simple as alien birds. 
Fair Enough 
RE: Slapmap 
Thanks, I've been looking for that option. 
Brush With No Texture 
Hey guys,

I'm designing a map called "maw of madness" and as the title of the map suggests I want to give the player the feeling of being swallowed by madness.

As such I want to use the waterwarp effect in certain sections of wall. However, I don't want the wall to be traversable / swimmable. Is there a way to make completely (not semi) transparent walls? a brush with no texture or an opposite of func_illusionary?

Thanks in advance,

You have two methods to choose from.

1 - Clip brushes

Make a brush and give it the clip texture. The player will not be able to pass through this brush, and they will not be able to see it.

One bad way of making a ladder is to make a detailed ladder as a func_illusionary. Inside the ladder make a set of steps that are 1 unit wide, and put it inside the ladder. When the player walks into the ladder they are instantly transported up the invisible staircase (just like a normal staircase, but all of the steps are within boundaries of the ladder's space, so the player moves upwards).

2 - Skip Texture

Make a brush and create a texture with the name 'skip'. Apply the texture to the brush. The brush will still be there, but it wont be drawn. You can use this tool on individual faces too. And you can apply it to brush entities, like doors for example. This can be used to do all sorts of things in Quake.

When you compile the map, you have to run the newskip tool to remove the faces. Created by Metlslime: 
Skip-textured Func_wall 
Then run newskip or compile the map with these tools to have the skip texture removed automatically. 
Note About Clip Brushes: 
You can shoot through them. They are great for putting diagonal brushes against pillars, for example, at the side of a corridor, sticking out of a wall.
Ever start shooting a monster in a corridor and you are moving backwards and sideways and you get stuck on a light or something? And you die because you got stuck and pwned? A well placed diagonal brush can prevent this from happening as easily, because you just glide over the thing that is sticking out of the wall.

I should do this more often :D 
or jsut make the water out of func walls with water texture on them -- it will be solid and block bullets but render as water. 
Thanks guys, learning all the time :)

In a few days I'll throw a deathmatch map I've been making up for critique. The basic geometry is done, entities are done and lighting is getting close.
I'll upload with the mechanics all finished for critiquing before finishing the texturing and decorative brushes. 
Put Some Monsters In! 
What Ijed Said 
What RickyT23 Said 
What Drew Said ;) 
What Others Said :P 
Warning: 256 Models Exceeds the Standard Limit of 256.

Okay, so what is it really? 255? Or do I actually have more that 256 and it's just not telling me? 
It will still load in unmodified ports despite the warning. You just can't add any more if you want to keep it vanilla.

If this or any of the other limits become a serious problem in your map, feel free to give me a shout. It seems I'm getting pretty good at optimizing these things... :P 
If You Have A Lot Of 
func_illusionary details, try grouping some of the ones that are close together into one model. 
I well understand the limits and have gotten pretty good at optimizing stuff. What I was pointing out is this:

256 exceeds 256

Which it actually does not.

I'm guessing it has to do with counting that starts at zero instead of one. I probably have 257 models.

I've been adding one unnecessary func_wall off and on over the last several builds just to see how close I was to the limit.

I'll take one out now and the warning should go away.

Nevertheless, 256 is not more than 256

The good news is, I still have 5 or 6 models left to play with :) 
It's probably a counting issue and a bug of that message. The index would 0-255, the range of that is 256 items. So the model with index 256 would be one over the 0-255 range as it is actually the 257th model. 
negke: are you sure > 256 models loads in engines that don't support it? i remember having to remove bmodels from some maps like nesp09 because there were over 256 and it was crashing the engine. 
What I meant is that a map with exactly 256 unique models will still load despite the warning in Fitz and BJP. Anything above that number will cause a crash. 
It might load, but I suspect that you'd have problems with model 256. The limit is because vanilla quake sends the model value as a single byte over the network. If you try and send 256, the server's going to send 0 instead - and 0 is interpreted by the client as "no model". As long as you're happy with the last model only being visible in engines with higher model limits, you can have 256. 
the message is slightly buggy i think. The true limit is that a model with index >255 will break the network code on protocol 15 (you'll have some invisible entities.) So 256 models is okay, 257 is bad.

The bug in fitzquake is I used >=256 instead of >256 as my check for displaying that message. 
As we were talking about it in the thread of mfxsp6 and in others, i became more curious about it, and want to know more before i get this one in my maps. So i ask:

What is HOM exactly? What causes it? How do you fix it? 
it's the polygons that are not being rendered.

this happens if you have erroneous brushwork: too little trianlges, too many intersecting edges on one face, textures of various nature touching each other (water+sky or something). or just huge room with too complex geometry, bsp-vis compilers just can't cope and make erroneous polygons.

so just build clean and simple and with r_speeds in mind and you'll never get this hom thingy. 
It stands for Hall Of Mirrors. 
I don't know about other engines, but in Fitzquake if you set gl_clear 0 and noclip outside the map, there will be HOM everywhere that's empty space and you'll see why it's called "hall of mirrors". 
I had an idea about doing it on purpose using skipped textures. For that crazy 'down the rabbithole effect'.


Has that been done yet? I think it could work really well, maybe having chunks of other realms in weird positions as the player moves through some sort of rift. I nearly had a go on my last release. 
for me HOM as an effect is ruined by it's associations with errors, problems, bad mapping, whatever 
might be interesting as a breaking the fourth wall type of map 
Marksurfaces Are Evil Part 2 
Okay, I've been having to go very slow with making changes. Basically I'll make a few changes, only in one particular area, then copy the map over to my fast computer and BSP it. If the difference in marksurfaces is reasonable, I keep going, otherwise I start hitting the undo button.

Today I cloned a light fixture, not very big and kind of detailed, made from about 12 or 13 relatively small brushes. Connects to the wall at a 16x16 section of brush.

Copied the map and ran TxQBSP. When I saw the marksurfaces number I almost fell out of my chair. The increase was from 32,258 to over 33,000 !?!

Started thinking, well that light fixture didn't really look too good in the map, and there's two others exactly the same, I'll delete them all and maybe get a reduction of a thousand or more marksurfaces. Wrong.

New marksurfaces was only about 100 less, which is probably pretty close to how many surfaces there actually were on the two fixtures.

I'll take what I can get, back to mapping. 
More Marksurfaces Stuff 
I worked at trying to reduce marksurfaces all day yesterday. It seemed like every time I simplified brushwork, the marksurfaces went up. I remembered negke's comment about rebb's modified txqbsp, so I downloaded that and gave it a shot. Magic.

Using the -forcegoodtree switch I got an immediate reduction from 32,266 to 31,763 with no other changes. That's some breathing room. Which is good because I had more stuff to add that was absolutely necessary.

I added another small room with an elevator and an arched doorway. I recompiled the map and... more magic. Marksurfaces went down again, by over 250!

I'm now at 31,507 and I think my marksurfaces problems may be over because there's not much more stuff that needs to be added.

I did a full compile and played it through to the end, looking for any bsp errors the whole time and didn't see any problems at all. 
So pumped to play this! 
Rebb Did Some Good Job There. 
BSP Tree Hug 
It's still very much an experimental switch, but it does help with marksurface counts - the only side-effect seems to be a somewhat less efficient PVS in some cases.
A few well placed hint brushes should help if needed though.

It would be nice if someone with a much better insight than me into the dos and don'ts of BSP creation could take a peek at the code ( it's a super tiny change in qbsp.c ) and confirm/deny if this is actually a horrible idea ;) 
..sorry Maybe An Outdated Question 
Do guys know if and what version of the programs QME and WORLDCRAFT may be used in commercial works ?

tHaNk in advance 
A Bit Of Bsp Theory 
I've done a few practical experiments today to test how BSP responds to the order of the brushes in a map, so I'll write up and post all about that later - and hopefully explain why adding a brush can reduce the marksurfaces. For now, a bit of reassurance for rebb.

Once the compiler has created a list of surfaces from all the brushes in the map, it has to decide which one to compile next. It has two methods of choosing the next surface to split along, which we will call "fast" and "slow".

The slow way is easiest to explain. It tests every surface in the list, and checks exactly how many splits will be made. It then chooses the surface which will create the fewest splits.

The fast way is more complex conceptually, but quicker to compute. The engine looks through the list of remaining surfaces to find the ones which are axis-aligned. Of these, it chooses the one which best splits the area of the map into two evenly sized halves. If there are no axis-aligned surfaces, it just takes the first remaining surface.

The old rule for the bsp tool was to use the slow way for the visible surfaces, on the grounds that reducing visible surfaces matters. For the clipping hulls the fast way was chosen, either to save compile time or to make a more balanced bsp tree, not sure. However, once you're running up against the marksurface limit, then minimising the number of splits in clipping hulls suddenly has value. This is where rebb's modification pays off, as it applies the slow way everywhere.

Fun little idea which has seems to hold up from all that above(bear in mind I'm not that knowledgable on bsp stuff): If you've got big chunks of map with trisoup walls, maybe a cave...if you build some nice axis-aligned brushes to contain the cave walls, even ones which will eventually be clipped away, that ought to improve the compilation in the "fast" phases of compilation. Those brushes should be compiled early, and act like proto-hint brushes.

So coming soon - why all that minimising splits stuff is not what it sounds like. And how adding brushes can reduce splits! 
How To I Make Enemies Spawn? 
What if I want to put an enemy into my map (I am making a Quake 1 map) that doesn't appear (or "spawn") until the player walks over or activates some kind of trigger? 
For Vanilla Quake (i.e. Not Quoth) 
Make a box room in your map, put monsters inside it. Over each monster make a brush entity 'trigger_teleport' and set a 'target' key on that entity with a value of 'Jeffrey' (or whatever). Give it a 'targetname' of something like 'triggerJeffrey'.

In your map make a point entity 'info_teleport_destination' where you want the monster to 'spawn', and call it 'Jeffrey'.

Make a brush entity where you want the player to trigger the spawning. Make it a 'trigger_once' entity. Give it a 'target' key with a value of 'triggerJeffrey'.

Now when the player touches the trigger_once entity, the teleporter in the hidden box room with teleport the monster to the info_teleport_destination. :)

If you are using the Quoth mod, just put the monster where you want it to spawn, give the monster a 'targetname' of 'Jeffrey', and check the 'delayspawn' flag for that entity. Now you can target the monster with a trigger_once brush entity and it will spawn when triggered.

:D :D :D 
Thanks, But... 
Thanks for the help I will try that out!

However, there is one thing I was wondering in regards to the editor I am using (NetRadiant). When I go to "file" there are 2 options I am interested in know what mean. They are "save selected" and "save region". What do those do? Can I save only selected parts of the map or something? 
More BSP Stuff 
So here's part II of the weird and wonderful world of BSP Algorithm weirdness.

If you already know about Greedy Algorithms you can skim through this as it won't teach you much that's new. I hope that it will answer that burning question of how deleting brushes can increase marksurfaces - and please let me know if you are curious but part of the article was incomprehensible! 
Practical Experiment 
A little func_ bonus content from that blog post. I tried some very simple experiments into how the order of brushes in the map file affects the BSP output. It's easy to replicate, just create a single 6 brush box, with a 7th cube floating inside(texture this one differently so you can recognise it). Export the map, and use a text editor to cut & paste the floating brush entry up and down the brush order - you can create 7 different map files in this way.

I then tried compiling all 7 maps with Rebb's compiler, first without the new switch. In this case, there actually was a small change in the number of markfaces: when the floating box was moved high enough in the map file, the number of marksurfaces fell from 193 to 191. Yup, that's a 1% saving!.

When I repeated the compilation with -forcegoodtree turned on, the marksurfaces held at 177 for all 7 map files, but that's a 9% saving over the earlier worst map. Seeing no variation does not seem surprising after the last post, where we saw that the "slow" method considers all brushes at once. But there were variations in other quantities like edges and clipnodes. How?

Well, I can think of two possible explanations. One is that these other quantities depend on some other part of the compiler we haven't considered, and bit that is sensitive to order of brushes. I think the more likely explanation is that even when always applying the "slow" method there are still occasional "ties" where two splits look as good as each other, and the compiler picks one solely on order in the map file.

This is consistent with the observation that all the faces in our test are axis-aligned, so we don't ever test the code in the "fast" method which compiles brushes strictly in order. It appears that the variations in the former compilations were only due to ties being broken by brush order. The fast way appears to generate more ties than the slow way (which is believable from the code), and these ties might result in greater variation (an interesting result). 
Yes, that is what those two menu items do.

Save selected saves the selected brushes to a map file and save region saves the current region. 
Please Define 
Region selection is in the "View" menu. It's basically a way to hide large chunks of the map at once. You can select only a specific area to be visible while editing, this can de-clutter your view of the map a lot.

I've only used the "set xy" option, so I don't really know how the others work. The "set xy" will hide everything that's not in the current xy 2D view

I've never tried saving a region, can't think of any good reason why I'd want to. I guess it just saves the currently viewable stuff in a new map. 
Preach : Interesting ! 
Thanks for those articles, looking forward to the follow-ups :)

If it turns out that the experimental switches like "-forcegoodtree" are indeed not having yet unknown side-effects, like causing one's offspring to be born with a tail, maybe it could be implemented in other tools as well - the code change needed is very minimal. 
Ah - That's Like Hammers Visgroups 
.. has also this feature: it is possible to hide some part of the design in the editor (3 options are actually possible: visible, hide, or greyed).
Also, vis-grouping allows to be indeed more flexible. It is possible to build only a selected part of the design to check that it looks correct.
Well, I guess more or less all editors have this kind of features :) 
I've always liked quarks tree view that makes map components look like a file system. 
And Again... 
i still like quarks texture applying. 
Moving Platforms 
I tried messing around to figure out how to do it but can't figure this one out. How do I get brushes to move around like you see in many of the areas in the game? (Quake). I am talking about things like platforms that move back and forth and also things like those those cubes at the end of E1M2 that move around. How do I create those? 
thats a lot of questions..
head over to:

in entities you'll find what you looking for

googling the unofficial quake specs should be helpful too. 
func_train and Path_corner to be more unprecise 
Moving Platforms 
For platforms that only move in one direction like back and forth, or up and down, you can just use a door. For more complex motion you'll need to use a func_train with multiple path_corner entities. 
That's One Question To Be Precise 
Moving platforms are func_train entities. They move along an interlinked set of path_corner entities. The plaform starts at the path_corner it targets (if it has a targetname itself, it will only start moving after being triggered); each path_corner targets the next one, and the last one the first. If the platform is supposed to stop at the last path_corner, set "wait" "-1" there. 
Da Fuk 
Slow typer... 
Random Marksurfaces 
OK, my next foray into the realm of messing with BSP compilers, and the first real success (sort of).

Now with graphs! Yes graphs! 
Very interesting research into the BSP process, Preach.
It's weird how the results we so different from a box map and a full size one.

Have you tried this test with maybe some small maps like DM maps? 
Other Tests 
Afraid I didn't try any map in-between. I'd go and give it a shot now, although I expect that the result would be more like the latter than the former. Unfortunately I can't do that easily right now, because I've been revising the code for a future post, and don't have the original compiled at the moment... 
I was mainly interested in pinpointing where it started to become 'bad' and to try to pinpoint what it is about full maps that don't show up in box maps. 
Cutoff Point 
I may have some insight into that from the new tests. It seems like there's a very fine balance to strike with random input - it seems to work best for trying out different ways of resolving "ties". I guess that in the simplest of test maps there really isn't any difference between just tie-breaking and randomising everything - but I think as soon as you add any real detail then the difference matters. 
Just To Say 
I'm following this as well, thanks for the work.

Nothing solid to add though. 
is it possible to make rmq using some modern free engine?

i remember i've seen e1m1 on crytek eng 
Shit Wrong Thread 
And That Promised New Method

So here's the way I was talking about, it gets you some improvement, even in the average case, over the deterministic compile run. I'm pretty sure that because the randomness is so low level, it's almost always a case of multiple tying brushes, and the randomisation changing how the tie is broken.

It's not mentioned in the post, but I did check and this version also performs well on the simple test map file. We achieve the same minimum of 160 (over 100 tests), and I'm beginning to suspect that can't be bettered. The graph shows an improvement in the average case, similar to the one that's in the article. So that's reassuring. 
Not Ijed 
is it possible to make rmq using some modern free engine?

that would end up being a free quake replacement, and zenimax would probably sue you for theft of IP. 
Not Sure I Understand The Question 
It's on a free engine... if you mean porting it to something like Unity or sauerbrauten then yes it'd be possible, but in that case it'd be better to make a standalone brand new FPS game using the same ideals as Quake.

Making a classic FPS game isn't too taxing in terms of asset and feature creation, as long as you make a feasible plan and still to it.

An idealistic FPS is almost impossible to make :)

And a AAA FPS would be a great big waste of time.

It also depends how much of a hobby or job the project is in terms of both your own time and if you can pay others for theirs. 
Prevent Monster From Running Off High Edge 
I have a thin and narrow platform (shaped as a square) that monster_ogres run around. It's over 256 units high from the ground, supported by 4 pillar/beams.

When monster_ogre sees the player, they run off the edge, dropping down to the floor below.

I was surprised to see this. I thought monsters don't do this.

I can't seem to find any information on this in google or quakewiki. 
Figured It Out 
The problem is the UI bounding box for the entity (in TrenchBroom) is misleading/inaccurate. I made my platform as wide(or narrow) as the entity's box, so the entity falls off the edge.

To prove this, I surrounded my platform with walls, and the entity was stuck.

Same issue with the monster_dog box. I put a monster_dog in the corner, and it's stuck. I had to move it 8units away from both walls (of the corner) for it to work.

Pretty annoying. 
the engine checks for collision in a >= way (as opposed to > ) so monsters have to be at least 1 unit away from walls to avoid getting stuck and have to be on platforms at least 2 units wider to avoid falling off.

note also that narrow pathways will be very difficult for monsters to move into because the checks for movement are done in discreet steps. 
I added your information to

Feel free to adjust, or find better place for it in quakewiki. 
Max Leafs Visible 
"max leafs visible: 416 near (-832 -2824 576)"

Although this doesn't appear to be a warning or error message, I still see it as one. I wasn't getting it before, and now I am; and I have no idea what it means.

I've googled it a number of ways, and getting no good results.

What does it mean, and how do I troubleshoot it?

Does it mean too many polys for a certain area of the map from point to point? 
Nah It's Not An Error Message 
It's just a report

It tells you that of all of the places in the map, the one with the most leaves visible to it (as in when the player is stood there) has 416 visible to it. You can go WAAAYYY higher than 416. The other three numbers are the coordinates of this position. 
How Do I Use Quoth Content In My Quake Levels? 
So I heard about this awesome content pack called Quoth that adds a lot of stuff (monsters, weapons etc) into the game for modders to use in their levels. However, I have no idea how to make any of this stuff show up in NetRadiant (the level editor I use) or appear in-game. How do I load these custom resources into the editor and use them? 
Quoth In Radiant 
Alright, Ricky. Added to quakewiki.

This page: talks about Radiant, and mentions Quoth 
Avoid Jumping 
What is the maximum distance that can be jumped by strafe jumping and bunny-hopping? I need to know that distance for a map and i don't want to use fences or clip brushes and i want to make the chasm as smaller as possible.

Trying it by myself is no valid option as i can't get the hang of it.

As far as i know, with normal jumping the player can get across a chasm of about 180-200 units. 
Bunny Hop 
I don't know that there is a limit, other than a product of the maximal speed (2000?) and the air time of a regular jump, really.

if there are no slopes, grenades, rockets, or monsters, then you can protect against shortcuts by making the opposing edge slightly higher than standard jump height, so that it can't be jumped regardless of speed. 
Quake Units 
Not sure how strafe jumping and bunnyhopping fits in,
but regular mapping subscribes:

Max distance player can jump foreward => 225
Max distance player can jump upwards => 42.5
Max distance player can fall not injured=> 275
Min gap in floor before fall through => 35
Max step player walks before jumping => 17
With a rocket-boosted bunny hop sequence or something like that, a player can reach *insane* speeds which translates to insane jumps. I don't think there is any protection against that sort of thing really, apart from something like a midair teleporter or trigger_push, which is a bit cheesy.

(With the grappling hook in RMQ, just as anecdotal evidence, it was possible to reach horizontal speeds upwards of 1000 units per second - I've seen speedrunners go above 600 by other methods.)

Skill should be rewarded. But for 99% of players, 300 units or so should be uncrossable if there is no boost possibility nearby (including slopes and any source of damage) and they have no explosives.

I think. ^^

The slime pool in e1m1 is rather uncrossable (for mere mortals that is) without extending the bridge, so take that as a rule. 
The above goes for *Netquake* servers. Some popular engines are not quite Netquake. 
Those values are all wrong. 
So Negke, 
what are actually the right values? 
Correct Values 
Max distance player can jump foreward = 244
Max distance player can jump upwards = 43
Max distance player can fall not injured = 256
Min gap in floor before fall through = 33
Max step player walks before jumping = 18 
And yes, those are for Netquake, id1, vanilla, etc.

Also note that, I believe, there's a slight difference between old SW Quake and source ports concerning the out-of-water height (29). 
yeah, the out-of-water height is a bit sensitive. Not everyone can get out of water when the ledge is 32 units high! Make it 16 to be safe. 
thanks negke! 
Following What Gb Said... 
in general try not to build anything to the exact maximum, if you want the player to succeed. Because physics is framerate dependent, some players might not be able to make a jump that is theoretically possible.

Also geometry built near the threshold between "can" and "can't" is ambiguous to the player and makes the environment harder to read. For example you want gaps that are obviously "jumpable" or "unjumpable" when a player looks at them. (exception may be in DM maps where expert players are supposed to be challenged to learn the quirks of the map.)

For example, 16 units is a good max step height. 32 is a good minimum non-step height. 40 units is a good max jumpable height, 48 is a good minimum for un-jumpable height. 
MadFox and Negke: thanks for the info, it's going to be very useful.

Gb: at the situation i am right now. i have to penalize the skill, as i want to put something very important on the other side. The problem is that if i penalize skill, i have to make that it SEEMS obvious that it isn't possible to go to the other way. I'll probably mix more height and width, as i cannot make the chasm too big (244 is a lot for that part (right now it has 160) and i do need to take into account strafe jumping too), but i still cannot forget about the options of fences, something hanging on the middle of the chasm or adding gravity. I'll test all of them and decide later.

Metlslime: thx for the advices, they are usually obvious, but that's something that can tend to be forgotten.

I'll explain my idea: What i want to do is put a very important key-part of the map on the other side, so it can be seen easily and makes the player want to get there but hiding the path a lot so it is rewarding and makes the player realize how important is or how good the reward is, so i was thinking of ways to prevent the player to get to it by shortcuts, aside from those that we talked before; even ways of countering cheat codes.
The only one that i thought till now that not involve coding or hacking and can be valid even for countering ''noclip'' is killtargeting the object with a box surrounding it made of a trigger_once with a message. This box is killtargeted by another trigger put blocking the way i want the player to follow. Of course i plan to put the box so that only can be touched if the player cheat, or maybe putting also some kind of force field around the box so it is more obvious that it cannont be reached, but it seeems kind of cheap and it won't stop cheaters of trying to get there. I even though of using the box to target all the lights, as the most effective way to prevent people to noclip through doors and secrets triggered by that key-part, even if there is a cvar that adds lighting, only a few ones would know of it, so it will block most cheaters.

I'm conscious to the fact that being so zealous against cheaters can give me problems but i think that if done well it can add a lot to the map. 
Truth Is Too... 
... that if this part is giving me so much problems maybe i should forget about it entirely if i don't get a decent way to solve it quickly, as it can lead to have a dead weight in the map.

I'll go ask the pillow too. Good night. 
If you put up a barrier, make it appear logical. If it's a tech style map, yeah, a forcefield might work. A door stuck halfway also works. Anything that's in the theme of the map. 
Why worry about them? I mean the only person that they are cheating is themselves out of playing a game the way it was intended to be played and missing out on the experience. 
Thanks for the right values.
I just quoted Virtus DeathMatchMaker's manual,
but glad to see opposite. 
Max Distance Can Be Quite High 
As Mandel said, it depends on the max speed a player can get when bunny hopping; because the speed increase with each hop.

As Mandel said, the max speed (in most clients) is 2000.

The default speed (running) is 320; and, as negke said, the distance of a jump (default) is 244.

320/244 = 1.3114
2000/1.3114 = 1525

So, the max distance a player can bunny hop is 1525 units.

The max distance a player can bunny hop (on his first hop), is 320; but it's difficult (you need a nice starting approach/curve/turn) to do.

But, like gb said, put a barrier there (so that it's obvious) that a player shouldn't even bother/attempt a jump (in the first place). 
1525, Deqer 
thats quite a lot. 
Maximum Faces 
a brush can have?
on the opposite side of the ravine place a vertical wall with a skip texture on it. players trying to jump over will fall down. 
You have a point there, but i have my own reasons too:

1) I want that there is as much people as possible that enjoy the map like it is. Someone that cheats won't enjoy the map, the same happens with those that play a map in easy, they get a half-assed experience on the first try, and that is the most important one, as you won't get the same feeling twice in most parts.
That is the reason too as to why i always play the first time in nightmare, as the map won't feel as hard and intense on the second time and subsequent ones, and i will miss that if i don't do it that way. The problem is that i will miss the first experience in normal and that normal won't feel the same after completing the level in nightmare, but i can live with that.

2) People that cheat can activate triggers without noticing, and get as a a result a weird or unplayable map, and then think that it is the company or the mapper/modder fault. I don't feel responsible for them and don't care about them, but they should be taken into account too, as that people makes comments too, and those comments can make that some people that would enjoy the game/map/mod won't play it. This applies to 1) too, as if they cheat they won't get the same feeling (you don't get the acomplisment feeling when you see a secret, it isn't the same feeling if you see a room from one point than from other, ...).

3) I just pity those cheaters, as they are missing the good and bad points on maps, because the don't see that they are destroying their own fun times by taking unfair shortcuts. Same with people that exploits big bugs to defeat bosses. Yes, I like to get in the way of the problems of others if this makes that i can correct things that are blatantly bad for them, even if this can get me into problems. On the other way, I even feel bad and void when i use the architecture and the AI in Quake as a way to defeat the monsters, and don't want for more people to get accostumed to this as it seems that is happening more and more as the time passes.

4) That way of restricting players can be good. As an example, i recently played ''An evil new'' by Tronyn and Murderous Martin, that have ways to prevent the player from using cheat codes, and thought that it was a good experience, even if it was hard and at some times i wished for those cheat codes, the impossibility of having them made me put more effort on it and the feeling of acomplisment was far greater than expected and I enjoyed it and completed all of them. 
I haven't thought about that till now, but now that i have the distance for a normal jump i can calculate the distance of a strafe jumping by using the difference in their speeds when walking. I suppose the height will be the same. It won't be accurate but will get me a general idea of it, and that way i have that information there for subsequent maps.

Enliten:That idea ..., there is better ones, like the others that were posted before. But thanks for the intention. 
Cocerello: "I haven't thought about that till now, but now that i have the distance for a normal jump i can calculate the distance of a strafe jumping by using the difference in their speeds when walking."


You're welcome. 
Over Thinking! 
Cheaters cheat, it's up to them. They won't have much fun and aren't worth catering to. All the time that you spend combating this problem is time that could be spent on improving the map in other ways.

It has a parallel with the DRM argument - people who pirate your stuff wouldn't have bought it anyway.

Someone who cheats through your level won't play it properly because you block their cheating.

I used to try and block speed running, before I realized that I was hurting the maps.

Frustrating the player on purpose, no matter how noble the goal, is a bad idea.

To solve your problem I'd propose something cool and taunting rather than a physical block. Have the player ride through the area in a func_train cage beforehand or have votes spam magic at them from it from miles away.

These tactics will annoy the player but not frustrate them, and anyone that cheats their way over the gap is gonna know they missed out on something important. 
The more faces a brush has the less likely the map is to compile. Not for the brush itself but how it interacts with all the other brushes in the map.

The clipper is your friend! 
Quake players get to decide how to play the map.

Getting too obviously in the way of this is annoying for everyone involved. So just make the gap sufficiently wide that its obvious that you're not supposed to try to jump across. Then, if a player wants to spend 40 minutes lining up the perfect bunny sequence to jump across, then (a) he/she probably knows that they are not playing the map the way the mapper intended and (b) who are you to say this is less of an effort/reward ratio than the long route you had in mind? Dismissing an effort like this as "cheating" is almost insulting, imho. Ages ago distrans sent a nice mail to SDA about this sort of thing, search for "distrans" on to read it.

OTOH, someone who types god, impulse 9 into the console and rjs across... well, screw em. That really is just cheating. 
Achievements.... I remember when I used to play wow, the most fun thing I ever did in that game was explore off-limits areas, or take monsters to where they weren't supposed to be to create havoc.

If somebody tells me I can't or shouldn't do something, it makes me want to do it more. You could even consider rewarding them for their out of order completion or challenging them spawn mobs that wouldn't be there had they collected a key or rune.... 
Mwh, enliten: You probably missunderstood my words, i consider cheating using the cheat codes, i do not consider cheating speedruns, strafe-jumping and bunny-hopping, as those involve tons of skills to pull them.
I still think that i have to prevent that the player reaches there, as that shortcut probably will avoid a big part of the map (i wouldn't mind if the shorcut wasn't so big). I won't prevent players to get there if they pull a good bunny-hopping or other hard to pull trick, but i will make it obvious that it cannot be reached with a normal jump or a strafe jump, if i finally put the chasm.


Have the player ride through the area in a func_train cage beforehand

I don't understand what you can achieve with this one. To have the player measure the place so he will know that he can't jump? Or to show him what he cannot reach?

or have votes spam magic at them from it from miles away.

I don't understand this one at all, all i get in my mind when i read it sounds so crazy. Could you explain it? 
"Overthinking" hits the nail on the head I think. 
Shortcut Is A Shortcut. 
I agree with mwh.

Map is a better map when it offers things that allow for increased replayability (aka replay value).

Don't worry if a player skips a big part of the map, because the player won't. The player will play the long route first time, then try the difficult shortcut in the future. 
I agree with what you say, ALL of it, as it is compatible with what i said. 
The two examples I mention are ways of making sure the player knows the area is important, but they're more complex than just leaving a hole.

Cage: This is done in one of the episode 2 levels where the cage goes through water. Basically drop the player into a cage (so they can see out) then move it through the area you want them to see. This means they look at it but can't interact with anything directly.

Vores: Players love monsters. They ignore everything else in favour of monsters, so if you put monsters somewhere then players will head directly for them despite everything else.

For example, if you've got a fork in the path and want player to take the correct route, put a monster in it.

If you put some vores (long ranged attackers) on the other side of your pit then players will know for certain that what's on the other side is important, even though they can't get there yet. They also have to kill the vores, which adds some nice dodge game play to your level. 
"You're not supposed to be here"

was a good command in one of the mission packs after rocketjumping.
So the developpers had foreseen these attempts. 
Terra - if you no-clip around a lot you get told off and made fun of. 
I've seen playtesters do all kinds of shit I'd never expect, tbh. It's true that they will go kill a monster if it's a threat to them, but they might as well go back and happily continue doing what they were doing before the monster came along - jumping on top of something, looking for loot, or whatever.

I'm always slightly hesitant when it comes to guiding players like that. Ideally, if you have a fork in the road, both forks should lead to something that makes sense even if the player takes the "wrong" one.

Like in DOOM. 
Fork Monster 
Thanks for the idea. I actually have a fork (which merges back together anyways), but on one side there is a weapon you can see, but I feel now I'd like to add a monster there too now. 
My latest map seems to be breaking compiler limits (I blame tronyn for wanting larger maps!) I know the models limit can be broken easily. The clipnodes I just need to be more aggressive with clipping ceiling space. The marksurfaces is black magic and can safely go up to 64k but I have not seen the face limit before. I can load the map fine but I was wondering if the face limit can be safely broken with Fitz engines?

(text from compiler window)
WARNING: Models 366 exceed normal engine max 256
WARNING: Clipnodes 35914 exceed normal engine max 32767
WARNING: Faces 35778 exceed normal engine max 32767
WARNING: Marksurfaces 42509 exceed normal engine max 32767 
Is a great example of 'follow the enemy road' since it's full of pointless loops that the player can take and get lost in.

I remember the chainsaw maze in one of the early levels that had lights flashing on and off - the whole thing was a giant time trap, but a fun one.

The player had two ways to know that they'd exhausted the area - the map and when there was nothing else to kill in it.

Since Quake doesn't have a map thanks to being 3d the player falls back on constant slaughter.

You're right in saying that players will do all kinds of mad shit (grappling onto scrags to swing across chasms!) but run away from monsters isn't a common one, assuming they're not out of ammo or on red health.

Which is something I'm experimenting with now - purposefully crippling the player to change their play habits. In other words, putting monsters where I don't want them to go. 
You're Not Supposed To Be Here 
I got that In Hipnotic even when i wasn't cheating or trickjumping, probably because i like to look at everything to find new ways to go or secrets.

I remember getting that in the map where you see the mines for the first time, and thought that the way that was considered a cheat was more obvious to me than the one the mappper wanted the player to go. 
I Though Cthong Was Talking To Me. 
At least is was sowell maped that I could explore sideways without getting clipped. 
What he's wearing under the lava.

And Mrs Chthon has to wear 30 bikini tops. 
Mapping And Darkplaces 
I've been inspired to make my map by psp quake mods, and I was wondering how on Darkplaces I could get the texture filtering perfectly off so I can keep that pixel look inside my game.
Not being able to push the video setting under 1 (on filtering) makes me a sad man.. 
Radiant Users 
Now Ithat 'm A Bit Familiar With Modelling 
Are there any good tutorials to model/convert/and also program models for quake (with blender) ? 
Via Fbx 
The latest state-of-the-art blender conversion tool is this hacked together python-based thing:

To use it, make your model in blender, and then export one fbx file for each frame that you want to use. Extract the files in the fbxtomdl zip into a directory, then place all the fbx files into a subdirectory. Add all the fbx files to the directory, and add any skins in bmp, pcx or tga format. Then run the executable

fbxtomdl -d directoryname

General advice: make your model entirely from triangles, and skinmap your entire model in the same uv mapping - quake doesn't support different skins on different sections of the model. Be aware that the quake model format is not very accurate, so don't go overboard on the detail, and try to make sure that the model occupies roughly the same position in each frame. 
Worldcraft 3.3 Source Code 
Does anyone, anyone at all have the source code for Worldcraft 3.3? Or even Hammer? Has anyone snuck into Valve and snuck back out with the golden gem of all mapping codery, the Hammer Worldbuilder Source Code?

Oh please say yes.... 
It's The 
Main drawback of worldcraft, it can't be expanded with new functionality due to its closed source state.

I've never come across the source anywhere. 
Obscure Bug! (& Bonus Workaround) 
I've managed to hit a very obscure glitch in tyrann's compile tools (it may be in others too)

*** ERROR 08: Internal error: map.nummiptex > map.maxmiptex

This says that the number of textures exceeds the maximum possible number of textures. The maximum number of textures is calculated as the number of faces in the map. My map is a cuboid, so that's 6 faces and a maximum of 6 textures. I have three textures, one of which is static but switchable (so 2 frames) and two of which are both switchable and animated (4 frames each). This makes 10 textures...

If you ever encounter this bug, the fix is to hide a smaller cube inside your brush: it will get clipped away, but it will raise the number of surfaces in your map to 12 for long enough to get all the textures. 
Thanks Preach 
will definitely try it out! 
Quoth Question 

Is their a way to set how long the rubble will last? I'd like to have a custom rubble model hang around a minute or two. 
No Fuses 
It's a fixed duration in the code. Not offering a guarantee lets us reuse the entities creatively - like replacing some of the rubble early if there's an explosion of gibs nearby and packet overflow is starting to occur. 
Use a func_door, func_train or something for your rubble that should stay around. Ideally I'd use a func_emitter (Extras/RMQ) for this, because it lets you set the particles' lifetime among other things, but I guess with Quoth you're limited to what's in the package. 
Map.nummiptex > Map.maxmiptex 
@Preach: Yeah, that's a bug from the original TreeQBSP on which my util is based. Pretty rare, but much more likely to happen on a tiny, tiny map. Good job on the workaround though - spot on! ;) 
Found This Interesting 
That's pretty cool. I've been scribbling similar stuff for years without really putting further thought into it or thinking about how to make such sketches a stronger development tool.

That's a pretty good article, but it should have harped even harder about the most important thing: The graph is 2D but your level is 3D. 
good article. 
Texture Errors In Light 
Hey guys, I'm getting this error:

Bad texture axes on face:
face point at (0.000, 0.000, 0.000)

what is this error referring to... this website has a description that indicates alignments, but most of the textures (at the moment) have zero shift in their alignment...

any ideas? 
Check for microbrushes maybe..
Did you use custom textures?
Which editor did you use? TB i guess.
Which light was used... Come on. 
Sorry, Yeah Not Enough Info 
I'm using the Egyptian textures from soegypt. I'm using worldcraft and am using TyrUtils Light v0.10

As for microbrushes, I actually don'r know what they are... 
try looking in the error report. You might find a bug 'texture axis perpendicular to face'. Just click the fix button.

Its sometimes caused by clipping brushes.

I dont think its possible to create microbrushes in wc. 
which are very small brushes, and a typical problem in quark and similar editors. 
Fixed :) 
thanks ijed, the error report fixed it...

sometimes the obvious answer is staring us straight in the face... another week-ish of polishing here and there and the map should be ready for consumption. 
The Age Old Question 
Which bsp.exe is the one for me?

My current one: TXQBSP.EXE 1.12

What I need:
Support for small brushes. Small 16 sided cylinders get all messed up and end up more like 8 sided cylinders.

Support for liquid brushes that are one of the following: wedge shaped (4 or 5 faces), tied to an entity, completely or partially angled compared to the 3 planes (x,y,z), and/or micro-positioned (fractional units for a point like "263.4, 47, 18.9")

Specifically, doesn't think that there is a "Brush with duplicate plane on line: ####" when there clearly isn't!
Sorry Tyrann. TyrUtils v0.10 has these errors. It then proceeds to butcher my beautiful brushwork just like txqbsp.exe 
Duplicate Plane 
All compilers have some level of "tolerance" when it comes to whether a plane is duplicate or not, and the finer you make the detail the more likely it is that two planes you think of as distinct get merged for being "the same".

What rarely gets explained is why this is a good thing - why the compiler does it. Imagine that on the outside of your map - facing the void - you have two brushes which meet on angled faces. Because the map uses floating point to represent these planes, it's possible that the inherent imprecision of computer arithmetic makes one plane ever so slightly different to the other. If you don't have some way of treating approximately equal planes as being the same, then you get a leak between these two planes.

It's one of those things in engineering where there's a trade-off going on, and the compilers are configured to do the least bad thing. Like you could rebuild the compilers with the delta for equal faces being much smaller. But then you might have to rebuild your map so all the outer walls meet on axis-aligned joins...

PS: Check your map file in a text editor for line #### and see if there's another plane in that brush which is almost the same. If you can track it down, you might be able to slightly tweak the brush so that the planes are different enough to compile. 
Bottom line is: Quake is not the game (engine) for small, delicate geometry. 
If you really want those types of detail then map objects are the way to go. 
Distorting Map 
While working on a terrain map I found a strange outcome in my compiling.
Lots of polygons started scrambling their position.
First map in Radiant1.5 showed like

Then after some days compiling I end up with

In Radiant the map shows no gaps, but in game it is mesh. 
You can have liquids as entities, actually.

As for small multi sided cylinders etc, I suggest using Darkplaces or FTE and q3bsp - the grid size goes down smaller than Q1 and you can compile mapobjects into the BSP.

Liquids not cuboid - this is down to trigger fields. You can make a liquid brush wedge shaped, but you'll get waterwarp/tint outside of water then. Instead, stagger your liquid brushes to create the shape you want.

Your qbsp exe is q3map2, pretty much.

You can't use Worldcraft if you go that route though. 
Win7 Custom Radiant Build Menu 
The path to the file is:
C:\ Users\ *yourusername*\ AppData\ Roaming\ NetRadiantSettings\ 1.5.0\ *yourgame*

I'm using NetRadiant 1.5.0 here, change that if you use another version.
I also set the file to read only, just incase Radiant would like to overwrite it. 
What Is A Mapobject? Is This Some Wierd Radiant Terminology? 
mapobject = point entity
mapobject = brush entity
mapobject = point entity with a .mdl
mapobject = point entity with a brush model (as in the case of worldspawn)
all of the above??

Do you just mean any entity with a model? 
Basically Yes 
But usually with little to no functionality - decorative makestatics usually. 
Point entity with a model, decorative and usually does nothing, not even collide. 
Ok, Pop Quiz 
I'm setting up a future article for the blog here (like so future that I'm still finishing off the article which precedes it...), but it is a bit of a slow day on func_ so I think that's ok.

If you create a zero-wait trigger_multiple whose targetname is the same as its target then you'll get an infinite loop, which will quickly crash the map with a stack overflow. Similarly if you create a chain of trigger_relays which loop back on themsevles, the same thing will happen.

Can you devise a set-up where the same entity gets triggered more than once in the same "action", and the game continues running? (In the same action means before the function which was called to trigger things initially returns). 
Not Sure 
If this is what you mean, but I often trigger two relays at the same time, which both point at the same target but with different waits.

To open a door for a fixed period of time for example. 
I'll clarify with an example. If you have a trigger_multiple with

"target" "tweedledum"
"targetname "tweedledee"

and his partner

"target" "tweedledee"
"targetname "tweedledum"

If you ever walk into one of these triggers, they'll instantly crash because they just keep using each other with no delay, and the stack overflows. tweedledee targets tweedledum who targets tweedledee...

So in effect tweedledee is targetting himself. This would however be fine if either trigger had a delay - in fact a trigger which targets itself and has a delay is a very useful pattern - it's basically a clock which keeps firing the same event at a fixed time interval.

What I want to know is "can an entity indirectly target itself - cause itself to be used again, with no delay, legitimately?" That is, without crashing the engine... 
Noob Questions 
What are the max faces / verticies in a map? Do models count towards these limits? Do brushmodels and external brushmodels?

I've got a Bad Surface extents error and nothing I've done recently seems to have caused it since I've been backing up, deleting stuff and recompiling to try and find the issue but no go.

I've got 50906 faces against the standard 32767 normal limit.

The map doesn't load even in RMQe and I've been testing in fitz up until now.

If it is just too much stuff then the map may well just end up as a load of empty boxes since It's barely halfway complete and I haven't even added the end arena. 
A delay of 0.1 would equate to next frame - it'd be heavy as fuck on the engine but it shouldn't crash outright? 
Shorter Frames 
Frames can be shorter than 0.1 seconds, and it wouldn't be a great strain on the engine to do that. The problem is that the sequence of Tweedledum and Tweedledee never ends. This is fine if there's a delay, because you've got an infinite sequence to get through, but an infinite amount of time to do it in*. If there's no delay, you have an infinite number of triggers to get through this frame, which is too much.

*Disclaimer: the Quake engine cannot in fact run indefinitely due to floating point issues. 
Random Guess 
Use a different entity than a trigger to relay the firing? A non-moving door perhaps? 
Probably you need to have some sort of flag or variable that cleared when the entity gets "used", and once cleared prevents the loop from repeating. Sort of like breaking out of a while(true) loop. 
I'm imagining if you add a trigger_counter to the loop you might be able to terminate it after a certain amount of iterations? I'm not sure if I'm understanding the question right.

trigger_relay: tweedledee targets tweedledum
trigger_relay: tweedledum targets tweedledee
trigger_counter: tweedledum killtargets tweedledee, count 10

That should be activated 10 times in a single frame, at least in theory? Can't remember how killtarget works atm, maybe it doesn't remove the entity until the next frame.
I don't really see any practical purpose to the whole deal though...
Oh and this setup can't be reused of course. 
Thinking A Bit More... 
That depends on which order tweedledee activates the tweedledum entities. If it goes for the relay first it never reaches the counter obviously, and it most definitely won't work. 
building on CZG's idea...

"targetname" "a"
"target" "b"

"targetname" "b"
"target" "a"
"count" "1"

now the trigger_multiple's use function can trigger its own use function on the same frame, but for a total of only twice, instead of infinite times. 
Re: Ijed's Question 
the hard limit of faces and verts (regardless of engine extensions outside of new a format (bsp2)) is 65535.

External bsps do not count, but regular bmodels do.

Have you tried the old standby of removing large portions of the map to try to pinpoint the problem area? 
So its quite possible I just hit the limit with bmodels.

I don't have that many, but I haven't actually vetted the ones I'm using for vertex density. It's possible they've got lots of redundancy.

I tried removing certain lumps of geometry but not yet taking out entire lumps - that's next on the list. I'll give the 'big box' method of elimination a try as well.

In either case I suspect I'll have to either use external bsps or go to bsp2. Possibly both.

Fog Trap 
Had an idea for a blindness trap for the player.

fog .9 0 0 0
Used Quoth

Map file

Another one e1m1 with a speed power up.
Also uses Quoth mod 
v_cshift makes more sense but i wouldn't mind seeing a silent hill darkness fog effect. 
Did Something 
Similar but as a spell cast by a monster, using the shambles darkness effect when it casts lightning.

Worked pretty well, but unfortunately didn't really gel with the monster in question. 
yeah, i never understood what that was all about. at first, i thought it was just some graphical glitch to do with the lightning. 
I Reckon 
it'd work well as a direct attack, say, a special type of voreball that if it hits you leaves you blind for a duration. 
Small Q 
a simple question. how to carve shapes in other brushes? for instance what if I want to create a door port in the wall... do I have to create all the blocks around it just manually? 
it depends on the editor you use.

better do it manually, carving usually leads to problems at some point. you can use splitting/cutting tools fine however, at least unless you do weird 3D angles. 
i'm using trenchbroom. so is there anyway to put one shape in another and cut it out of it? 
oh nevermind, got it. 'c' is for cutting. 
'Carve' refers to subtracting one shape from another automatically, and usually means that the resulting geometry is a mess. 
By Mess 
I mean it might look ok, but won't compile without leaks or holes.

The 3 point cutter in trenchbroom, combined with shift dragging faces (kind of like extrude) should be enough for you to make most things you want pretty easily. 
Carving Saves Time Sometimes 
Anything but box shapes causes problems using Hammer. If you want to add light textures to a ceiling for instance. cut/paste/carve/repeat is a nice fast way to do it. 
what's the precached model limit in Fitzquake/Quakespasm/RMQ?
In glquake it's 256 (this includes map bmodels) 
nevermind, i suck and can't read the FQ documentation that clearly says it's now 2048. :P 
Quake 1 Episodes 
Hello, I'm new to mapping for Quake but have picked it up rather quickly. I would like to know how I'd go about making a .pak file instead of just single maps, like creating a whole episode. I've no idea how to make an episode and any help will be much appreciated. Thanks! 
I use pakscape:;1327

You drag and drop folders and files in just like winzip. 
All that .pak files are are just .zip folder style containers with files in. :) 
Ok, got it. Thanx guys! 
Just To Clarify 
AFAIK, pak files are not renamed zip files. Pk3 files are, though. 
Zip Works For Pak 
Err, No 
It doesn't. Try it. 
Custom Engines 
It probably works in some custom engines, if they support the pk3 format then they probably support it even if the extension is wrong - particularly because it offers compatibility with the pakN.pak automatic loading scheme. But I agree with SleepwalkR that most engines won't cope.

Fun fact: Fitzquake (and so I assume most other engines) will read any mdl, bsp or spr file correctly even if you name it with one of the other extensions. I haven't found a practical reason to do this other than confusing people, but it's neat to know.

Apologies to Flesh420 for all this mad, unneccessary and contradictory posting, please ignore everything after necros's reply! 
pak is the same thing as bmp 
Jump Height Difference? 
I'm banging out a remake of DM-Stalwart from UT99 to brush up on my brushwork (har har) and I noticed just by chance that a ledge I had made was able to be jumped on in Darkplaces, but not in Quakespasm. I changed to Quakespasm because it doesn't fudge the lighting (I spent time on that lighting!) and it looks like it's fudging the player physics too. Is there something I'm missing, or does Darkplaces have buggy/improper player physics? 
Greybox Texture? 
Also curious if there's a .wad floating around with greybox textures. I'm using one of the tiled floor patterns from the stock textures, but I've seen plenty of screenshots where prototype maps have a few differently colored grids as placeholders. 
The physics in Darkplaces and Quakespasm are different. This is because Darkplaces is based on the Quakeworld engine, whereas Quakespasm is based on the netquake engine (What was originally dosquake->winquake->glquake) 
Which set of behaviors should I target? Quaddicted recommends Quakespasm, so I suppose it'd be safer to target that engine. Is there a consensus on which engine is preferred for SP/DM? Up until I discovered this today I had no idea there were differing physics models across Quake/QuakeWorld, so I'm kind of thrown. 
Mind The Step 
The jumping difference is down to step physics. When the player hits an obstacle, the engine checks if the player can clear the obstacle by being pushed 18 units higher. This is how you can go up steps without needing to jump for each one. In regular quake, you must be standing on the ground for this to work. You might notice this if you jump while climbing some steps - you get blocked by the netx step and lose your forward momentum.

Darkplaces relaxes this requirement, allowing you to climb stairs even if you are off the ground. This fixes the blocking when you jump into some stairs. However, this also lets you climb a ledge you are pressing against, once you are less than 18 units short of the height needed to land on it. In effect, darkplaces lets you climb ledges 18 units higher than normal. This is not a qw physics difference, it's specific to darkplaces and can be disabled with sv_jumpstep 0 
I Made Some Grey/orange Textures For Mapping 
Using Quakespasm Is Best 
because most people will be using a similar engine (like fitzquake, directq or rmq). This is at least true for the singleplayer side of things.
If I am not mistaken though a lot of the multiplayer engines are based on darkplaces (like Nquake). 

This is the greybox wad I use in my current DM map. I made the textures in Wally. Have fun. 
To Map Hackers 
negke & co., how do I make an item float in midair in vanilla quake? There must be some way to circumvent the droptofloor part. 
you rest the item on an object that gets removed when the map starts... 
Indeed, this works even in deathmatch. Thanks. 
Make Sure To Remove It A Frame Or So After The Map Starts 
weapons don't drop to floor until a frame or so passes. 
correct me if i'm wrong but I think it actually needs to be after 1 second, because the game starts at 1 second.

so, a nextthink of 0.5 would actually run at 1 second and would be before droptofloors are called.
to be safe, it should be at least > 1. 
My Method 
Was to have the player touch a trigger once that killtargeted all the func_walls I had set up for the feature.

Worked on all engines as I recall. 
Simplest setup is a func_wall that removes itself (no need for triggers). Add the following fields:

"think" "SUB_Remove"
"nextthink" "0.2"

necros: I've heard that one before, but it's either incorrect or irrelevant in this context. Setting nextthink to 0.X in a map works fine. If anything, if the game starts at 1 second, then all of such values will be automatically executed at 1.X. 
To clarify a few wrong statements above: there are so-called NetQuake type engines - the ones that Quake SP runs on as well - and there are QuakeWorld engines which, among other things, have client-side prediction and modified physics, and are originally not meant to be used for SP. Some people use NQ engines for multiplayer games, some prefer QW. Naturally, certain NetQuake ports geared more toward singleplayer, while others are made with multiplayer in mind.

All engine ports are based on the original WinQuake, GLQuake, or QW sources released by id. Darkplaces, on the other hand, was largely rewritten from scratch as far as I know, and as such handles several things different than regular engines. It supports both NQ and QW servers, but it's not the base for any other ports. 
The nextthink/SUB_Remove on a func_wall makes sense.

I was thinking there is probably a way to hack the floating object itself to not go to droptofloor() but I was too lazy to think that up myself. And whatever works, right.

I used triggers on all the start spots in this version, might just go and do the SUB_Remove thing in the next one.

I remember we had a spawnflag for this in RMQ and also spawn/deathtargets on IPS. But if one targets vanilla deathmatch, custom progs is a no go. 
I just stuck in a simple if that skipped the droptofloor() call for that one. 
Well That Just Proves What I Know 
precisely dick!

Just stick with QS for your map... 
It's a DM map, no one uses QS there :) They use stuff like glpro, qrack, and ezquake.

I have a hard time getting my .lit file to stick already. Seems half of them have no coloured lighting. 
Layout Tools? 
Are there any good tools to be aware of outside of the usual workflow? Aside from the editor and texture utilities, what else do you leverage while you're making a map?

In particular I'm trying to think of a good way to plan maps. I was using graphing paper, but has anyone used something like google sketchup/layout, or another program? A simple way to layout a design from multiple angles would be awesome.

I was just using paper, but it's hard to keep track of the map from multiple angles, and to keep track of what line is what. 
Thing with planning maps... paper is fastest but lacks 3D. And if you do it in 3D you might as well do it inside the editor?

I like planning on paper, if you practice sketching straight in linear or orthogonal perspective and just do lots of little sketches it's pretty okay, you just have take peace with the fact you can't draw from all angles. 
dividing your time between layout and looks (dev texture etc) can be a huge save of effort. 
Trenchbroom makes it very easy to bang out huge swaths of geometry with little pain, but I find that the thing I have trouble with is keeping layers matched between floor levels. Such as the first greybox rough revision I made for my remake of DM-Stalwart, there are four or so different floor heights, and they all connect via ramps and stairs, but a couple of my levels ended up uneven with each other, which didn't really matter in the rough layout, but for when I do the real-deal I need to make sure that should be square with each other are.

Is there a good technique to prevent snafus like this? Such as making floor platforms first, or placeholders? I seem to remember at one point in 2D view editors I'd setup all the floors first from the top perspective, then use a side perspective to move the layers to the heights I wanted, and work from there. 
there are four or so different floor heights, and they all connect via ramps and stairs

One of the strengths of Trenchbroom, I find.

Resolving height differences can be a bit of a pain, but the fact that there is height differences is a good thing for your map and is worth the trouble. 
Doing an accurate projection of a plan isn't as good as it might seem. As Necros says, the map will be better for the tweaks and playtesting you have to do.

When I draw a level plan I just scribble down the loops and points of interest in a flow chart style diagram of how it will play.

Orthogonal projection of architectural style plans is a pain in the arse and tends to break as soon as you put players (or even AI) in it.

A good rule of thumb; the less flat the better. Even when it means rethinking your ideas for the level.

I just hit a problem with this last night where the SP map layout I'm making isn't working with the monster I wanted to use in that section. So in order to maintain the uneven floor I'm rethinking the encounters there.

I could just fudge it, or chuck in a random horde, but solving the problem well is part of the fun. 
For The Best 
It may be for the best, because the player movement and mobility is different in Quake than it is in UT99, so a little tweaking will be needed regardless. Though even with just the rough greyboxes the map works well for sure. I drafted my brother into testing it with me and we had a blast with the gameplay.

Still deciding what theme I want to use. The easy answer would be metal, since the original Stalwart is a garage, but I have a few ideas for making it medieval themed. Trying to be creative in replacing setpieces from the original with Quake-esque replacements, instead of just trying to recreate them. 
rethinking... redoing.
I have a section I've redone 4 times now. Throwing stuff away does waste time, but often you get something even better out of it. And if not, you can just reload a backup. 
What I use when making a level... I find with singleplayer levels I just spend a disproportionate amount of time planning before actually touching an editor. Recently I also do perspective sketches of entire areas. And I try to come up with unique little setpieces.

The overall gameplay of a level usually comes pretty fast, since I like to keep that simple - there might be a destroy objective or a collect keys objective, but also lots of exploring where I don't really plan much. So my high level gameplay is usually very simple, and then I try to allow for emergent gameplay while exploring. Periodically spawning monsters that patrol etc.

Then again, parts of levels also come together while just putting blocks together in Radiant. It's really a mixture of several approaches, and then I just reiterate.

I tend to use a greyboxing approach these days, too, and start with simple blocks and placeholders. So for the multiple floors problem, yeah I would use placeholders in various places or just build it from memory (and accept the little differences that come with that). 
I used to make a lot of drawing plans for maps, but these days I flesh out a few rooms, make a bunch of geometry pieces for templates and I spend a lot of time having "inspiration sleeps"... that is I intentionally have naps and dream about mapping. It's weird but sometimes I will nap for 5-10 minutes and spend a couple of hours mapping then if I run into a wall I have another nap. 
I Dig 
I do my best programming after I wake up. Lots of good ideas for functions and design in those waking moments!

Speaking of that I've been meaning to give QuakeC a go. Never was very good at C, better with more modern nonsense like Java, C#, and Ruby, but it's QuakeC. Gotta be good. 
It's basically java without OO. 
"Speaking of that I've been meaning to give QuakeC a go. Never was very good at C, better with more modern nonsense like Java, C#, and Ruby, but it's QuakeC. Gotta be good."

Prepare for pain. :) 
Best Description Of Qc 

This should get you started:

And the main site has plenty to chew over as well: 
More Resources For Learning QC 
I've always held that Coffee's Ai Cafe has a fantastic set of tutorials for QC.

Admittedly many of them centre around creating good AI for a deathmatch bot, but there's variety enough to get you exploring most of the code base. The practice with the AI is also helpful when it comes to working with the monster code in Quake, even if the tutorials rarely work directly with individual monster files (they all follow a similar pattern in the end). 
Haven't seen that before, even though I have heard of 'coffee move'. 
Leaks, But No Leak 
I've been using txqbsp for a while with no trouble, but was reading about tyr's qbsp so I figured I'd give it a show, and it is telling me I have a leak where there is none. I load up the point file, and it meanders around in the void then passes straight through a simple floor brush. I swapped back to txqbsp and it compiles with no leak, I turn on r_showtris and vis is working correctly, only what is visible is rendered, the vis is very good considering the size of the map.

What could be the trouble here? I have no entities in the void, no brush entities in the map at all, and the only texture I'm using is a greybox grid.

What gives? Tyr's light and vis are working great, qbsp is the only one acting a fool. 
I don't think tyrqbsp is based off of txqbsp, which is unfortunate as txqbsp is the best compiler out there in terms of robustness and its ability to cope with complex geometry. 
Tyr`s Qbsp 
Tyranns qbsp.exe is for all intents and purposes currently broken. It wont compile anything for me so I just stick with txqbsp like I have for years. Tyrs vis and light are amazingly fast and work great though. 
Good to know. Thought it was my fault! 
Has a newer version in testing at the moment with a lot of fixes and improvements. 
Rebb�s Jury Rigged BJP Tools 
are youre choice at last... 
Rotate Info 
would something like this chart and an explanation be helpful?
The rotation stuff seems under used and understood. 
Gameflow Study 
I'm getting charty with it!

I'm starting to do some data analysis tests for Quake gameplay. I've done a first run through of one of my old favorite maps (hip2m2 if your curious) to get an idea of some basic ideas.

I'm attempting to create generalizations about the basic gameplay elements over time. This is only the results from one study, but I had to pause to write the data down every interval. Also, copying the output from the console is tedious if I were to try to improve the collection method by outputting the data every 30 or 60 secs to the conole. Is there an engine that supports exporting data in this manner? Maybe in the save file?

I can make some generalizations though (still this depends on play style and it would be nice to have others input their data for this study). Kills over time is almost perfectly linear at about 12 kills per minute or 5 seconds per kill. Shells and nails maintain the same average (44 for this particular map), but nails varies much more wildly than shells (okay so I use them more but who wouldn't). Rockets maintained a very low average hovering around 10-15.

The linear kills over time is to me the most useful tidbit so far that I've learned and gives me a good idea of this maps pace, although being able to see the balance of everything over time like this makes me giddy. :D I love charts!!

Is there a better way to automate this? 
You could record yourself playing/take demos, and gather the data later. Never peeked inside a demo file before, possible it's in there and could be plucked out. 
I've created a map and everything is sealed, but for some reason when I play the map it's bright though the worldspawn brightness is set to default, which should be at 0. Can anyone help and tell me what's causing this? 
You Have To Place At Least One Light Entity 
otherwise it would completely fullbright

and don't forget to run light.exe 
Use QW and then cokeman's mvdparser. You can specify what information you want in the output with templates. Should be possible to get pickups etc. from it.

I used it for

There are also tools for protocol 15 demos but I haven't found a user-friendly one. Will probably be investigating them later this month. The SDA guys should have stuff. Maybe 
Are you using the newest tyr tools for light and vis?

It's possible VIS broke somehow. In Quake turn "r_showtris 1" in console and just make sure that the whole level isn't being rendered at one time, which may indicate something doing wrong at compile time.

This is assuming you're running light.exe and have some lights thrown about in the map, which is what to check first. 
Ok thanks. Yea something broke and I got the idea to try different compile tools and that fixed it. 
VIS Has Nothing To Do With It 
It's like spy said. Light.exe adds the lightmap information to the compiled bsp provided there are light entities in the map. 
Collision On Moving (blocked) Bmodels 
If a moving brush entity, e.g. a func_train, is being blocked by a player or a monster, does this affect the behavior of other entities riding it in any way? Technically, it's still in a "moving" state, right? Would that impact on any active/inactive monsters on it, specifically their movement/AI routines? 
Seen anything like that, especially with trains. Typically they affect nothing and nothing affects them apart from a direct targeting and the obvious movement of creatures placed on top.

The only oddity I've seen there is with dead monsters, who'll sometimes slide on horizontally moving trains, and doors.

It's possible however that a mover is doing damage to a creature (even if it's 0 damage) which in theory could interrupt / reboot it's state.

Just conjecture / vague memory though. 
I am trying to get my maps to work with Darkplaces and I have setup all my bmodels (doors, buttons) with skip on their hidden surfaces. I have been using your newskip.exe program to move the skip surfaces around inside of the bsp, but strange things are happening.

Projectiles often fall through the bmodels with skip surfaces and traceline functions cannot recognize the objects anymore. If I compile without the newskip.exe the bmodels are all fine. I checked that the objects have the correct bbox and min/max setup but I cannot see what is wrong.

What exactly does newskip.exe do? I want to be able to explain to LordHavoc so that I can log a bug with him about Darkplaces and hopefully get the situation fixed. I really want to keep the skip surface function but I need to get more details. Can you help? 
basically skip tool will re-arrange the faces in the leaf or bmodel so that the skip faces are at the end of the list, then it changes the "num faces" count to be lower.

so if you start with this:

NumFaces: 6
Faces: A B C D E F

And B and C are skip-textured, you get this at the end:

NumFaces: 4
Faces: A D E F B C

So B and C are still included in the list, but won't get drawn because the engine will stop after drawing the first 4 faces.

Also the source code is included in the newskip archive, so Lordhavoc should be able to look at it in more detail if he wants to. 
thanks :) 
So That's How SKIP Works! 
I thought it deleted the faces. That explains why newskipped bsps when loaded into another map as a .model still render all of their faces even when loaded by themselves they don't render. (Yeah I was playing around with the idea of instancing (you know like source engine!) multiple bsp's which works almost perfectly but would be absolutely horrid for performance in my case since skipping doesn't work. That and you get fireflies between mating surfaces of zero thickness (think tri-soup where two brushes only share an edge)); 
Wait how does the engine render entity .model's like for monsters and brush entities? Is there a way to have a skip utility that causes certain faces of a bsp to have the pink index color of transparency applied to them? 
The latest tyr-qbsp removes skip surfaces completely during compilation (instead of hiding them at the end of the surface list) in case that helps. 
Interesting, I didn't consider that use case when creating the tool. It should be possible to support it, though tyranns new absolute kind of makes my tool obsolete. 
"Absolute" should read "qbsp" -- cursed iPad autocorrect 
Darkplaces doesn't treat skip surfaces as simply tranpsarent faces by default like normal engines. Instead, to DP it's pretty much like they aren't there, so shots pass through and they don't block visibility. Check the sv_gameplayfix_q1bsptraceline* cvars, they can revert this behavior. 
i wish skip worked on external bsps. that would be radddddd 
Sounds like tyr's does? 
Mapping For Quake 
This question has probably been asked before but after hours of Googling, I have to turn to you. I've been using GTKRadiant 1.4 for Quake 3. I would like to use the same editor for Quake. According to several readme's from different maps, this should be possible.

Google has thought me GTKRadiant 1.5 has a gamepack for Quake and should be easy to configure. However, I don't like 1.5. I'm spoiled like that :)

Quake ED by Sikkpin is mentioned a lot. But all I find are dead download links. There doesn't seem to be a site for it.

Other editors are mentioned of course but before switching it would be great to hear if it's possible with GTKRadiant. If not, links to Quake Ed by Sikkpin would be appreciated since that one seems to be the best fit for me (based on what I read). 
The Quake gamepack should work with either version. Worth a try. 
Looking into it. Apparently official support is dropped for 1.5 and later. So no official gamepack download. Currently looking for mirrors :) 
The 1.5 Release Contains The Quake Gamepack 
A slightly modified version of it is available here.

And while I'm at it, might just drop this link as well: 
Should be pretty easy to pull that data out of a demo file (assuming you have code lying around that reads demo files, I have some oddball Python at, Mandel has some C at or you can ram the demo through lmpc and parse the text). 
Thank you for those files. Unfortunately, the pack doesn't seem to be compatible with GTK 1.4. I got pretty far and solved several errors but eventually it would still crash.

Maybe someone else has any ideas? Otherwise a link to Sikkpin QE would be appreciated. 
You can totally use GTK1.4 with q1, but it requires some small bits of hackery.

Basically, you extract your texture wad as jpg or tga and store them like a q3 texture pack.
Then, when you go to compile, you convert the map that was saved from GTKR (which will be a q3 .map format) into the q1 .map format with a converter program. then you compile as normal.

When i get home, I'll see if I can dig up my old guide for this. 
That would be great. I thought about converting but figured it wouldn't work texture wise and Quake uses different entities and such. At least, when you decompile everything is messed up. 
Here You Go

Its very old, but it explains the process at least. You can probably make it so that you can select Quake1 as a game mode (like Quake3, RTCW, etc...) instead of overwriting the Quake3 entities file... see GTKRadiant documentation on how to set up different games for that. I haven't used GTKR in ages. 
btw, i forgot, but there is a better guide to using gtkradiant. i also forgot who made it. :\ 
Quake 1 Map Pack 
GTK1.3+ Quake 1 Editor Files

Here is my Quake 1 setup for GTK 1.3+ Please check the readme file for more details of where all the files go and what they do. I was planning to test the entities.def file today, but ran out of time, it was a crazy day. I went through my own def file and took out all my custom MOD stuff, which may cause a couple of problems.

You will need to get some compiler tools, I only included the textures and editor files. You can use func_group entities with most Quake compilers, just remember to add the right switches, for example "txqbsp -group -q2map %1" will cope with Q3 map format and groups! :) 
Still Thinkering 
@Necros: Thank you for the link. What editor are you using now?

@Sock: We can always count on you. Thanks for sharing. A couple of questions though:

The GTK 1.3.8 beta doesn't have native Quake support. I take it I have to create my own gamepack much like mentioned in Necros his guide?

Based on the files you posted I figured this:

Entities.def and q1.shader go in the folder inside Radiant. I have to make this.

I would need a file for the qames folder in Radiant.

Textures and maps should be in the Quake folder and Tools doesn't matter right?

Also, Radiant should be installed with only q3 game support? In your readme you mention SDRadiant. Perhaps that's the difference?

I got 1.5 to run with Quake but god I hate that editor. Getting into Quake mapping, while using 1.4, is harder than I thought. My head hurts after 2 days of Googling, trying stuff out and harassing people. 
GTK 1.3+ Hacking 
I recommend you setup the editor like you are going to make q3 map.

* Go to the scripts directory under baseq3
* Rename the existing "entities.def" file to "entities.q3def" instead.
* Add "q1.shader" to the "shaderlist.txt" file
* Drop the zip file into the baseq3 directory.
* Extract the zip file
* Open editor, make cool maps!
* Setup quake 1 compiler tools in maps directory
* Setup compiler batch file (remember special switches)
* Compile map
* Copy bsp/lit files to quake directory 
Damn it, just use TrenchBroom! :) 
Yeah for real TrenchBroom is amazing. 
I also will advocate trenchbroom... it is clearly the best. 
I am currently using Trenchbroom :) 
Trenchbroom is definitely on my list. It looks like a great editor especially for terrain and such. However, I will not rest until this works. Not when people put in their time and effort to help me.

Radiant works now. I see the textures. I only get the Quake entities and I can make and save maps. I've read several compiling guides. I think my setup is good (Using Necros his GUI). But I get a line 4: invalid brush plane error.

I figured I need to convert it first but it looks like none of the programs can find the map. Regardless of where I put it. The source map is now in Quake/id1/working folder. Could this be the problem? First I left it in the Quake 3 arena map directory and that didn't work either. Is there a specific location needed? All the tools (compilers) are in Quake/Tools and the output map is in Quake/Id1/maps. 
I thought quake 3 maps had to be in a .pk3 file? 
Only when you release it for the public. 
I think my setup is good (Using Necros his GUI). But I get a line 4: invalid brush plane error.

Rmember to add the right switches, for example "txqbsp -group -q2map" or setup a compiler batch file (remember special switches) 
Switches is one thing, but the problem now is that the tools simply don't see or recognize the source map. 
Quake1/ID/maps <--- Where the bsp/lit file goes
Quake3/baseq3/maps <--- source, wad files + compiler tools

I don't know how the necros GUI tool works, I just use DOS batch files to compile stuff and copy it once finished. 
my gui basically makes dos batch files on the fly and runs them. :)

i'm actually not familiar with -q2map but i do see that it is a valid switch for aguirre's txqbsp so it SHOULD work.

you could also try getting aguirre's convmap.exe and using it in the compiler gui by checking the "map must be converted..." checkbox, and setting the arguments to -f32 as that will also convert a q3/q2 map to q1 format before trying to compile it.
Note: if you do this, remove -q2map from txqbsp, of course! :)

now, with all that said, the error sounds like it might actually be that the brush itself has an error. can you copy and paste the first 5~ lines of the map file? 
Yeah, I followed your readme instructions. Somehow there is an error opening the testmap (I've tried several compilers)It's just a square room with a info player start and a sky texture.

I think I have to convert the .map first to Q1 map format? Looking at programs to do that. 
that's how aguirre's convmap.exe works (and also how the original mapconv.exe which was made by sleepwalkr).

convmap also has many many other features besides covnerting q3->q1 map formats.

but there's basically 2 ways.
if you use convmap, then you will be converting and creating a new map file and then compiling the new map file.

if you use -q2map on txqbsp, then the compiler is converting it on the fly without writing out a converted map. 
Tried that too, several times. Made a new testmap. Something goes wrong there. Here's a bit of the map file:

// entity 0
"classname" "worldspawn"
// brush 0
( 448 192 -8 ) ( 128 192 -8 ) ( 128 -72 -8 ) radiant/notex 0 0 0 0.500000 0.500000 0 0 0
( 128 -136 8 ) ( 448 -136 8 ) ( 448 -136 0 ) radiant/notex 0 0 0 0.500000 0.500000 0 0 0
( 456 -72 8 ) ( 456 192 8 ) ( 456 192 0 ) radiant/notex 0 0 0 0.500000 0.500000 0 0 0
( 448 200 8 ) ( 128 200 8 ) ( 128 200 0 ) radiant/notex 0 0 0 0.500000 0.500000 0 0 0
( 120 192 8 ) ( 120 -72 8 ) ( 120 -72 0 ) radiant/notex 0 0 0 0.500000 0.500000 0 0 0
( 128 192 0 ) ( 448 192 0 ) ( 128 -72 0 ) q1/floor01_5 0 0 0 0.500000 0.500000 0 0 0
ok, well, the lines look fine to me so the last thing we can try it to do this all manually.

to make this easy, make a folder on your C:\ called maps or something.

copy your q3 .map file there and copy your convmap.exe and txqbsp.exe there as well.

assuming your q3 map is called

open a command prompt and type:

cd maps
convmap -f32 q3
move q3.out
txqbsp q1
Build a testmap in Trenchbroom and it compiled immediately. Currently looking at my single room in Quake.

I did what you said, I now have .out file. No bsp. 
did you follow all the steps?

type the rest:
move q3.out
txqbsp q1

the move command will rename the .out file to and then you need to try compiling it. 
Typed it as a single command :)
It works. Thank you very much. Now only to figure out what goes wrong. It does give a couple of no entities in empty space warnings but nothing destructive. 
Importing A Question 
Mick asked:
I'm currently working on porting some Q3 maps to Quakeworld. And some of the maps has doors in them. And after finishing the map it all works well on my localhost server through ezQuake. When typing /map mapname

But today some of the maps was added to

And the doors doesn't work at all, they are both triggered by shooting and by touching a trigger. Does it have something to do with KTX server (1.37)? Or do I have to make the door's in some other way ?

Mapename: Q1Q3DM7

Thread at ->

I just downloaded the file q1q3md7_b4.bsp, and opened it up in a hex editor. I can't find any func_door entities in the file, or indeed any func_ type entities of any class. Did I get the wrong file? If there's a different copy on the server, any chance of a direct link? 
Not really about editing but this seems like the best place though. I'm using Quakespasm. Everytime I move, textures like water/teleporters/etc get all blurry. I'm using the default engine, with default textures, no changes whatsoever. I can't post a screenshot since it only happens when I look around.

If neccessary, I could figure out how to do demos and post that. Any ideas? 
What map? Transparent water?

Try r_novis 1 OR r_wateralpha 1. 
I Have The Same Issue 
Haven't tracked it down yet, though. I'm on Mac OS X. Sprony, you should post this in the Quakespasm thread. 
That's A Combination Of... 
transparent water and the r_wateralpha settings. I think that you have to go with r_oldwater 1 to fix that (but I'm not sure). Either that or recompile the maps to have transparent water. Google id1vis to find the tool that will do that for you.

Make sure that you back up the id1 folder first though.

The issue here is that vanilla Quake cuts you off from seeing through liquids from the outside. That was to help lower r_speeds due to computer limitations back then. This had to be done at the map compiling level (bsp). Quakespasm assumes by default that you have already converted the levels bsp file to remove that visual limitation but if you didn't you get blurry liquids. 
r_novis 1 does the trick for me. Thanks! 
The Bug 
Is called HOM (Hall of Mirrors) and means you're looking at water that wasn't vis'ed.

r_novis turns off all vis data for the level - which will make the map slightly slower running. In an id1 level this won't be a problem, but if you try the same trick in a big map it'll probably slow down the game FPS a fair bit, depending on your PC. 
So the obvious solution is not r_novis 1 but r_wateralpha 1. 
... fullvis the map... that would help eventually ;) 
Is there some sort of visible brush entity limit in Darkplaces? Because some buttons and func_wall decorations are invisible or else stretched and splayed across the whole map. 
If I recall there's a limit but it's astronomical. Have you tried a different engine, or using a different compiler? 
"...but It's Astronomical." 
Oh, okay it makes sense now. I thought their wasn't a limit so I just kept mapping, and mapping...and mapping...and here I go for some more... 
Hey Tyrann Buddy 
How's that awesome new qbsp coming along? 
Trenchbroom Prefabs? 
Is there a way to handle prefabs in TB? I know that there isn't, but how are people handling it? I brushed up this really bitchin spire and want to keep it around without having to open the map it's in and copy-pasta it. 
Is the only way for now, I tend to make things like that into a func_group and then double click to select them all, using Ctrl drag to clone.

Prefabbing has been brought up on the forum, I think Sleepwalker is planning this for tb2 - might be completely wrong though. 
It's On My Radar 
The very first version of TB had prefabs, but I'm not sure how useful they really are. 
not sure if I mentioned this or not, but the way portal2 (and perhaps some of the other modern source engine games) use 'prefabs' is nice.

basically, they are .map files which are instanced into the current .map, allowing even large sections of geometry to be reused and updated in a central map. writing this it sounds completely boring... but trust me, their use of them proves to me prefabs can be useful! 
Not Sure How Useful They Are 
Actually they are reeeeaaallllyyy useful man. To the point where I have a map full of them that I open and copy paste as needed. 
i�m doing the same procedure as 5th. 
There's some discussion about it in the issue tracker and I'd like to roll it into a prefab system. Good to know people do use them, I'll keep that in mind. 
One idea I proposed was to use .map - had no idea portal2 used it though.

It could work really well if used like the entities tab - you see a little preview of each prefab and just drag n drop into your current level. And just saving prefabs into a 'prefab' sub folder...

The complex part with the current workflow would be including entities with prefabs though, since grouping things can only be done through making them into a brush func group entity as of now.

I don't think an instancing support would be required, but I honestly don't know. Maybe it would be incredibly awesome to edit all your doors or whatever by opening a single

All the door frames in my test mod have broken offsets where the door z fights with the frame when open. 
Virtus DMM Has Prefabs 
always liked the logo
This Explains Everything 
Why Did I Do That? 
If I ever do another map I'm going to keep some kind of log book. I started to work on my map again yesterday after about 4 or 5 months, and I can't remember how things work. I find about 6 very similar versions of a texture and can't remember why I made them or how they're different. I walk through the map and see things and say to myself "Why in the world did I do that?" I'm going to end up wasting a week just figuring this stuff out. 
Use a code-versioning system to check in changes you did on your map with comments. 
to my world, Rick! 
Snarkpit website (can't remeber the http..) has also some nice to consider, even though they are CS oriented...
I also found once a website (Mission HQ as far as I remember...) in which there were tons of WW2 prefabs (i.e the Tiger Tank in Fort Driant has been re-built from one of their model)..

So prefabs ! Yes, there are many over the intarweb :) 
More For Personal 
I was thinking more for personal clipping, as I don't like using other people's work in my own. Like if I spend a lot of time brushing a cool looking widget, or if I make a cool ceiling design, I could make a "slice 9" version of it and then save those slices as prefabs, so I can paste them and scale/extrude them as needed to make ceilings in a map. 
Fullbright Water 
Why? Surely there is some way to fix this. I don't mean light mapped, just some way to turn the brightness down. I made a custom water texture using only the darkest colors available and it still looks too bright in places. The only thing that seems to help is wateralpha, but transparent water doesn't look right in Quake. 
Edit The Texture 
How About. 
Use wateralpha, and put a very thin (2 units) func_illusionary right under the surface, and then put an all black texture on the top face and skip on the bottom face. 
Use wateralpha, and put a very thin (2 units) func_illusionary right under the surface, and then put an all black texture on the top face and skip on the bottom face.
I have done this with teleporters, lava and water, works a treat! I usually make the lava illusionary brush red and the water one similar base colour to the top texture. 
Interesting idea. Might look funny if the player uses a very transparent wateralpha setting. I don't have any models left and I'm real close to the marksurfaces limit. I might just have to add a little more light to this particular area (it's not a very big part of the map).

On the other hand, I'm beginning to see less and less reason to keep deathmatch stuff and that would free up a number of models. I intend to finish this thing by the end of the year, if not sooner. I'm tired of working on it.

Still, it would be nice if this could be added as an engine feature, kind of like fog. 
Fullbright Water 
That's an engine issue, not a mapping issue. You need to use an engine (like GLQuake, I think) that ignores fullbrights altogether. Personally I think that unless it's *Lava a little transparency can be a good thing in a visual sense. Of course it may also "Break" a map because, for example,in E1M4 (The Grisly Grotto), you can avoid the Skraggs by simply diving in and due to how the old vis worked you would disappear from their view and thus not get shot at from above or perhaps you can see a secret that you missed before. 
You need to use an engine (like GLQuake, I think) that ignores fullbrights altogether.

That won't work. 
I'm pretty sure liquids (including the sky) are treated differently from normal textures. Maybe that's why there is no brightness setting for them, because it would affect all of them equally? 
I Already Asked Tyrann About This 
in terms of allowing the texture to be lit.

He said it wasn't possible, which is a shame because it would be great. I dunno if it is possible in dark places, probably is.

Fullbright water sucks :( 
Shadows On Water 
Requires changes to both the tools and engine. Possible an updated bsp format too, though we could probably work around that. 
I can see why shadows on water (light mapped water) would be a problem, but what about some way to darken the water texture down from full bright? Just the ability to choose 75, 50, 25% brightness or something like that would be a big improvement. Actual shadows are not really needed, though I'm sure some people would think it's great.

A full bright sky is not much of a problem, most people use a skybox anyway, lava seems like it ought to be bright most of the time, but water being full bright often just looks bad. 
how about using an external TGA texture that is really dark? 
I was going by memory. I could swear that there was an engine out there that didn't fullbright liquids... Maybe an early version of TXQuake (OpenGL based) or something else from that era (early 2000's a year or two after the GL source was released) I recall that it looked washed out in general. Then again I might have been thinking of a totally different game altogether, maybe Q2.

It (fullbright liquids) can screw up the look of a level in some places because it stands out so much if you want to go dark and gloomy with a secret area that you need to dive into in order to get to the goodies. There are ways around that with creative brush work but it's still a bit of a pain to light in order to explain away the bright liquid.

Ideally only *Lava(xx) (all versions) would be fullbright with the *water(xx) never fullbright, *04water(xx) always fullbright, *01slime(xx) being never fullbright and *04slime(xx) being fullbright, or some other similar naming convention.

I get why they did it back in the day and it made sense from a hardware point of view but today it can limit options in some small cases. 
If you're already willing to change the look of default Quake, then using DP/FTE and GLSL water isn't a stretch. Pretty sure you can set some parms to the GLSL that would give you less transparent water, such as fog, tint and fresnel. You could try not using normalmaps with the glsl water either, or really flat ones to prevent the water bumping itself...

or write your own glsl water shader for vanilla looking water just slightly transparent but still not able to see much beyond the surface. Fresnel etc.

Real water's transparency depends on depth and the colour of the ground etc, so the dm3 pool shouldn't be fully transparent indeed.

glsl is your friend. 
Something i've done is to use the transparent illusionary trick above and to use a non-liquid version of the liquid texture (ie without the *) and stretched to maybe 4x4 scale.
If your liquid is placed below the illusionary by 1 pixel, you can set the illusionary to have alpha about 0.5 and water to be about 0.3~ i think and this makes the water look like it has a lightmap on it.
doesn't work with all kinds of waters, but most of the stock water textures look fine. 
Maybe I haven't been paying attention. I can set the alpha of a func_illusionary and water in a Quake map? This is a plain old bsp file type map running in Fitzquake. 
Alpha Papa 
Almost all engines today support alpha transparency on water, it was introduced with glquake, the official 3d accelerated engine, and so any engine not based on software quake has it. The support is limited though: critically it's controlled by a cvar, not directly in the map, so you need some kind of mod to ensure that the value is set to transparent. Otherwise you're relying on the user to set it correctly for your map.

Most source ports of quake support the addition of the alpha field for entities, making them appear transparent. It's one of the few extended features to be implemented consistently across so many engines that it can almost be treated as standard (skyboxes would be another, fog almost so). In engines that don't support alpha, the entity renders fully opaque instead.

Fitzquake supports both of these features, so it would work fine in that engine(minus the proviso about needing to set the cvar). I'd recommend a slight tweak to the setup necros suggests to provide better fallbacks in less functional engines. If you put the func_illusionary slightly below the waterline then:

* In software quake you get opaque water that's not lightmapped but animates (which is probably better than lightmapped-but-not-animated water). No worse than usual.

* In engines without "alpha" key support, you get animated, lightmapped water which is opaque - an interesting trade-off you'd probably opt for if this lightmap idea is important to your map.

* In engines with both you'd get the full effect. 
Good That I Asked 
I was aware of r_wateralpha.

The support is limited though: critically it's controlled by a cvar, not directly in the map, so you need some kind of mod to ensure that the value is set to transparent. Otherwise you're relying on the user to set it correctly for your map.

That's what I was thinking which is why I asked about setting it in the map.

Most source ports of quake support the addition of the alpha field for entities, making them appear transparent.

That's something I didn't know. I'd seen this effect , but I guess I just figured it was done with custom code, though now that I think about it, I remember at least one map where it was used that was just a normal bsp.

Thanks guys, for all the info and ideas.

Most of the too bright water in my map was fixed by using a super dark water texture. There are a couple of places where pitch black walls are adjacent to lit water that don't look so good, but I can probably live with it.

I tend to spend days fixing trying to fix small things like this, that most people will never notice. If I keep doing this, the map will never be done. 
That May Be 
But if I notice even one instance where I know the author took time to get a tiny detail right, I enjoy the map that much more. 
trying to fix small things like this, that most people will never notice.

but they will notice if it's not fixed. :P 
Tiny Detail Right 
The details are everything.

If there's one misaligned texture, people will think you're sloppy. If there's one overlapping-brush-2-brush-flicker, they'll think less of the map as it ruins the Sustainment of Disbelief.

Even the smallest detail (to chamfer or not to chamfer) can make a big difference in the overall fluidity and coherence of that area.

The details are everything. 
Not Sure 
It's easy to get obsessive and waste a lot of time getting everything perfect.

A good release stands on its own, warts and all. 
You Got That Right 
It's easy to get obsessive and waste a lot of time getting everything perfect.

I'm trying for not too many warts.
It's getting closer. 
How Do I Use An External BSP? 
Do I just put the brushes in an empty map, run bsp and light and then place it in a different map using info_notnull or something like that? 
Do I just put the brushes in an empty map, run bsp and light and then place it in a different map

yes, be sure to place the bsp in your progs folder.

using info_notnull or something like that?

i use the Quoth mapobject_custom entity, has mangle and such.

At least thats what i do, not sure if vanilla progs handles this so easy.. 
yes, be sure to place the bsp in your progs folder.

you can use progs/map.bsp or maps/map.bsp and both will work for the model path. only sounds are hardcoded to be in sound/xxxxx 
in fact, it's generally good practice to put any external bsps in a subfolder so you can keep things clean. unless you want to use a pak file in which case it matters less. 
Okay, thanks. Now, how do I place the external bsp into my map? 
how is the newest remake going? 
BSP2/2PSB WorldCraft To Radiant? 
Trying to open some .map files saved with WC in Radiant but keep getting.

parse error at '[': expected '#number'

The maps are also BSP2 sized.
GB, you have experience with this? 
WC uses a different .map format from Radiant.

I don't know if WC has other limits that could possibly be BSP2 related; the only thing I think I have heard is that it can't properly display maps that are bigger than 8192x8192.

There is a converter program by a person called Scrama, I believe, you might have some luck using the forum search. It is somewhat obscure though. You will also have to convert the texture wads between WC and Radiant. :-s

If it only needs to be done once, using some converter is acceptable, but daily WC <-> Radiant conversion in any halfway productive environment, eg in a team setting, isn't very good for the workflow. I have lovely memories of this problem from RMQ. 
God Bless Standardization 
I thought the only difference was .rmf
I Just Need The Brushes Though 
It's for something of a spinoff map... 
I'm not 100% and can't check right now, but I think TB will load this map fine and save it as a standard .map file. Although the texture alignment info will be fucked, naturally. 
Actually, I just remember I did use TB for exactly this in the past... must have been some hazy late night troubleshooting, haha. I'll try that! :) 
That is good to know. 
Actually, it's still not working in Radiant, exact same issue... like I said, I was probably only half awake, lol. 
Useless Google 
I search "worldcraft" I get a dozen of useless pages about World of Warcraft. Sigh. 
The Utility GB Was Talking About 
So it still exists? Someone should archive that :-p 
not sure how to extract textures from those rmf files though. But you probably have access to the wad3 files. 
Actually That Link Is The Old One 
And the new one isn't in Russian :P

I'll put it in the wiki :D 
Utility Is Only For HL Maps It Seems 
I'll get out mah ruler! 
That's Strange 
I have tons of maps and map scraps that were created in Worldcraft (1.6) and I've never had any problems opening them in Netradiant. 
Oh Wait 
I guess you mean that Valve version of Worldcraft? 
huh, IIRC I have used it to convert WC maps in the past.

Then maybe the problem is something entirely different? Now I'm confused. 
Worldcraft was hacked to work on quake by varios people, the final package being assembled by Baker.

HL maps basically are quake maps, the only difference being the texture format of hlwad, and that is only used by worldcraft, the bsp still compiling with normal quake textures.

Worldcraft .maps have extra texture coordinates that allow things to be moved about more freely than other editors (at the time at least) allowed without mucking up the projection.

It sounds like the .map you're looking at is corrupt, have you tried opening it in a text editor like notepad++ or something? I don't know radiant but I'm assuming it tells you on which line it's failing.

Afaik bsp2 makes no difference to the .map format. 
The .rmf doesn't hold the textures, you can just extract those from the bsp using texmex.

You could also try downloading Baker's worldcraft 3.3 adapter package. Not saying you learn wc, but it could help you to fix the error and the package has texture converters inside... although I'm not sure if they'll be able to spit out a normal wad after chewing on a hlwad. 
The Quake .bsp will not have the textures in Hlwad format. The only use for the Hlwad format is to get the textures into the editor. You still need the regular .wad to compile the .map into a .bsp because the compiling tools require them.

The biggest advantage to using WC 3.3 is that you aren't going to be violating any copyright laws as it's 100% free while AFAIK WC 1.6 (full) was never released to the public for free when Valve bought the rights to it. There's no good reason why that I can think of but perhaps they just figured that it wasn't really needed to go through that extra step due to the age of Quake.

Someone could probably write Valve and ask that they release it as freeware and they might do it if they have the time. 
I Think 
That's been asked a few times actually, to the sound of silence.

I used to use Worldcraft, but Trenchbroom is better. 
You guys didn't buy Worldcraft when it came out? I still have my original version 1.1 disk with the paper receipt from ACD Systems. 
I Linked 
The full 1.6 version on another thread. Not sure about the legality of that, but it's not for sale anymore and I'm not hosting, so...

The only difference AFAIK is being able to use the prefabs system.

1.6 doesn't have the advanced texture snap that 3.3 and later provide, and there are a few glitches in there that can be annoying. 
One thing I always liked about the old Worldcraft was that it allowed you to move individual vertexes anywhere you wanted to, even if it would be an invalid brush. NetRadiant infuriates me sometimes because of the automatic checking and rearranging of other vertexes just to keep the brush valid. Sometimes to get from point A to point B you need to pass through invalid shapes. 
I Still Use Worldcraft 3.3 And 3.4 
It's fine! Tried Trenchbroom but it's too different, I don't feel like I get the control and precision I want with it as easily as with 2D editors.

As for 'the compilers requiring .wad to work', not true, there have been compilers that support hlwad for ages now. Haven't there? 
Trenchbroom is the greatest editor of all time! 
Nope, you still need the normal wads afaik. 
TrenchBroom Is Unstable. 
It crashes when I add Quake.Wad to map properties. Maybe I'm using the wrong wad? I'd like somebody to post me a working link here. 
Try This 
It Worked, But I Still Have One Problem. 
Vertex mode. Trying to enable it crashes the tool and gives a shithole of errors. I wonder what's the creator's mail so I could send the log here. 
I didn't notice your nickname, Sleepwalk. Do you need the log anyways? 
Here It Is Anyways. 
Go To Preferences 
And set Instancing Mode to Force Off. 
Ijed - RE: Compiling With Only .hlwad 
I just did it.

I opened my .map file in np++, checked the texture location in the header. It says "blah.hlwad". So I'm like 'heh - thought so!'.

So then I went into my texture's directory and renamed my .wad files to whatever_meh.wad. (adding '_meh' obv.)

Compiled again, worked! Loaded into the engine, textures intact.

WC3.3 + TxQbsp std. 
+1 To Ctrl+Z-ing A Bunch Of Windows Rename Operations :P 
It's right here, near the top....

'Support for Valve WAD3 format.' 
It's Nice To Be Wrong 
It Worked Thanks! 
i've wait for 5hours with the classic converter, but with wally i made it in 5min 
I want make map for Quoth2. How I can use self palette.lmp and conchars.lmp with this mod? 
I Don't Know What You're Talking About 
but I am excited about you making a Quoth map. 
All you need is the entity definition to make it and the mod to test it. 
Most compilers don't support HLWAD (Tyrbsp doesn't anyway). That's why I said that and it's probably why the docs for TqBSP specifically mention that is does support it, it's not a normal behavior for Quake BSP. I found that out when I moved the .wad files before compiling and ended up with a level that was all pink checkerboard textures. 
To Digs 
Digs: I think what you're asking is how you'd use custom graphics like console characters in the Quoth mod. I'm not clear if this is something you want to do personally or it's something that you're planning to go with your map (replicating the trick zerst�rer pulled to get the � character in quake is a potentially valid reason to need this).

What makes it difficult is that Quoth already has a custom character set in order to display e.g. the flashlight meter graphics. From a creative point of view it means you need to preserve the quoth characters in your custom set. There's a practical side too: Quoth has the custom characters in its pak files, which gives them highest priority.

So the ways of overriding that pak file priority are:
1) Opening the pak file and deleting the file, then placing your custom file in the directory.
2) Opening the pak file and replacing the conchars with your custom set directly.
3) Adding a pak file with a higher number (pak3.pak) having the custom conchars file within it.
4) Create a new mod directory, then run that mod using an engine that supports the "-quoth" command line command to import files from both your mod and Quoth.

Options 1 to 3 would be fine for personal use. 3 has the downside that sometime in 2016 Quoth 3.1 will come out and overwrite your pak3.pak file. 1 and 2 would need to be performed manually if you reinstalled Quoth. If you're planning this feature for the map release then 4 is probably the right approach, but bear in mind this still makes it a bit more effort for people to play your map, so you need to weigh that against the value of the custom conchars. 
Yes, the fourth option a little more difficult for the users. But he is the best in my opinion. I will use it. Thank you! 
Just because you're driving around in a mini-cooper doesn't mean that cars cannot travel above 200mph.

What version of TyrQBSP are you using (!?!?!)

I just compiled a map using tyrqbsp and .hlwads and it compiled just fine, textures intact.

Apparently this feature has been supported by tyrqbsp since April.

Not wanting to put any compilers down (past or present) I shall just say also, FYI, that there are a lot of Quake maps that would not exist today where it not for TxQBSP. IMO it had been the standard (i.e. the best) for a very long time, and was included with Worldcraft3.3-Quaked if I recall

So, basically, I don't understand where you're coming from.... 
QuArK Pipes Tutorial 
For those who use QuArK, here is a pipe building tutorial link made by Felikkz7

This is awesome... 
You�ve posted this already i think...
but its great! 
that there isn't an easy option like UnrealED's 2d shape editor. You could do this with only a few clicks, literally takes less than a minute. 
While this is nice, patch meshes and Darkplaces probably get the job done too. I'll never understand why people don't use that stuff more to make Q1 levels. The results can look identical to those images. 
GTKRadiant With Q2 Mods 
I've always been a BSP guy, but I figured I'd give GTKRadiant another shot. I'm trying to get it to work with my Paintball2 mod (base dir: pball), but GTKRadiant seems dead set on using the baseq2 directory, even when I try to manually load a texture directory or set the base path in the project settings.

How do I make it uses textures from a mod dir other than baseq2? 
Possible Help 
I don't know about Q2 or GTK, but with Netradiant and Quake you put all texture wads in the id1 folder, nowhere else, and it finds them automatically. 
How do I make it uses textures from a mod dir other than baseq2?

Under "Project Settings", select "Custom Quake 2 modification" and enter the name of the mod's gamedir. 
"Custom Quake 2 modification" is not an option. The mods are all "Quake III" related. I set it to "Quake III modification" and set the fs_game to "pball", but it still keeps trying to use baseq2. 
Never mind. I guess it just had to be restarted in order to take effect. 
Fog And Trains 
Two questions.

Is there any way to set r_skyfog in the map?

Is there an easy way to change the sound on a func_train? 
No And Sort Of 
I'm not aware of an engine that allows setting sky fog independently from the normal.

All it would do in any case is apply a flat colour over the top, since sky has no distance... You can achieve the Same effect if you open the images in a graphics editor and apply a colour layer.

Trains have a 'sounds' key, which is just binary 0/1 which gives you silence (0) or the classic quake train(1) sound.

Changing this in the qc is pretty trivial, and many mods have already done it, usually allowing for custom sounds to be map defined. Extras r4 / pox mod springs to mind as having e best extended train functionality. 
Fitzquake has a r_skyfog and setting it lower than the default 0.5 does reduce the amount of "fog" applied to the sky.

I'm using a sky box that is a dark, cloudy, night sky with a large moon visible. Even small amounts of fog lighten the sky dramatically causing it to look not at all like night time. Changing r_skyfog to 0.2 is a big improvement. I've tried just using lower RGB values for the regular fog (0.2 .05 .05 .05 currently) which helps but reduces the normal fog effect to where it's almost unnoticeable. 
Ah, Didn't Know That 
Ah Ha 
Remembering how sock was changing gl_texturemode in his maps, a little research led me to this page at the Tome of Preach.

Looks like I would need to use a quake.rc file to set r_skyfog.

Tome of Preach looks like a great storehouse of Quake info. I think I'm going to just sit down and read it all. 
Preachs Site Is A Well 
of qc boundary pushing. highly recommended. 
Yeah, if you're making your own mod then that's a good way to do it - but only if you need the same setting for all your maps!

Another approach is to have a custom QC entity which sends commands to the player's console during the map. This lets you build maps with different settings for the various console commands you have created.

Quoth already has an entity like this:

It's the moral equivalent of the following QC code:

stuffcmd(player, "r_skyfog 0.3");
I only need it for this map because the skybox just looks bad with any amount of fog. I have a custom progs.dat but it's nothing special because I am not a programmer. I consider it completely optional, but I guess I could try a custom QC entity anyway. 
Two Things 
Preach is one of the people that keeps this community going. Without a doubt.

The other is that qc isn't really coding, it's just scripting. Once you open it, look at a few variables and read some of the tutorials on inside3d it's a free bar.


I'm a bit drunk.

Doesn't invalidate anything I just said though.

Whatever it was. 
That Thing About Preach 
Definitely not invalidated by being drunk. 
I'll Let That Sleeping Dog Lie... 
No Triple Meaning 
There is a ton of good stuff at Tome of Preach. I now remember going there back in the spring. I switched to a different computer for dev stuff early in the summer and didn't copy my bookmarks from the old Athlon 64 I had been using. I bet I had it bookmarked on that machine though. Excellent site man, thanks :)

I played around with spawning a trigger this morning and had no trouble getting it to work. Much more stuff to read. 
Fitzquake Crash 
I've got a mesh, that if created causes a hard crash in Fitzquake.

Condebug doesn't give me any readout of the error, nor does developer 1 - it just hangs before crashing to desktop.

Other engines (FTE, Tyrann's) have no problem with the mesh in question.

I can't see anything in the documentation, is there any known issue with this? 
FYI, Fitz crashes if you set a skin on a model that doesn't exist.

I'm generalising gibs and different types thereof. 
ijed: if the skin doesn't exist, or if the model doesn't exist? 
Just The Skin 
It's a hard crash without an error message, which is what had me scratching my head.

If the model didn't exist it'd give me an error.

It seems the other engines I mentioned default to skin 0 if the qc tries to call a bad skin, same as with a bad frame. 
Interesting, I thought I had set it up to display a blue/black checkerboard texture when the skin is missing. Maybe some other changes have broken that feature. 
I thought it was odd when I figured it out. Ah well nobody's perfect :)

I doubt it matters, but this was with Spike's hack to make it usable with BSP2. 
Remember my cellshading sm134? It uses invalid skin numbers on purpose for the blue/black effect, and there's no crash. So it sounds more like there's another condition at play on ijed's end. 
But like I say, I fixed it by inserting duplicate skins on the mesh. It also only affects this particular mesh as well.

Here it is, if you want to check it out; 
GtkRadiant 1.4 
It's for Quake 3 but surely there are some experienced Radiant mappers around?

I had a system crash and now I'm kinda worried. In reinstalled and everything works fine. When I open the map in the editor, all textures are nicely aligned (except I'm missing some due to the crash). However, if I compile, regardless of what option I use, I get this:

Any ideas?

PS: If I build a new map, regardless which textures, the same happens. As if some value is off somewhere that's downsizing them. 
Antilights And Weird Classes 
I'm mucking about with weird entity settings as usual. Most of my experiments have found that no matter what classname an entity has, you can give it keys that light.exe recognises and it just works. For some reason, antilights only seem to work on proper light entities, not on these repurposed entities. I'm using benlight for these tests, has anyone ever encountered this and worked around it? Or does another light tool cope any better? 
I'm not quite getting what you are asking. Are you asking if someone has found a way to apply or tie a negative light to an entity as a sphere around the entity? If so I haven't seen it. 
Even the stock Quake3 textures do that? If not, then likely there is a disconnect between the Q1 textures you are seeing in editor and the textures the game is using (maybe there is a pk3 of half-size textures in your Q3 directory stomping correctly scaled textures in a directory you are using for radiant?)

If not, first thing I would look at is if your textures are being scaled down properly. Quake3 generally uses double-sized textures that are scaled down by half in radiant (so, a 256x256 for a 128x128 wall). Select a face in your map and bring up the surface properties, your x and y scale should be "0.5". (in 1.5 at least, there's a setting in 'edit -> preferences -> settings -> brush' that controls this default) I'd then save the .map and then look at it in notepad. You should have brush faces that look something like:

( 0 96 256 ) ( 0 32 256 ) ( -64 96 256 ) egyptsoc_mat/block01a 0 0 0 0.5 0.5 0 0 0

Where the "0.5 0.5" parts of the line are the texture scale. If Radiant showed you something different in editor vs when it saves, then there's a problem that I don't know how to fix :(

I don't believe there are any compiler settings that could be doing this. 
I'm not quite getting what you are asking. Are you asking if someone has found a way to apply or tie a negative light to an entity as a sphere around the entity? If so I haven't seen it.

It's a compiler issue I'm having, and I don't understand the compiler source code all that well. In general, the light.exe tool doesn't care what classname an entity has, it's only looking for the "light" key on that entity. You can give a monster_shambler the key "light" "200", and the compiler will create a light source at that point (obviously it doesn't follow the shambler, it's just static).

The other thing is that antilights - lights with a negative value in the light key which some compilers support. What I've found is that these two things don't mix. If you create two mapobjects with "light" "200" and "light" "-200", what I've found is that the antilight one doesn't have any effect. If you take the entities and just change their class to "light", suddenly the antilight starts working as well.

I think I've spotted a separate issue in what I'm trying to do, so don't worry too much about it, but it's weird all the same... 
AFAIK it was AguirRe who invented antilights, or standardized them at least. Maybe send him a direct email because I don't think he views this board anymore. 
I'm Probably Wrong But 
I would guess that when anti-light was added (negative light), that particular code only checks actual Light entities, whereas the original Light code (as you have noticed) just looks at everything.

Personally, I've always considered that to be a bit of a bug. 
Yes, even stock textures do that. Thank you for your suggestion. I checked but Radiant shows the right scales, just like you said. I did some extra checks:

It's not the editor. Regardless which map I make or load, everything works fine.

It's not the game. If I take old compiles or load the original maps. all is displayed normally.

It's not the textures. Even vanilla textures show the same problem.

It has to be a compiler issue. I reinstalled Q3map2 to no avail. 
A google search result that might be fruitful:;topic=1820.0 
Can't Compile Map 
Hey, I'm using necro's compiling gui and I get this error in the console:
Copying Files... The system cannot find the file specified. Converting map... --------------QBSP-------------- 'C:Program' is not recognized as an internal or external command,operable program or batch file. 
put the map in a path without spaces (it breaks at the space in "Program Files"), quake tools are a bit last century 
My man! Thanks to you I found the problem. After re-installing Windows I decided to sort through my old files and make everything tidy. This resulted in me installing Q3Map2 in a directory outside the Quake 3 directory. That's apparently the problem because I now placed it in the Quake directory and tada, it works like a charm! 
good. I might try that tomorrow. 
@Spirit #2 
Alrigt, It compiled. But I can't instantly launch quake and play my map on it, (I have the steam version BTW.) but it's alright now! thanks for the advice! 
Random Idea 
could a very low r_speeds limit lead to a "Quake the way id did" look? 
I Guess So 
Could be a good speedmap theme also..... 
Ogre Idle Sound 
Why do they have one? No other monster makes noise when standing still. It makes no sense. 
Ogre Idles 
Most monsters do play their idle sound while walking instead of standing. I'd guess it's because the ogre has a special chainsaw dragging sound when he hits the waypoints of his patrol, so they put the mumbling on the standing sequence so they don't interfere. 
Monster Idle Sounds 
The Vore has that grunting\wheezing noise that it makes (I think that's used while it's idle). 
All monsters have an idle, but they call it at varying times. Most will call it while in their run sequence (attacking you) at some point, as well as when standing still chilling out.

If you look through the sound folder you'll find them all.

Ogre has the additional chainsaw scrape as Preach mentions.

The idle sounds themselves add ambience to the level and give the player a hint of what they'll be fighting later on. Some have stronger, more recognizable sounds, like the ogre, or the Quoth Night Gaunt. 
I Don't Think So 
Basically, I'm trying to figure out why the only ambient sound in my map is from the sky. There's no water or lava noise. I think this is caused by the texture names I used.

Just to test, I built the map using the -noambientsky switch and when I move around the level using -noclip and -notarget, the only sounds I hear are from torches, sound entities such as ambient_drip, monsters that are walking a path, and ogres.

All the ogres make the rumbling sound when standing still, all of the other monsters are silent when standing still. 
You're right.

I just took a quick look over the qc and only the ogre is calling his idle sound while in his idle cycle.

All the others call it during their non-idle cycles, or during walk. 
How would I make them shut up?

I commented out both places in ogre.qc where that sound is called and they still stand there making that stupid noise. 
That should do it. The engine isn't calling any monster sounds directly.

So, I'll ask the dumb questions; did you compile, did you copy the progs.dat over?

I've failed on that many, many times. I'm also dyslexic when it comes to greater > or < less than. 
Facepalm moment - was just me being stupid and putting the new progs.dat in the wrong game folder.

Seriously, is this some kind of bug? Why does only the ogre make sounds when he should actually be silent, waiting to ambush the player? 
Thats lots of weird shit in the original qc. Like the ambush / crucified spawnflags and so on.

Probably the actual behaviour should be controlled by the AMBUSH flag.

So if that is set a monster is silent, if not then they make sounds.

I never realised one of the reasons I like patrolling monsters is that they make sound. 
@Rick Re Liquid Sounds 
"Basically, I'm trying to figure out why the only ambient sound in my map is from the sky. There's no water or lava noise. I think this is caused by the texture names I used."

That's the cause of that problem. Water, slime and lava texture names have to be the same as the originals (including any numbers such as *water04). Using any other name (say, *water07) will still get you all of the physical properties of the liquid (swimming, drowning, and fullbrights in that example. Replace *water with *slime07 or *lava07 and you will get those physical properties instead) but the sounds won't get cached because the engine wasn't told to look for them because the texture name didn't match the correct parameters.

This "Can" work in your favor if you have a secret that has water but you don't want the water ambiance noise to give it away because you have a different clue leading to the secret for the player to find instead 
I was guessing that was the problem with the lack of ambient sounds. I'm using *lavakell and a *rk_water that I made.

I guess I'll extract all the textures I'm using and put them in a special wish13.wad so that I can rename the custom lava and water to match the original id texture names. 
Liquid Ambients

your *lavaXXXX should work, but the water needs an name that starts with "*water" or "*04water"

But, isn't there an engine bug where either slime or lava don't generate ambients at all? my memory is fuzzy. 
I'm Checking Now 
Before I was definitely getting no lava or water sound. I've renamed *lavakell to *lava1 and *rk_water to *water1.

I now get sounds but it seems to be the same sound everywhere (still using -noambientsky).

Does water and lava use the same noise? Maybe because I didn't do a full vis the game just thinks I can see water everywhere and there's no lava sound at all. I'm doing a full vis now just to find out. 
Seems like you were right, there is no lava sound at all. Water and sky seem to be working okay.

Just realized my trick of using sky brushes to hold the lights and seal behind func_wall windows is a problem because I can hear the sky noise everywhere I did that, even though there is actually no sky visible to the player in those areas. 
IIRC, vis is what adds the liquid ambients to the map, as the engine uses the portal information to determine if you should be able to hear 
Increase Spotlight FOV? 
Is there a way to increase a spotlight's fov just like the one that was used in Backstiengotic?
(I'm using trenchbroom BTW) 
Also, Another Question 
In Backstiengotic, is it possible to make a built in skill selection part that changes the player's starting point when triggered? 
Not real sure what you mean by fov, but if you mean how wide the spotlight's beam is you just need to set the angle key/value. There isn't one by default and I don't know how or if you can add one in Trenchbroom. I think the default is some thing like 25 or 30 (degrees). 
Read This

It explains it all, but is mostly focused on bug fixing. There's a light section in there that explains the values and how to use them. 
There's Also... 
I might try that. 
Tronyn snuck another 2PSB map past my filters so I updated the BSP2 page at 
Compiling On Mac OSX 10+ 
What is the best way to compile a map with the newest MacOS? I'm using trenchbroom to make levels and it says there are compilers built in but I don't see any way to actually use them, which I don't understand. 
There Are No Compilers 
built into TrenchBroom (unless you're using the very old version which I released for Mac OS only about two years ago). You need to download the binaries yourself, for example from here:

Then you need to figure out the command line parameters (see the manuals in the downloaded zip file) and call them from your terminal in the correct location. 
Compiling Made Easy 
Use necros compiling tools.

It will make your life a whole lot easier. 
How To Use The Compiler - 
Here's a tutorial on how to do the initial set up, once it's up and running you'll be flying. 
Re: Necros Compile Tools 
I believe that those are for Windows and not Mac. 
Did he say mac? I wasn't paying attention at all. 
Beating 65535...BSP Faces Limits Tips 
Does anyone have tips for defeating the unsigned short integer limit of 65535 faces or verts in a bsp file?

I currently have in Worldcraft map info:
Solids: 14828
Faces: 90024

This number will probably reach around 150000 faces as I finish the map (I'm about 70% done). I have not compiled in over 10 months as it would probably take that long for vis to finish. Is it possible that I could still compile and beat the limit? I would like to stay within BSP if possible and avoid BSP2. 
try tyranns vis 
Tyrann's qbsp never works for me. I just tried his latest version 0.14 and it still crashed.

Most of my brushes are created to break up an otherwise boring wall into interesting textures. I have an idea to create a couple dozen textures for specific walls to be able to make just one brush instead of I dunno 5-10. But that raises this question:

What are the texture limits for standard bsp 29?
# of unique textures?
Max texture size (e.g. 4096x4096)?
# of instances of each texture?

I can't find the limits anywhere. Google has failed me. 
What Is Your Crash? 
With Tyrann's tools?

I've been using them exclusively so might be able to help. 
Maybe This Will Be Helpful 
Making Textures For Quake

Be careful about the max size, I once made a texture that was 320 units tall and for some reason the alignment was off at the top by a small amount, as if the texture height had been changed by a pixel or two. 
Actually, after reading that page again for probably the 10th time, the following finally sunk in:

OpenGL requires that all textures have dimensions which are powers of two (1, 2, 4, 8, 16, etc.) When GLQuake loads a texture with non-power-of-two dimensions, it resamples it, very poorly, and passes it to OpenGL with power-of-two dimensions. So it's a good idea to make your texture dimensions powers of 2 to begin with, to avoid ugly resampling.

Guess what? 320 is not a power-of-two. Duh.

I was probably a victim of the poor resampling. 
tyrann is an active developer, send him a proper bugreport with files to reproduce it and you might get a non crashing toolkit in days. 
Trenchbroom is being buggy on me! where the hell is the new update for the editor?! 
Re: Arg 
disregard that, I've got it to work for now. 
Please use the TrenchBroom thread to report problems, and if you don't give me bug reports, you won't see your problems fixed. 
And Remember 
SleepwalkR is doing this as a hobby, for fun.

In any case, how goes TBv2?

I see you knocking down issues on the devtrack at a decent pace :) 
It's going well, but there is still a lot to do... I can't really say when I can release something. 
Tyrann's Qbsp Finally Works For Me! Worldcraft Rounding Finally Gotme 
I got it to work. Had to compile as bsp2 but hey I have 80000 already and have at least 50000 to go before I sleep. And polys to go before I sleep.

I found out why Tyrann's qbsp "seemed" like it wasn't working. It stops outputting to the console after upteenhundred "WARNING: Brush with duplicate plane" warnings but still compiles.

And on that note. Is there an rmf to .map converter that won't round my smaller brushes' verts to x.0? 
Thanks For The Suggestion Spirit But It Was My Fault Not An Actual Bug 
Que Elaborado 
Ok, I'll stop now. 
MergeAll Compile Step QBSP 
What does WARNING 21 : Too many edges in TryMerge mean? I don't understand what this means in the docs:

// =====================================================================================
// TryMerge
// If two polygons share a common edge and the edges that meet at the
// common points are both inside the other polygons, merge them
// Returns NULL if the faces couldn't be merged, or the new face.
// The originals will NOT be freed.
// ===================================================================================== 
Maybe it means use better compilers? 
Are you trying to compile a map that is full of errors? 
Looks Like It's My Turn 
I added quite a bit of stuff in my map and hit the MAX_MAP_ENTITIES with TyrUtils 0.6, so I switched to a more recent version (0.10). The map compiles fine, however areas that receive no illumination are now fullbright, and this even with a minlight setup in worldspawn. Is there a way around it or am I doomed to use very dim lights with very big radii?

Here's a shot so show you: 
Do you have some delay 3/4 lights in there? From what I can see you must have some errant lights in there somewhere, the other alternative being a very powerful sunlight value, but I can't see any sky in the screenshot.

Also, minlight isn't required - not having it, or a value of 0 count as the same. 
I only use delay 5 lights, and the issue is present in the whole level, not just in this room. My sunlight value is 80.
I tried recompiling with TyrUtils 0.14 but no luck either. 
"...Trying To Compile A Map That Is Full Of Errors?" 
Full of warnings. Usually about duplicate planes from rounding (we hates the rounding precious yes we do) and the occasional brush face with an invalid normal. 
No Beep Message? 
Maybe I'm missing something obvious, but is there a way (in vanilla Quake, no QC) to display a centerprint message without triggering that "beep beep" sound? I've tried triggers and relays with the sound set to "0", but it doesn't work. 
try sounds/misc/null.wav.
Maybe that helps? 
That's a Quoth-only functionality. 
Replace the beep sound with a copy of misc/null.wav 
Create a new brush entity called "trigger_multiple". Set a new key: "noise" with a value of: "misc/null.wav" Set your message. Give the key sounds a value of 0. 
Sorry that last key is "sounds" with a value of "0". 
Thanks much :)

noise = misc/null.wav

Works. Why?

I'm going to try it on a relay next to see if I can save a model. 
Why? For Rick 
from triggers.qc

void() multi_trigger =
if (self.noise)
sound (self, CHAN_VOICE, self.noise, 1, ATTN_NORM);

multi_trigger is a function that is called when the trigger is touched/killed/used. the code plays whatever the trigger's 'noise' key is. the 'sounds' key/value that editors expose just switch (in the entity definitions for the triggers themselves) between several hardcoded noise values (which are also precached by the trigger) 
if you set a 'sounds', your 'noise' will get overwritten, so don't 
Has Anybody Else Ever Noticed 
that the wizmet1_2 texture has one rivet that's misaligned? 
Way To Ruin Negke's Xmas, Rick 
I'm going to include that texture in more maps from now on ;D 
What? Do you think that every bolt and rivet in the real world was placed with a micrometer in hand? It's tiny flaws like that in a texture that just take the reality of things in life and place it in the game. If you want nice shiny textures go map for Halo or something...

There, now Negke's Christmas isn't ruined (quite so much). 
Source Code To Sin Editing Tools. 
Hello everyone.

A long time ago, ritual released the source to their editing tools. I was wondering if anybody knew what to get it as it is no longer available.

I Bought Sin From Steam A While Ago 
Doesn't work in Windows7, I see they removed it from their catalog in the meantime.

The second one is okay-ish, but couldn't compete in the marketplace. 
Here's the catch to Sin editing ToolsI have form GoldenBoy.
It's all in there, scripting etc.
I tried it out but it's quite messy. 
Need Help! 
How do I change the radius of lights and how do I make doors in trenchbroom? 
Lights - add a new key (a data entry in an entity, like a light) by hitting the + button when you have it selected and are viewing the 'entity' pane.

It'll create one without any useful data inside, you need to first name it 'light' and then give it a value. By default lights have a value of 400 if you set nothing.

There are various others keys to be added to a light that can give you more control, but you're better off reading more comprehensive documentation for that;

To make a door select one or more brushes and right click on it. Select the option 'create brush entity' and then func_door.

These also have a bunch of keys to set for speed, distance and so on, this is a pretty good guide;

Good luck! 
Default Light Value Is 300!!!!!!! 
Thanks man, now how do I create a worldspawn entity in trenchbroom. If thats what its called 
TB Creates Worldspawn Automatically Once You Lay Down A Brush 
To edit worldspawn properties, select a world brush. 
Thanks. I think thats all I need to know, sorry for all the noob questions 
Change Waterlevels 
HI - Complete noob with mapping...I have Quark and Trenchbroom and some other editors installed, but am clueless on how to alter waterlevels. Probably because I dont understand concepts of the brush too much.

Lets say I want to change the waterlevel on E1M3 so thats its nearly topped off. I think that probably is sort of simple, but how? Next, the tunnel leading off has to now be immersed to a certain level, and also the plat area near the stairs has to be filled. How ? Any help appreciated. 
You Mean... 
have the water change level or move? I don't think this can be done in standard quake. There may be a mod for it but certainly not in standard mode. Maybe you could fake it by having the entire map submerge instead? 
Yeah, water is just a brush. You can select it, then change the size in the editor, but I don't think you can change the size dynamically (while playing the map) in regular Quake.

I suppose you could you put a *water texture on a func_door, but then the player couldn't get inside. I think one of the expansion packs added a func_water that could move. 
I Think 
He means changing the water in literally e1m3...

Quake maps are compiled into a format (.bsp) that is not editable. So to change e1m3, you would need the original source .map to work from in an editor like trenchbroom, and then recompile it with your changes. 
You Can Get The E1m3 .map File Here 
There is a way to "Trick" the player into thinking that water levels are rising (or falling for that matter).

Essentially you turn the entire room into a platform (a "Platroom" if you will) while the liquid brush is stationary (you can't actually move a liquid brush in-game using Vanilla Quake that I'm aware of, if you try to tie any entity to a liquid textured brush it will become a solid or disappear IIRC).

So you can get the illusion from the players perspective that the water level is changing as the "Platroom rises or falls just like any other platform. Of course it's a sloppy solution and you have to enclose the "Platroom" inside of another room in order for it to vis and some entities will act a bit funny, but it will work. I've seen it done way back when in one of the earlier player made maps on a compilation CD. Aftershock maybe, it's been a long time.

If you're asking how to insert a liquid brush into a map it's just like any other one as far as editing goes. The liquid effect is a direct result of the texture name as long as it starts with an asterisk (*anynamethatyouwanttogiveit) and the sound effects for them are tied to very specific texture names (*water02).

The default behavior is water as long as the * is there as the first character. If you want lava or slime then the name HAS to start with *slime or *lava. 
Wasn't There A Liquid Mover? 
I'm sure someone mentioned a liquid mover for one of the expansions or something...

Or maybe I was dreaming a sexy sexy quake dream. 
Thanks Guys... 
Yes, I am wanting to do what Scampie says. Edit the .map so the water levels on certain maps, like E1M3 and E2M2 are higher overall. Doing so will result in some other areas of the map needing to be "flooded" so not only are we merely editing an existing water area, gonna need to add some new water to tunnels and other connecting areas that the water will now flow into. 
I'm 100% Sure... 
That the official expansions didn't have "Moving" water (a push brush above a repeating water flow texture is not "Moving water" ;) ).

That extra code (rising or falling water levels) is really something with limited use in a game like Quake in my opinion. While I can see it being used to force the player to get through (or perhaps backtrack through) an area as quickly as possible in some limited scenarios I don't see it happening a lot while making liquid brushes a lot more complicated at the software end. But there are other ways to get there anyway if you really wanted to get the player to run back out in a set time frame without liquids being a factor.

Quake is set in a fairly dry setting (damp yes, but the liquids are almost always there to break up the levels BSP-wise in most maps if you pay attention to that sort of thing due to the way vis works). id was smart about hiding the limitations of the engine from the player but if you know where to look behind the scenes it starts to become obvious pretty quickly.

Then again I just watched the latest Sherlock so who knows, I might be looking for things hidden within things placed behind things with other things being pure fiction and a total red herring meant only to cut down shrubbery in the French forest of NI!

I do believe I will have a beer instead of thinking about this anymore. 
Are you looking to re-envision the level or simply add water as the level progresses? The first is fairly easy while the second is not at all easy (or may not even be possible). 
Not looking to change map geometry. Just the areas that have water in them that the maps came with , increase them higher. Like the moat in front of the castle on E2M2 for example. Some other areas on that map may be interesting with higher water levels too like under the bridge near the teleport. Raising the water there woudl mean also taking a look at the small connecting stairway that has a grenade launcher , where the big door opens. The stairs probably would need more water added, because if you add more water to the main area, that area would need more added than what it has now. 
Changing Water Levels 
would have helped me greatly with deck, rather than having a slowly lowering platform I would have much preferred to put a rising slime trap (at the grenadelauncher/shambler ambush).
But the code didn't exist so the trap ended up being quite frustrating for a lot of players.
I can imagine a lot of interesting chase maps developed if there was moving fluids, imagine being chased by a wall of lava through a map (like the lava chase in marble zone in sonic 1). 
Altar Of Storms 
comes to mind, i do recall some rising lava threre.. 
Rising Water 
I used it in FMB-BDG2. It served two purposes: one, to get the player up to a platform to enable escape from an area and two, to gain access to a semi-secret area that conatained a rune. I thought it worked quite well, but then I never had to play the map :) 
Func_water Is Awesome 
But my current implementation is invisible :L 
And fish get stuck in it :{ 
Trigger_counter Won't Count Different Monster Types 
any suggestions? 
What A Fool I Am... 
I just figured out how to set counter number limits. all fine now. 
Double Doors With Toggle Flag Won't Open 
how do I fix this? 
Are They Triggered? 
Toggle only works if a door is given a targetname and therefore can be toggled. 
Try A Crowbar... 
Oh wait, that's for Half-Life isn't it.

Go to the Quake Wiki. It has an entry for func_door that says in part.

"By default doors will automatically open when a player or monster is near, and close when they leave. This only happens if the door is not locked and doesn't have a targetname.

If a door has a targetname, it will only open if another entity triggers it, such as a button or trigger.

If a door is locked, it will only open if the player touches it while holding the correct key. If this happens, the door will open and stay open permanently, and the player loses the key. " 
i think you have to still set the 'wait' '-1' so the door stays open though, for key doors. 
Wait -1 
I think that the Wiki entry means that it stays unlocked (open for passage) otherwise it acts like any other door does from the point that it was unlocked onwards. 
They stay open by default ricky 
wait doesn't need to be set, the qc code of func_door sets the door's wait key to -1 if it requires a key. 
You may need to check the "don't link" spawnflag. Doors in Quake can be weird. I think I have a test map that shows "lip" being completely ignored for some values, and using a door, you can push items through solid geometry (only in certain directions though). 
The Doors Are Triggered And Toggled, But Won't Open 
check for cross connected doors. these are doors who's bounding boxes touch. There is some code that groups doors together if their bounding boxes touch and they can override settings on other doors. 
I'm Just Wondering... 
Anyone know of a quake texture wad containing every single quake 1 texture? (Wizard,base,metal,rouge,etc.) 

Look at! Quake.wad should be it, 
or quake101.wad? 
Link, MFX? 
If you mean everything, not just the id textures, then I don't think so. It would be huge. I think there's one called id base ultimate, or something like that with all the base textures from Quake plus the two expansions. 
Here, Knock Yourself Out :) 
I ment the original quake's textures. 
Google, RoQ? 
Look there roq, its the 2 files i told you. 
This one...

Has all the stock textures I believe. 
Disregard That, 
I found one called id.wad it has every texture imaginable in quake. I'm fine now. 
As Mfx Said 
At the link in my previous post, look for, inside is quake101.wad, I think it has all the original Quake textures. 
Adquedit V13 
I want to edit the ents and textures of a map with adquedit but the program can't seem to open bsp? 
Is so old that the map that you're trying to get into might not be supported. Does it meet ALL of the vanilla Quake requirements (Size, entity count, not BSP2 and so on)? If not then that's probably your problem. If not then I have no idea why it's not working.

If the above is true:

Without a .map file then you are probably not going to do much. With a map file you can change what you want re: entities and recompile the bsp using -onlyents and it won't mess with the vis or lighting.

For the textures you will also need the .map file but you will probably have to re-vis the level. To swap out textures you can open the .map in a text editor and do a find - replace to quickly swap textures. Just keep in mind that if the 2 textures being swapped are different sizes you may not like the results. 
You can use winqbsp.

program allow you to decompile *.BSP ready in the original format *.MAP

It's not the original map file you obtain, but it can help you to trace the ents and tex. 
Adquedit V13 
How do I use Adquedit?
Maybe I didn't set up/use it correctly 
Adquedit V13 
Forgot to mention that the maps I'm trying to edit are: the stock Q maps and DOE & SOA maps 
Adquedit Manual Download Link

It's for v1.25 but it should cover what you need to know. 
Texture Replacements Bsp 
What other texture replacement programs are there?
I've tried Adquedit and TexMex and they both don't seem to work 
I connected the func_door with the func_button. The door has a "message" property. But if I open the door once, then I will not see the message. How to avoid it? 
It's Not The Right Thread, I Know... 
...but it's a tech related question for ya eggheads.

Point is, I bought Rage+DLC and Doom3 BFG on steam and tried to run them both on parallels 8(no dual boot for me, thanks) and they just don't start giving back a supposed card driver issue. Any idea or workaround?

Keep in mind that I played on parallels Batman Arkham Asylum, Necrovision, Dishonored from Steam w/o problems on win7.
Plus, not from Steam, DN4ever and Wolfenstein 2009 and everything went smooth as possible.

I even played RAGE (mac version, w/o DLC) on the same rig.

Can anybody lend a hand?
Just a guess but Rage and Doom3 are OpenGL games, I think most of the others you mentioned are DirectX. It's possible that has something to do with your driver issue. 
"Point is, I bought Rage+DLC and Doom3 BFG on steam and tried to run them both on parallels 8(no dual boot for me, thanks) and they just don't start giving back a supposed card driver issue. Any idea or workaround? "

Dual boot. :) 
System Time 
When the console is dropped down all QC functionality is stopped, but there seems to be a system clock running with Fitz clients. Is there anyway to check the system clock from QC? 
I connected the func_door with the func_button. The door has a "message" property. But if I open the door once, then I will not see the message. How to avoid it?

A message set on a func_door is only used when it's touched, and then when it actually is opened by any means, it sets it's message field to ""... so you'd need to do something else, like put the message on the button, or maybe on a trigger_once slightly behind the door that opened. 
meant to post the qc...

void() door_use =
self.message = ""; // door message are for touch only
ok, thanks 
if there's a system clock, it is completely disconnected from qc. qc is only aware of game time (without engine extensions at least). 
if there's a system clock, it is completely disconnected from qc
The console being brought down pauses QC, I want to know how much time has passed. I was hoping I could query a system clock (engine level). I know the engine is maintaining a clock because I found the MarkV engine shows time passed with the "status" console command. 
I'm getting strange leaks in my map and I don't know how to fix them. I feel like my map is broken again and I won't even bother to fix it or continue it! sorry for the disappointment guys... 
Are You Using Quark? 
or maybe some carving function? 
No, Trenchbroom Level Editor... 
I honestly feel like I don't want to continue my map anymore. I'd rather bin it and start all over again. I apologize for not finishing it. 
I Forgive You! 
I would try to find out what caused the leak so you avoid running into the same problem. 
#13505, #13506 
Thanks, Rick. Parallels seems to have open gl problems indeed...

And thanks Willem, even though you Bootcamped me. 
What kind of leaks, like going straight through brushes?
How many are there, and what compiler do you use.
Try to not use the -forcegoodtree switch(in case you use it) 
Just finish the map, then once you've "sealed" the map from the void if it still leaks just get someone else involved with the map and they'll help you fix it. I guarantee someone will help you. 
Binding 'snap verticies to grid' to your spacebar and banging away on it like a madman as you do terrain. 
Ijed Speaks De Truth. 
Seriously, someone else mentioned this too and it really works wonders IMO. 
I'm Ashamed To Say... 
I won't be continuing work on this map and I've disappointed you all and I am disappointed myself. encountering errors like this is just another way of learning to map and hopefully I won't make the same mistakes in my newer map.

Sorry guys. :( 
You're getting micro leaks between the brushes, this is just how TB works, for now at least.

There is also an option 'force integer snap' but this leaves it difficult to make anything that isn't a box.

I notice a similar problem with texture alignment as well - rotated brushes often end up with .36381819 scaling and positions. This inaccuracy seems to cause drifting as the brushes get moved around.

Shame I only noticed after duplicating a shit tonne of wonky crates around the level :L 
You're getting micro leaks between the brushes, this is just how TB works, for now at least.

There is also an option 'force integer snap' but this leaves it difficult to make anything that isn't a box.

I notice a similar problem with texture alignment as well - rotated brushes often end up with .36381819 scaling and positions. This inaccuracy seems to cause drifting as the brushes get moved around.

Shame I only noticed after duplicating a shit tonne of wonky crates around the level :L 
Force integer snap does NOT make anything difficult. It just prevents you from creating invalid brushes and it should be enabled at all times. You will have less leaks and you won't have to snap the vertices to integer coords anymore. In fact, what you're doing restricts you a lot more than just leaving the "force integer plane points" option on.

And what do you mean that rotated brushes end up with that particular value for scaling and position? 
I tried it in a much earlier version and found it very restrictive. Didn't mean to crap on your editor!

The drifting is that the decimal values appeared over most of the rotated crates I've got, and the alignment has gradually shifted as I duplicated them around the level. It's probably you've already fixed this, since I've been building this map for quite a few months now.

I actually have a few test maps to send you on the bug tracker, a hard crash and the texture drifting issue. Probably of academic interest only, since I think these should both be corrected with Trenchbroom2, from what you've mentioned of it.

I'll try and get those maps to you next week in any case, give me a nudge if I forget / am too slow. 
Thank you! 
Looks Like,,, 
.. TB suffers from the same floating coordinate issue QuArK has... 
Yes And No 
everything will be fine if you check the damn "force integer plane points" option in the map properties.

TB offers you the freedom of using FP face coords, but it should only be used by someone who absolutely knows what they are doing. Which is why it should have been disabled by default :-( 
It Should Be The Default. 
But inaccurate or floating vertices have plagued every single game editor I have ever used. Back when I was mapping for Unreal Tournament I noticed if you have too many vertices occupy the same area in the grid then the grid snapping stopped working and they acted like 2 magnets with the same polarity.

It also depends on which compiler you use too, I find BJP's TreeQ tool to be the best compiler since any microleaks tend to be fixed due to it only allowing vertices to 2 decimal places. At least I think that is how it works. Plus the pointfile it writes if you do get a leak works well. 
the problem aren�t values like 34.348827.
Thats most like an editing error made by the mapper.
More annoying are values like 256.00187.
Which occured to me when for example aligning textures on that a brush in Quark or Radiant with ETP enabled.
Snapping the vertices back on grid again garbles the texture alignment :( 
What Do You Mean, Mfx? 
You mean when you snap vertices to the grid in TB the texture alignment somehow becomes corrupted? 
This is nothing compared to the hilarity of the Doom3 .map format's floating point issues.

For some reason in D3, id made the "genius move" of storing brush planes in the map file in the (distance, normal) format, so any plane that's not orthogonal (i.e. doesn't have a unit vector normal) is going to be stored with a certain amount of inaccuracy. Simple operations such as moving brushes around in the editor result in degradation of your plane equations and everything ultimately ends up off grid by a tiny amount.

I also believe planes drift every time you load a map into the editor, so your map slowly decays over time, like that badger carcass in the grass verge that the kids can't stop poking at.

The doom3 compiler however welds nearby vertices, so your cracked, leaky maps actually just seal themselves and it rarely causes an issue (or is noticeable) in the final map.

It does, however, make absolute mincemeat of your OCD, and is one of the reasons I just couldn't face D3 mapping any more. 
vertices would be whole numbers only in most instances? I can understand that if you clip across a face that it would then have a vertex off the grid depending how you clipped it?

I think I have learned to stick to the grid as often as possible even with clipping. I used to clip to make circular shapes but I try to use vertices now so that I don't get wandering geometry. 
I meant mostly quark, and it occures in Radiant irregulary. TB hasn�t got that issue to me, as i�m texture-finetuning in an editor capable of ETP. Meh, i know but i�m a bit pedantic when it comes to alignment:) 
What's ETP? 
Simple operations such as moving brushes around in the editor result in degradation of your plane equations and everything ultimately ends up off grid by a tiny amount.

I also believe planes drift every time you load a map into the editor, so your map slowly decays over time, like that badger carcass in the grass verge that the kids can't stop poking at.


Fuck. At one point (before I gave up) I was building 95% of my map geometry in Max to stop that happening because it was driving me crazy. 
Re: Floating Points 
I think it's important to mention there are 2 places where floating points can affect a map file.

Quick synopsis of map file format:
Brushes in .map files do not store vertex information at all. Instead, all the faces of your brush are converted into infinite planes, and the editor and compiler figure out, at run time, where the vertices of a brush are by doing the intersections of each of the infinite planes against the other planes in the brush.

The checkbox Sleepwalkr is talking about forces the planes stored in the map file to be integers.

Here's the thing:
You can have a brush face that was all it's vertices on grid but it's plane is floating point. Rounding the face plane to the nearest integer can make the vertices off-grid.
If this happens at run-time with not-as-good compilers, you get leaks that don't appear in your map editor.
All good compilers support floating point planes (like Aguirre's TXQBSP and other new ones).

Sleepwalkr: Is there ever a chance that having Force Integer Plane Points checked will round a floating point plane as to create off-grid vertices?
This is why I am afraid of using that option. 
Insane, Off The Wall Question: 
If an editor wrote vertices to the map file instead of planes, could we make a compiler that creates standard Quake .bsp files from it? 
Hah, that Doom3 story is great ... so they created a problem and then patched the tools to compensate for it. I wonder what they were trying to fix in the first place. 
TB doesn't simply round the plane points. Instead it will find integer plane points that represent the original plane as closely as possible. However, some planes cannot be represented with integer plane points at all, e.g. a plane whose normal is the Z axis, but which is offset by 0.5.

To answer your question, since the result of the plane point finding algorithm can differ from the original plane, your vertices can change. However, TB will take this into account as the algorithm is applied whenever you perform a vertex operation. So what you see in the editor is what the compiler will produce also. I would say that this is what you want in most cases.

As I said earlier, if you know what you're doing, you can get away with using FP plane points, but you will likely run into microleaks sooner or later.

TB2 disallows floating point plane points altogether for now. If there is demand, I will bring back the option to use them, but it will be off by default. In any case, the editor will warn you about floating point plane points, and you will be able to auto-correct them using said algorithm in one fell swoop.

As for writing vertices to the map file: I think this should be possible, but the vertices would have to be stored in HEX format, which can be stored in text files and read back without loss of precision.

But I think that using integer plane points is the better option, because it retains compatibility with all compilers out there. TB2 can be used to map for other games, where such compilers will surely be unavailable. 
When I'm working on a map, I never continue if there are any errors or leaks in the BSP process. I will either fix the problem or revert to a previous version of the map.

I keep my maps in a separate folder from where the compilers are. I copy the map to the compiler folder and then run BSP, Light and VIS from a batch file. After that process completes, I rename the map copy as Name (what the major changes were).map, and continue work on the original file.

While working on Wish13 I have been including the marksurfaces count in the renamed map file just to keep track. I also try to work on either brushes or entities and textures only in a single session. Too many times I've lost a lot of lighting and texture changes because I also changed some brushes and then had the marksurfaces count go insane. 
Enhanced Texture Positioning. 
Hah, that Doom3 story is great ... so they created a problem and then patched the tools to compensate for it. I wonder what they were trying to fix in the first place.

Honestly I don't really know what they were trying to accomplish by changing the way that brush planes are stored. The only benefit is a smaller filesize (it's only 4 floats to store a plane in the (normal,distance) format vs. 9 floats in the (pointA,pointB,pointC) format).

But was map filesize really such an issue that it was worth having such nasty side-effects?

One of the Doom3 community guys (it might have been Sikkpin) got so pissed off with this, that he modified DoomRadiant to use the old quake brush format (it was an almost trivial change apparently) and all the problems just went away.

To late for me though, I've long since lost interest in D3. 
What does that mean? 
Its a term used in relation with the valve 220 (Hammer) file format i think.
You can shear textures with this for example.
Some of the light compilers support it by -etp switch. 
How Long Till Compilers Support -otp 
You Did That... 
450 warnings? 
Possible Theory 
I thought I'd mention that the Quake compiler actually works internally with those Doom 3 style plane definitions - it calculates a normal and distance from the 3 points when it's computing the BSP. So maybe the thinking was to make the map format more closely match what the compiler sees. I think I'd agree with Kinn that it's not a wise move though. The Quake compiler also has limited healing - when it creates a "new" plane it tries to match it to an existing one, and it will merge a pair of planes that are "close enough" in angle and position. 
Action At A Distance 
Incidentally, merging of planes offers one (of many) possible explanations as to why adding or removing brushes can affect remote parts of a map. Suppose a brush on the left of the map has a plane which is "equal enough" to that of a brush on the right hand half. Whether left is merged into right or right into left now depends on which brush compiles first! And if you delete the former, then the latter slightly changes.

I understood that one of the useful properties of BSP trees was that it was easy to merge two together. Does this mean that we could make a compiler that builds a bunch of rooms independently, then merges them together? Obviously there's not just a technical issue of whether such a thing could be written, but also a practical question of how to tell the compiler which brushes are part of different rooms. But it would certainly deal with some of the weirder cross-map interference issues. I wonder if the detail brush code could be a launching point... 
Yeah, with Quake, you always lose a bit of accuracy at the compiler stage when it turns those 3 points into a normal,distance - but it's a one shot deal and what you lose is negligable and usually harmless.

In Doom3, those inaccuracies just keep piling on top of each other just by doing routine brush manipulation in the editor, until that time when you zoom in to raise a decal off the floor by 0.125, and all those cracks and misalignments stare back at you like a British smile. 
I totally agree it's a change for the worse in the .map format. It was just a really good opportunity to explain that aspect of the compiler - the merging of similar looking planes isn't well known - once you'd done the groundwork of explaining the format for us! 
Worth Mentioning 
The D3 problem is worse the further you are from the map origin - and also worse if the geometry is grouped under an entity (as it involves an extra calculation to offset the brush local coords from the entity coords) 
I suppose this planemerging creates leaks in hull 1?
Instead of having visible gaps between brushes (hull 0 leak)? 
I always assumed .map stored verticies

SleepwalkrR: this doc explains Quark ETP: 
On the contrary, the planemerging fixes leaks! At least that's the intent, it's meant to merge two adjacent brushes where some kind of rounding error occurs*. Of course, it can sometimes cause more problems that it solves if it starts affecting brushes further afield. I'd have thought it would affect hull 0 primarily; if there's no leak in hull 0 then the expansion of the brushes for the other hulls should overwhelm any chance plane merging has of creating a leak there.

* Rounding error is a constant worry, even with the best case integer coordinates. Imagine two adjacent brushes formed from a diagonal cut along a single brush. The editor has even been so good as to make sure the touching faces are defined by the same three integer-snapped points. Even so, because the two faces point in opposite directions, the order that these points are listed is reversed. This is enough to produce slightly different floating point plane values some of the time. 
Here are 3 brushes, all the same size and in the exact same space.

"classname" "worldspawn"
"wad" "quake101.wad"
//"0000" "0"
( 128 0 0 ) ( 128 1 0 ) ( 128 0 1 ) COMP1_3 0 0 0 1.0 1.0
( 0 384 0 ) ( 1 384 0 ) ( 0 384 1 ) COMP1_4 0 0 0 1.0 1.0
( 256 0 0 ) ( 256 0 1 ) ( 256 1 0 ) COMP1_5 0 0 0 1.0 1.0
( 0 128 0 ) ( 0 128 1 ) ( 1 128 0 ) COMP1_6 0 0 0 1.0 1.0
( 0 0 128 ) ( 0 1 128 ) ( 1 0 128 ) AFLOOR1_8 0 0 0 1.0 1.0
( 0 0 64 ) ( 1 0 64 ) ( 0 1 64 ) CEILING1_3 0 0 0 1.0 1.0
//"0000" "0"
( 128 256 128 ) ( 128 128 128 ) ( 128 128 96 ) COMP1_3 0 0 0 1.0 1.0
( 256 384 128 ) ( 128 384 128 ) ( 128 384 96 ) COMP1_4 0 0 0 1.0 1.0
( 256 128 128 ) ( 256 256 128 ) ( 256 256 96 ) COMP1_5 0 0 0 1.0 1.0
( 128 128 128 ) ( 256 128 128 ) ( 256 128 96 ) COMP1_6 0 0 0 1.0 1.0
( 128 128 128 ) ( 128 256 128 ) ( 256 256 128 ) AFLOOR1_3 0 0 0 1.0 1.0
( 256 256 64 ) ( 128 256 64 ) ( 128 128 64 ) CEILING5 0 0 0 1.0 1.0
//"0000" "0"
( 128 160 128 ) ( 128 128 128 ) ( 128 128 64 ) COMP1_3 0 0 0 1.0 1.0
( 272 384 128 ) ( 144 384 128 ) ( 144 384 64 ) COMP1_4 0 0 0 1.0 1.0
( 256 128 128 ) ( 256 160 128 ) ( 256 160 64 ) COMP1_5 0 0 0 1.0 1.0
( 128 128 128 ) ( 256 128 128 ) ( 256 128 64 ) COMP1_6 0 0 0 1.0 1.0
( 128 128 128 ) ( 128 160 128 ) ( 256 160 128 ) AFLOOR3_1 0 0 0 1.0 1.0
( 256 160 64 ) ( 128 160 64 ) ( 128 128 64 ) CEILING4 0 0 0 1.0 1.0
"angle" "270"
"classname" "info_player_start"
"origin" "192 256 192"

My point, eh I don't got one yet. 
is there a sound-emitting texture manifested in Rubicon2s progs.dat?

I�ve got an annoying watersplashsound all over my map, and i�m using the animated waterfall texture.

This drives me mad, maybe fullvis gets rid of this? 
Try These 
On your vis command line:

Disable ambient sound generation for textures with names begin-
ning with 'SKY'.

Disable ambient sound generation for textures with names begin-
ning with '*WATER' or '*04WATER'.

Disable ambient sound generation for textures with names begin-
ning with '*SLIME'.

Disable ambient sound generation for textures with names begin-
ning with '*LAVA'.

Disable all ambient sound generation.
But I Want Certain Water Sounds.. 
Or do i have to set up triggers for them instead then? 
There's An Ambient Drip Sound 
that is quite nice. I'm sure some mods have support for external sounds, maybe quoth? 
Those only affect sounds added automatically by the vis process, produced by textures.

All your ambient_whatever entities will still work fine.

We already have several custom sound ents; this is for the RRP project.

You can use the ambient_general for a looping ambient sound, the only restriction being that it needs to have 'loop' data setup.

the fx_sound is for single shot sounds, although it also has replay capability. 
Thanks Ijed! 
there shouldn't be any automatically generated sound from the waterfall. Aside from the vis.exe-generated ambient sounds, there are of course mapper-placed ambients.

The only special rubicon2 code in this regard is, there is an underwater loop that plays whenever the player is underwater. If you are not underwater you should not hear it. (There is also a loop for when you are on fire.) 
I got it fixed with the -noambient switches, ambient_general "survives" this. Still curious where it came from then.
It was one of the curnt.wavs, i�m sure.
Another Question 
can those ambient_generals be triggered?
Starting off? 
i believe they can't be triggered, they are implemented the same way as other ambient_* entities which means they spawn a static sound that gets sent to the client on connection.

With quakec changes it might be possible? I haven't looked at the code in several years. 
oh but... there are some technical issues with triggering looping sounds. The engine won't play the sound if the player is outside the range of the sound at the moment that it is activated. If this happens, the player will NEVER hear the sound until it is retriggered, and then the same range check applies. This is a huge problem and if you look at my steam traps, there is a lot of hacking to make the sound trigger continuously right around the outer threshold of the sound. At that time its' quiet enough that you won't hear it clipping/popping, and it mostly guarantees you will hear the sound when you walk closer. 
The engine is doing the range-check, so any triggered sound is muted for the player when he�s out of "reach"?

Basically the mapper would have to make sure that the player is "reached" by the sound when activated, if i get it right?

Having looked at the setup you made in rub2m2,
that�s a workaround yeah, and btw those maps are fantastic (i mean not only playin them, but looking at them in an editor). Those hollow torus brushwork amazes me with its flawlessness:)

Enough praise given!

Thanks for your quick response! 
correct, player needs to be in range for the sound to play.

Oh and also: the sound won't restart if you save and load the game. There was another hack i had to do to restart sounds condtionally, when a savegame is loaded. 
Phone Out Of Battery! 
True, _ambient code can't do much in this respect, but the fx_sound is a bit more flexible.

You can set it to play a sound every x seconds, so if you set it to play an ambient sound, that isn't looped (but sounds as if it is) then you can kill the entity and the sound will stop playing. Same works for starting the sound.

Fx_ will start replaying after a reload! but only if you've got your triggers very carefully set up. I always thought the trigger_always of q2 was a clever hack. 
Sound Manager 
this was the solution i came up with for looping sounds that are started out of ear-shot:

maybe it'll be useful to someone. 
That'd be truly looping, clever stuff.

The fx_sound will have a few seconds of silence from some save game reloads! depending on how long your sound file is. 
Thanks Metlslime And Necros! 
General Question... 
I'd like to know which version of Radiant works best for Quake. Also links to the better tutorials on using it may help. I tried using it several years ago and I found it difficult to even get basic stuff done so I haven't looked at it since. 
What About 
NetRadiant, imo. Or, if you want to use detached editing windows, the latest build of GtkRadiant 1.5 (=26 April 2007). Some people prefer 1.4 or earlier versions. 
Update Bsp From Wad 
Is there a way to update the textures in a bsp from a wad? 
Not without recompiling. 
QuArK Can Actually Do That... 
but it's a bit of a pain, and one texture at a time.

-Open the bsp, open the MipTex folder.
-Right click and Cut the texture you want to replace. Remember its position in the list.
-Open the texture browser (Toolboxes, Texture Browser.) You can import wads here under Edit, Import, Import (Copy) Files.
-Select the replacement texture, choose Copy from the Edit menu.
-Then select the MipTex folder in your bsp, choose "Paste Special..." from the edit menu, select "Quake 1 Texture" and click paste.
-Drag the new texture into the same position in the list as the old one.
-File, Save. 
I want to use trigger_hurt to increase the health monster (dbg = -1000), but it does not work for zombie. Why? 
the zombie's pain function (zombie_pain) always resets it's health to 60 when it's damaged (unless of course that's fatal damage).

you could do the armor hack if you want it to be tougher, add the keys "armortype" "1" and "armorvalue" "60", and it'll have 60 extra health... it won't regen that health though. 
and negative damage is still treated as 'taking damage' as far as the code is concerned, which is why it uses it's pain function 
Extra Health 
those are interesting to note!

I think as the game progresses a lot of encounters are made easier due to the extra power of the weapons you have. Would be fun to be put into a room with a bullet sponge enemy to create extra panic. 
Be Easy With The Extra Health 
it can be difficult to sell to the player why monsters are more beefy than normal, and that doesn't always make enemies more difficult, pain animations will still play and lock the enemy from retaliating... so they just take more ammo than usual.

I think it's best done on single enemies with something like "effects" "3" (i think 3 is the golden particles?) that gives a visual cue that the enemy is special 
Effects 8 
is just a nice light effect.

The effect 3 seems kind of broken. 
Is a combination of 1 + 2.

And I don't think 1 exists? 
The values are 1 (particles), 4 (artifact glow), 8 (muzzleflash glow) 
Not Sure 
If this belongs here, but is there a way for me to force an entity to be fullbright without using fullbright textures?

Specifically I want to use it on windows, but using water textures won't work because they have a specific pattern I want to maintain. 
What sort of entity? If it can be modelled with brushes, then an external bsp model will do it. 
i think so??
basically setOrigin() the entity to an area where it is bright, then manually change .origin to the new place.
I've never tried it though. 
Aha, External Bsp 
It's a func_breakable, or to be precise, various of them. The external bsp should do it,since resting the origin sounds like it'd be fiddly across this many entities.

I forgot about external BSPs, those should do the trick well enough. I suspect there'll be a problem with collision though. At least there was with expanding door triggers when I tried instancing their BSPs a while back.

Thanks guys. 
actually no! external bsps can have perfectly working collision; several of the sarcophagi in ne_ruins were external bsps. 
Like I say, it was only the trigger bbox of the door with a weird offset, the door itself was fine. 
From Tyrann Tools Light Docs 
The following keys can be used on any entity with a brush model:
"_minlight" "n"

Set the minimum light level for any surface of the brush model. Default 0. 
Tyrann Wins 
Thanks mech, that looks to be an even easier solution. 
Want to know what is the bsp2 standard now? I've read about two versions out. Any place to get the specs. map limits and such? What compilers, engines and editors. The info seems scattered around. A web page with current info would go a long way towards moving things forward. 
Of course the differences between BSP2 and 2PSB are rather tiny so you can still use them as a guideline.

Why is 2psb deprecated when there is very little difference between it and bsp2? Doesn't make sense to me. 
Because BSP2 > 2PSB and supporting 2PSB makes compiler and engine programmers cry in their sleep. 
Because BSP2 > 2PSB and supporting 2PSB makes compiler and engine programmers cry in their sleep.

Is that just your opinion or do you know that for a fact? Have you asked the people who create engines and compilers if they get 2PSB nightmares? :) 
Why support 2 standards that are similar if one will do the job? It's unnecessary overhead and code maintenance. 
Casting Shadows With An Invisible Brush? 
Can this be done? I want to cast a Q symbol but I don't want the brush to be seen. 
Put The Light And The Brushes In The Sky Brush 
Alternate Method 
With that new compiler that lets you cast shadows from brush entities, you can give the brushes the classname "info_null" and set "_shadow" "1". Does waste a model precache though... 
You could potentially use a bunch of negative lights too, but that would likely look like ass and be a pain to do. 
Wild Idea 
I always thought it would be cool if someone made an engine where you could go round the map and "spraypaint" the lightmaps. Basically just go round with a dynamic light that never went away. Then you could add a negative "brush" that subtracted rather than added light, and you could use it to fix up glitches or do weird effects. It'd probably be hard to make it robust in the face of recompiling the map, perhaps you could replay a demo to repeat any painting you performed. Anyway, that's my mad thought for the day... 
That Was My Idea! 
Licensing Issues? 
Um...hesitant to ask, but...

Is there any sort of maybe legal issue with using something from the mission packs? I know Quoth used the Scourge(the scorpion to you heathens who don't know) from hipnotic's pak (hipnothetically, of course), but is this legal? And to what extend? If someone hosts the entire mission pack in the zip along with a custom map so that someone can play it, is it illegal?

Methinks melord thou art a theif. Y/N 
Don't host the entire mission pack; it's copyrighted (and actively being sold on steam) - that would be illegal.

Including a few assets from the mission packs in a Quake mod is probably fine, but the copyright on those assets (models, textures, whatever) is still held by whoever owns the rights to the mission packs. So you're working under the assumption that they are OK with what you're doing, which they probably are. 
Without Licence 
I'd agree that including the scorpion in a mod like Quoth without permission is strictly speaking illegal. It's the same for maps that use texture sets from other games like Quake 3 or Daikatana, taking an art resource and re-purposing it in a similar setting, essentially is a act of redistribution without permission.

Morally speaking, I'd say what differentiates it from including the entire pak and all the maps is a matter of substitution. Including all the maps would make your mod a complete substitute for the mission pack. Someone who downloaded that would have no reason to buy the mission pack, harming that product's potential sales. Including the monster in a different mod doesn't do that; the value of Scourge of Armagon is preserved.

I guess it's kind of a map-centric view of things, but I think the experience of the mission pack is "play through these particular maps", rather than "play against this monster in some notional maps which may or may not include the maps supplied". If a cease-and-desist order were made, we'd comply without hesitation, but for a free mod I doubt we'll ever see one. 
you can just say it's a parody and get off scott free... that's how I got away with all those murder rapes. 
Okay Then. 
The Mapper's Ethic for Other Mod Inclusion:
I won't include the maps.
I won't include the demos.

I will include the monsters I want.
I will include the items I want.
I will include the code I want.
I will hide them in the .pak file(s).
I will include a "Special Thanks" in my readme.txt, whatever it may be called.

I might consider notifying the author before releasing my map...
...if I can find their contact info.

I won't release if the author doesn't want me to, but they will have to act fast.

I will revoke a release if the author of content I have used wishes me to do so.

Signature___________ Date________

Here's a pen ./

Side question: Didn't the Drake Mod use the Quoth Drole? 
% _ | Cte C ^, V+ 
A. The castle will rise from its vortal depths... 
it doesn't need to be so complicated. ask before using stuff, if they say no, don't use it. if you can't contact them and you've done due diligence, just use it-- it's likely a really old asset anyway. 
@Fifth Elephant Re: Shadows 
Aside from hiding the brushes casting the shadow inside a sky brush or behind a func_wall there is another way but you need to be sure that the brushes involved are well out of the way of game play because even though you cannot see them the engine WILL treat them as a solid (invisible) brush so you and the monsters cannot walk or shoot through them.

You will need a BSP compiler that supports the skip texture and detail brushes (Tyranns does using the entity name, func_detail).

Make whatever shape that you want to cast a shadow and make them all func_detail (you can group them and then do it all at once) making sure that you use ONLY the skip texture. Viola, an invisible brush that casts a shadow. A solid (as far as light is concerned anyway) clip brush so to speak.

An additional benefit of this is because the compiler changes the func_detail into a plain old everyday brush it has no effect on the number of entities\models used in-game.

This works for two reasons. All detail brushes are rendered so that vis compiler will ignore them but the light compiler will see them as a solid brush. By adding the skip texture the bsp compiler will not let them get drawn in game. If you simply did a skip on a solid brush it wouldn't cast a shadow but this trick, where an entity (func_detail) is turned into a solid in the middle of the compile process does work so that the light compiler "Sees" the brushes even though the player does not.

But like I said, it's an invisible solid brush so you need to be absolutely sure that's it's out of the way (rocket launchers and Skraggs are an obvious no-no here and probably tar babies and fiends as well, oh, and no way for any enemy to shoot at you or jump on you from above). It also cannot be touching "Anything" aside from itself (in other words it must be free floating, it can be a collection of any number of func_detail + skip brushes touching each other but that's it) otherwise the contact points will give you a HOM effect.

Have fun! 
Cheers For The Tips 
I went for the age old method of hiding the brushes inside the sky volume though I enjoyed all the different methods suggested.

I'm not 100% sure about using the Q symbol in the way I have in the end, the area I used it in seems a bit busy now. 
Tyrann's tools
_shadow 1 with skip texture shove it anywhere 
Adds to your entity count. Func_detail does not because it gets converted into a regular brush during the compile process. 
That's why I suggested using an info_null, which will get removed. Both ways still add a model precache though. 
Is there a limit to the number of precaches? 
I Mean 
What's the limit for engines nowadays? 
Depends On Which Engine 
Personally I prefer the "fuck the limits" option and go for full bsp2 support. Quakespasm is my current favorite for this. Afaik it has no limitation on precaches. 
Hardest Limit 
255 is the maximum that will work in all engines. Lots of leading engines do increase this limit, but because it requires a protocol change it's not trivial to do. This means lots of minor source ports don't have the feature. 
Sock Textures 
Hey guys,

New to this. I want to use the textures Sock used in his maps. His readme's state that these are modifications of the original textures. Is there such a thing as a Sock wad I can use?

Or do I have to go through all the bsp's, find the directories, filter the textures and somehow create my own wad?

Sorry if asked before. Did a bit of Googling but most things mentioned tools on how to make wads.


Sock Includes 
the textures in his .pak files, you could get something like pak explorer to get the .wad files.
I believe you can also take textures directly from .bsp files using TexMex. 
Mememe Textures 
At the bottom of THIS page is all the links you will need. TexMex will extract textures from BSP files and ADQ will open up PAK files. I do include all source materials with every release, map + wad file.

Once you have extracted all the wad files out of all the different pak files, just put them in the same directory as your map and add them to the wad line on your worldspawn.

Eg - "wad" "common.wad;animated.wad;liquid.wad;zendar.wad" 
Thank you! 
Precache Limits 
Since I am already taking the ijed approach with respect to map size, I will ijed my precaches too.

Thanks for the tip.

P.S. 255!! Thats pathetic!! 
whether all engines support "alpha" property for the entity? 
99% of them do (100%?) 
Trenchbroom + Compilers 
I decided to give Trenchbroom a try. It works great. However, I'm wondering if my directory setup is correct because there are so many programs out there.

In my regular Quake folder I got a 'Id1' folder. In there I made a 'textures' folder containing several wads. I also got a 'maps' folder. I added a 'utils' folder as well but when using 'ne_q1spCompilingGui' it needs all my compilers in one folder. So I also made a 'compilers' folder.

The whole compiling story is not clear to me. I've downloaded TYRUTILS and the files by Bengt Jardrup. I'm not sure what the difference is. Also, all compilers come with several files but it seems you only need the .exe's in order for it to work?

Bengt Jardrup also has convmap.exe. Is this the aquirre converter I see mentioned several times? I have to learn Trenchbroom better so I want to make the more complex brushwork in GtkRadiant 1.4 and convert that to Quake. According to the explanation I read I need to make an 'output' and 'workingfolder' directories inside the 'Id1' directory. This doesn't seem to work so I probably misunderstood that.

Any insight into the correct setup would be great. I read the Quake Wiki and I've found useful information using Google as well, but never the complete picture so that's explains the questions above. 
You really only need a the vis, light and bsp .exe files. The other files are probably readmes and source files (for budding programmers).

I just store everything in my trenchbroom folder for mapping, texture wads, compilers and .map files. When you create the .bsp file all your textures are compiled into it so these aren't required to go into your quake directory. (plus it makes your quake directory cleaner).
As for Trenchbroom, I store it inside my drop box folder so that my work is always always always backed up. 
Re: Ne_q1compilinggui 
the output folder is the one where you are putting your maps to run.

so if you are making a normal map, the output folder should be /quake/id1/maps

the working folder can be anywhere. this is where the .map file is copied from it's original spot, and then compiled (the compilation process creates a bunch of files that are mainly needed only during compile time).
after the compile is done, the .bsp produced is put in the output folder. 
Extras_r4 Mod 
I was mapping with the extras mod with the func_water lifting.
Now I'm breaking up with the thing called z-buffering.
It means that func_water brush expands out of it size.
So a space left out still gets troubled with the greyness of the func_water.

Is there a solution to this
only way is to make two separate water brushes. 
They Are.., 
the left one is rectangle, the front one square.
It is the outgreying part where no brush is. 
try using my newskip tool, it has a *waterskip texture you can add to the sides of the water brushes. 
To Be Clear... 
first, do what necros said. Then, use *waterskip on the internal faces of the water brushes. So when inside the square, you can see into the rectangle. 
The volumes will be correct (but can only be rectangles, like triggers) but internal faces you have to cull by hand.

So, uh, what Metl and Necros said... 
To my astonishment breaking both func_water funcions in two separate ones clears out the greying.

Another thing I learned is that a very thin brush above the big one conceals the visible watersurface.

Just trying to change e1m3 with a changeable water level, but the z-buffering wrecked the view in other places.

Skipping tool can work as the sides of the brushes are still breaking up. 
FifthElephant + Necros 
Thanks guys! So it doesn't matter whether I use Tyrutils or Bengt Jardrup his stuff? It just basically a matter of preference?

Convmap from Bengt Jardrup is actually Aguirre's convmap tool? 
Convmap from Bengt Jardrup is actually Aguirre's convmap tool?

I guess you could say that. 
What Mr Useless is not saying is that aguirRe is Bengt Jardrup's nickname. I would recommend using Tyrann's tools as they are actively developed, fast and have great features. Check out 
Which compiler you use depends on what features the compiler has. I tend to use Tyr's BSP most of the time and I revert to Bengt's Treeqbsp tool when my geometry microleaks (it rounds vertices to less decimal places, plus I can never get the portal file to work with Tyr's utility). 
Tyrann's Tools 
Have detail brushes and a load of other handy features.

Detail brushes make your vis time reasonable - recently I heard a case of a map taking half a day reduced to >2 hours by application of detail brushes. 
Thanks guys! 
Starting The Player With The Axe 
I would like to have the player start with no shells and the axe selected.

My attempt: I thought the easiest way of doing this was to have console run the command "give shells," but I could not get that command to execute from a .cfg file.

Is there a way to complete this task without compiling with QuakeC? 
You Can Do It With A Hack 
Make an 'info_notnull' entity underneath the player start.

Add the following keys and values:

"think" "PlaceItem"
"nextthink" "0.2"
"touch" "BackpackTouch"
"ammo_shells" "-25"

This basically makes an invisible backpack item, like monsters or deathmatch opponents would drop, and contains -25 shells. 
You don't need to do all that if the player is sure to have only the shotgun and axe and 25 ammo. 
Rekt Once Again 
I was able to implement this within 5 minutes of the post.

Is there a way to suppress the pickup sound? 
if the info_notnull is right on top of the player such that they pick it up as soon as the map starts, does the sound still play? 
Yes Sir 
If There Is A Man, Stood In A Forest Miles Away From Anywhere 
and no-one can hear him. Is he still wrong? 
Crushing Platforms 
I keep getting crushed by my func_plats when going up, even though they're damage 0 and have nothing out of the ordinary applied. They seem to be touching me more than once per frame and doing 1 point of damage, stripping off my armour before hurting me.

Is this an engine issue? Framerate?

It isn't happening with func_doors but in some cases I need platforms. 
it is a bug with the collision detection of the engine.
i forget exactly what it was, but it had to do with bounding boxes.

if you are inside the bounding box of a mover, this can happen. the solution (i think?) was to make it so you were standing on the top of the bounding box of the mover pushing you up... 
Ok, thanks. 
It seems its an accuracy issue - my platforms were just too thin. 
Subtractive Mapping? 
Preface: I understand that this is in no means practical.

Has anybody ever tried starting with a large solid and carving the map from that? A subtractive rather than additive process? 
i tried it for my first failed map in 1996. after 5 rooms the qbsp process started taking many minutes. Probably the tools aren't designed for it. (of course, the issues isn't qbsp, it's the editor that has to chop up the brushes into normal additive brushes that get sent to the compiler.) And really, most people here will tell you not even to carve a single hole in a wall in an otherwise additive map, since most editors carving tools are so bad. 
unreal worked like that. 
Unreal did work this way. The tools for quake aren't really designed for it. 
Unreal got away with it because it was designed to support subtractions right from the start. Quake was not. 
Descent Mapping Was Kind Of Like That 
you didn't really subtract but you could only create playable areas, not walls. 
Serious Engine 
Is also subtractive. Too bad really, I've noticed that engines that use that method didn't get a lot of 3rd party mods or levels like additive ones did\do. The subtractive method is an inherently non-intuitive way to make content which made a lot of people shy away from games that used it IMO. That the first major games that were modded by a lot of people (Doom and Quake specifically) used additive geometry probably didn't help in getting people to switch over. 
I found Unreal editing much easier actually. No need to seal, just map away. 
Subtractive FTW 
I really prefer subtractive mapping, I find it a huge timesaver. Consider the following scenario:

have 2 cube rooms with a single straight corridor connecting them.
Minimum amount of brushes for additive: 22
Minimum amount of brushes for subtractive: 3

Of course, there's no reason you cannot just carve out a big box and map additively inside it, just like you do with Quake style map editors. The only difference is you don't need to bother with sealing your map. 
maybe because i'm used to it (17 yrs. experience!), additive building doesn't bother me. But it seems like, when dealing with very detailed architecture and not cube rooms like in the example above, the advantages of subtractive are reduced. Instead of 22 brusehs vs. 3 brushes, it's more like 1022 brushes vs. 1003 brushes.

If you are additive building all the details in a room, and you produce what would have been a leak in an additive map, instead what you will get is a contained, unfilled void with a bunch of unneeded faces, between the back of the additive brushes and the edge of that room. So it's better but, better still is to fix the leak.

Or map with a modern engine where details are provided by meshes and polygons don't count as much as draw calls. Then quake's building technique is pretty obsolete. :) 
Well, I think it's a moot argument. 'Subtractive' maps in UDK were really just additive maps, except with a huge brush covering the entire world to begin with, which meant you wouldn't do that if streaming the maps together. So in making a map, you really just have both methods, and they work fine together. You just add brushes as you do in Quake, and can do subtraction because it's handled gracefully without excessive polygons being generated. Any you aren't limited to convex brushes. It would honestly be great if something like that could be handled in Quake, but I realize that would be a huge change to how maps are even handled in Quake to be done right. 
then there's the quake3 method where you build a caulk hull and then fill it will detail brushes. I guess that is closer to the unreal method? I remember that being a lot of work, though, tagging the back of every detail brush with nodraw shaders... a lot of tedious work. You're basically making one brush per poly at a certain point, or using flat 3x3 patches to mimic quads... i don't miss that. 
Edge extrusion looks like a nice method, then merge vertices with the same location. 
box modelling workflows are pretty good for mapping. 
Subtractive Mapping 
for me meant working inside this sold block and generally meant carving out a lot of very boring shapes. There are some things in Unreal ED I would love to see for trenchbroom (2d shape builder yes please!!) but I find working with an open space is more creatively freeing than trying to carve out something interesting.
I made a lot of UT maps back in the day and it felt restrictive. 
that probuilder app looks awesome. 
10 Years Later ...

Does any of you know where to get the tutorials that are mentioned in here? At most i can only find the one by Metlslime, after checking Quaddicted webarchive and other places

It would be nice too if we could revive that thread or make another similar ... 
"Infinite" Map Approach 
How would you approach a huge, huge map, something like all original levels combined into one?

Is it possible? Does Q3BSP or BSP2 offer this? 
All original maps in 1 wouldn't actually be that big. 
There Is ... 
... episode 1 maps joined together into a single map in normal bsp format, with the version of e1m6 that wasn't used too in there. If you use teleporters, i think it would be posssible to put the four together.

Ne_qep1 is its name, from the mod ne_dynamic, made by necros. 
Hi, i am experimenting with some hollow pipe bw,
and when it comes to light the scene, i get this:

Tyrlight 0.14 with -soft 1 extra 4 set.
minlight value 10.

and thats one light only in this shot, value 300, delay 2.

Moving it around, and adding more light doesn�t change this significantly. Any clues anyone? 
can you take another screenshot with r_showtris 2? the face topology looks messed up. 
indeed, the faces are split in an unusual manner.

Though its on grid. TB screenshot: 
i forgot to mention, i used an experimental build of txqbsp_xt, which has HL facesplitting algorithm implemented (and is incredibly fast).
Switching back to older version fixed it:) 
those faces are split ok. this is actually the way it usually ends up looking with any qbsp compiler. 
Problem Wasnt One 
Except you don�t count my dumbness as one.

Those lighting oddities were caused by a abandoned .lit file with same filename.

Took me ages to figure that out(well, actually it was rebb who had that guess). Sorry for the disturbance, i go now standing in the corner for a while.

Auto Flagellation Is Demanded! 
I Already Feel The Pain, Ok? 
Heh, I did this myself a couple of days ago, but caught it quick. Drag and drop from the build to project folder. 
sometimes it the simple things.
Man, i really got rebb to sweat on this, i can tell you!

Sorry rebb! 
Optimizing Quake Maps 
Hi, can anyone point me in the direction of some literature that covers proper brushwork and bsp optimization?

In other words, I'm looking for ways to get the most (most being brushes, models, etc) out of bsp1.

I think max verts is around 65k, not sure about models and other things.

I'm thinking about converting a majority of the complex geometry into static meshes giving me more room for brushes. Is this a bad idea? What are the drawbacks?

Also, is there any way control how faces are split?

As I said, I just want to find the best way to maximize every little bit of space in bsp1, completely fill it to the brim in the most efficient, optimized way possible.

Any input would be greatly appreciated.

I'm thinking about converting a majority of the complex geometry into static meshes giving me more room for brushes. Is this a bad idea? What are the drawbacks?
Sort of a bad idea. Static meshes in quake don't really blend in with the rest of the level the way they do in modern (or even semi modern) games. They also don't have any collision.
You can use .bsp files as models though. This is a better solution as you get proper collision and it will blend in with the map but the lighting will not match unless you light the bsp model in a way that matches the area in the map in which you're placing it. Also you can't rotate them without breaking collision (eg: if you rotate a bsp model, you loose collision)

Also, is there any way control how faces are split?
Ah, thanks necros, I was afraid that's how static meshes would behave.

I'm trying to avoid going bsp2 simply because I want maximum compatibility with the variety of ports that are currently used...

...however, having 120k+ verts in a single map would be pretty sweet...

After running around with r_wireframe 1 I noticed some faces are split in undesirable ways. I'm pretty sure many brushes could be reshaped in such a way that I get better splits... 
Things To Try 
Merge textures on large faces; upscale the textures on bigger surfaces that are out of sight; separate intersecting geometry (ever so slightly) and/or turn things into brush models - both situation-dependent, may help or actually be counterproductive; use hacks to clone often-used detail brush entities; try -forcegoodtree with rebb's txqbsp mod; don't get carried away when making a map. 
also: faces larger than 240x240 will be split every 240 texels, on both axises. So a 256x256 face will be split into 4 faces. Keep that in mind, and add detail in places where the extra face is already going to exist. For example a 240-tall wall brush with a 16-tall trim brush above it will have the same number of faces as a 256-tall brush, but you can put a different texture on the trim and therefore get more detail for no additional faces. 
external bsps can help a lot depending on what kind of map you have.

check out my ne_ruins map for some examples of using external bsps.
upper area is external bsp, trim is func_wall
again, trim is func_wall and coffins are external bsp

Note that external bsps will not light up with guns and explosions but then no one (to my knowledge?) complained about the coffins not lighting up, so i reckon as long as you are careful where you do it, it's fine. 
is there a working link to the src?
Please, please! 
mfx, any model spawning entity will work for this, just put thing.bsp instead of thing.mdl 
but its not just this, ijed.
I always wanted to know how the ending sequence works in particular, the slow camera ride and that fog and the awesomeness in general. 
Fair Enough 
no, the code isn't included (just the .map file)
here's the camera code and the associated portal trigger scripted entity: (no warranty) 
Yeah, Thanks Necros. 
really appreciate that! 
Quake Wiki 
needs so much love. I needed to know a bit of info for some lights (needed the slow pulse style)...

There isn't even a page for the light entity! I really haven't got the first clue about wiki page editing though otherwise I might spend a bit of time on it. 
Re: -forcegoodtreehug 
Very situational when it comes to marksurface improvement, depending on the map it may even increase marksurfs / cause leaks. Use when feeling adventurous or desperate ;) 
Great advice so far. I'd like to read more about what determines how faces are split so I can make more informed decisions instead of just throwing brushes around.

@necros, I did not know you could use external bsps in that way. I can think of like five instances off the top of my head that I can go back and do that way. Other than not being affected by light from the map or weapons, explosions, etc. are there any drawbacks?

Every link to mapping tuts on quakewiki are dead :\ 
they draw slower. I once tried to make a huge purely decorative terrain section into an external bsp. Looked fine, collided fine, got about 10 fps though.

but that was a very extreme case.

if you're just replacing out of the way geometry that is just for looks (like the tops of distant towers or something), then external bsps are the way to go.

they just take more work to set up. you need to be a little careful with your lighting so that it matches up.

a final draw back: skip textures won't be removed when the bsp is loaded as a model.

however, faces removed as part of the qbsp filling process are still removed as a bsp model.
AND faces which are not facing the player don't cause collision.

so you can make concave models whose outside faces are culled:
this is the external model, has a lot of useless faces removed due to bsp culling
as a model, all the skip faces are visible, sadly.
but from the bottom (where the skip face is facing away from the camera) we can't see it, so it looks fine! 
they draw slower. I once tried to make a huge purely decorative terrain section into an external bsp. Looked fine, collided fine, got about 10 fps though.

True, the code for drawing brushmodel faces is different than for drawing the world, it might be less optimized and worse if drawing thousands of polys.
as a model, all the skip faces are visible, sadly.

Yes, i never did add proper support to newskip.exe for creating external bsp mapmodels. :( 
Func Walls 
What's the best approach?

All I need is a collection of brushes to appear once triggered, they don't need to do anything.

I think in Q2 it was a behaviour of func_wall; if given a targetname then they would start 'off' and wait to be triggered.

Glancing at the QC, the use function is this, basically;

// change to alternate textures
self.frame = 1 - self.frame;

Not sure what that does... although it makes sense that it would change to different animated +textures. Might have to try that out with some signposting monitors.

Anyway, my though on spawning func walls was to add a spawnflag START_OFF which decouples the startup functions from the creation of the entity if set (and will disable the skin changing).

Is this the optimal method? I assume any entities inside it when its created will become stuck, and if the player can see the thing pop into existence it'll look pretty goofy, but aside from those drawbacks it should work, along with proper collision. 
it makes sense that it would change to different animated +textures

That is exactly what it does, it works just like func_button where +<number> swaps to +<alpha>.

As for your question... perhaps just a really fast func_door with start_open and toggle? 
"classname" "info_notnull"
"use" "func_wall"
"targetname" "t1"
But the hackery options are going to be pretty high maintenance for what I'm planning. Basically I want to reconstruct large parts of a level once the player reaches a certain point.

Doors I've used before and they work ok, but do have the downside of crushing and moving stuff around.

Writing the entity type into the mapfile / entity entry in editor would work, but if I have, say, 20+ of these and need to modify them then it'll turn into a headache pretty quickly.

From the rambling post before really I'm asking if there are any problems turning on lumps of brushwork during run time. Apparently not.

Only time will tell :) 
ijed: if you are using standard progs (or progs that hasn't modified SUB_CalcMove), then as long as the speed setting on the door is high enough that the move would be completed in less than 0.1 seconds, the progs just does a setOrigin() call instead of normal physics movement, so Scampie's suggestion would work fine.

see if (traveltime < 0.1):
void(vector tdest, float tspeed, void() func) SUB_CalcMove =
local vector vdestdelta;
local float len, traveltime;

if (!tspeed)
objerror("No speed is defined!");

self.think1 = func;
self.finaldest = tdest;
self.think = SUB_CalcMoveDone;

if (tdest == self.origin)
self.velocity = '0 0 0';
self.nextthink = self.ltime + 0.1;

// set destdelta to the vector needed to move
vdestdelta = tdest - self.origin;

// calculate length of vector
len = vlen (vdestdelta);

// divide by speed to get time to reach dest
traveltime = len / tspeed;

if (traveltime < 0.1)
self.velocity = '0 0 0';
self.nextthink = self.ltime + 0.1;

// set nextthink to trigger a think when dest is reached
self.nextthink = self.ltime + traveltime;

// scale the destdelta vector by the time spent traveling to get velocity
self.velocity = vdestdelta * (1/traveltime); // qcc won't take vec/float

void() SUB_CalcMoveDone =
setorigin(self, self.finaldest);
self.velocity = '0 0 0';
self.nextthink = -1;
if (self.think1)

I'm not quite sure I understand func_detail. Does it just turn the brush into an entity? Is this something that's fairly safe/advantageous to use? Any tips or knowledge on the application of func_detail?

I realized making floor grates/grids from regular brushes is really expensive. Each "hole" is just as pricy as a cube, minus two faces. I went in and removed some from a small room and got about 5k verts back. The effect was cool, especially the way it cast light, but too expensive.

Now that I'm pressed for space I'm going back and seeing how I put high detail in the wrong areas.

From now on, action packed or dark areas will be relatively low detail, while slow, well lit areas will be for the scenic stuff. I know this is a no-brainier but it's also my latest

tangent: is it possible for one to manipulated the way light is cast with an "invisible brush", in other words, is there a brush that only effects light, so no visibility, collision, etc.

On could use low detail invisible brushes to cheaply cast light that looks as if its coming from behind a grate and just use a texture with transparency as the grate. I think. 
Detail brushes (func_detail) are for speeding up the VIS process. They are brush entities in the editor, but a QBSP with detail brush support will turn them into world geometry while not creating vis portals for them.

Attempting to lower verts/marksurfaces etc, one can use func_wall entities instead, for instance. 
Ok, got it. Not what I was hoping it was. 
Making grates would be good to use a texture, but doing it this way means you dont get the nice shadows.

I'm assuming you're making the grate by making individual brushes and not by using a carve tool. If you're using a carve tool I would stop straight away.

The general rule of making geometry for me is to stick to 16 units as the smallest sized brush and *only* go below that on rare occasions. Quake is a big chunky evil looking game, it's rare that you need fine details. 
In even the worse implementation of a carve tool, you're probably fine using it to create on-axis grate holes.

overlapping brushes get merged during bsp anyway.

it's off-axis carving that can lead to microleaks and such. 
Yeah I know the faces get split during the bsp process but it also makes it a bitch to go back and edit the brush later on if you're relying on the carve tool (I once made a level this way and wanted to change a couple of things and realised what an error I have made, it changed my entire philosophy on mapping)...

Though I knew the faces get split up I thought the way which you made the brushes determine how they split? 
but it also makes it a bitch to go back and edit the brush later on if you're relying on the carve tool
definitely. if you're making a grate or something similar, i recommend putting it in a func_group and then doing your carving so that the resulting dozens of brushes are still part of the func_group. you still can't edit them easily, but at least they're all contained.

I thought the way which you made the brushes determine how they split?

Not that I'm aware of? afaik, merging and splitting is all done at once.

for carving, i would say doing things like grates and such is up to you. i'd only recommend staying away from it with things like big world geometry for exactly the reason you mentioned. 
Carve Tool? 
Clip tool is the same thing, or CSG subtract? I'm a nublet, I apologize. Of those, I've only used subtract, and very judiciously for that matter. gets messy. fast. 
Never Apprise 
We all started somewhere.

I'd offer more useful descriptions but I'm a bit hammered. 
carve = subtract 
I thought the way which you made the brushes determine how they split?

As far as i know, no. For example, I have a map where i cloned a brush and its surroundings several times, and almost every clone is split in a different way, in cases some brushes merged and split again in a different way.

#13682 : thanks for the link, Spirit.

So i have to suppose that the tutorial Iika made has been lost forever. 
I meant the link as incentive to add map performance tricks there... 
Interesting, I haven't looked at the door code much. 
Typical Entity Count 
What's the usual entity count for the standard quake maps?

It feels fairly easy to hit the 512 entity limit! 
I hope it's not 512... 
Pretty sure it's 512 entities before you start getting in-game error messages.

(it might even be less because I t hink if you're shooting nails and stuff that adds to the in-game count or something) 
If you're refering to the edicts limits, that's 600. 
That's Weird 
so far I've got 2161 entities and no warnings or errors.

I'm using TxQBSP 1.13 and Light 1.43, release 2, the one modified by MH for colored lights and multithreading. Can't remember which vis. 
As far as i know, lights are count as ents by light.exe, but they don�t add to the edicts. 
lights are not edicts, unless they have a targetname.

KillPixel: don't worry too much, modern engines handle well above 600 edicts. It's just that the standard id engines can't go over 600. 
Are things that do stuff during runtime.

A light without a target name is effectively deleted before runtime, and so not an edict. 
i believe light.exe actually delete them if they don't have targetnames? 
Oddity I've Yet To See... 
I use Worldcraft 1.6. Working on a Quake level, I compile to check my latest round of progress. Oddly, the batch file I'm using to run TXQBSP returns 28 warnings.

Checking back with the rmf. file, it claims that I have 28 instances of invalid structures. Which is odd since I've been careful about my vertex manipulation. When I zoom to the problem, it's a shapeless object at the grid's top view origin. It's a solid with one face, larger than the grid itself. 28 of them.

I deleted them all, and progress continued, but I'm wondering if anyone's ever come across this before. And what it may possibly mean... 
probably just a bug with the editor. i've seen that kind of thing is just about every editor i've used at one point or another. 
Lights And Other Entities 
A blog post on when light gets removed and how to remove other things. Save entities, save the planet! 
Ok, can anyone out there spoon feed me some literature on custom entities and how to make gtkradiant see them.

I've asked someone on quakeone to make me a couple and he compiled a new progs.dat for me as well as gave me some cut/paste stuff to put in a radiant file.

I've got several more things I need but don't wanna harass the guy every time I need a new entity.

Currently, what I'm looking for is a way to arm/disarm triggers, silent spawns (that is, remove the "thud" that models make when the teleport in). I'd also like to be able to trigger any sound, i.e type a path to a sound file to be played. That way one could make a pretty dynamic and awesome sound scape.

My QC knowledge is nill at the moment, I know, I know... 
The empty object error is something that occurs in Worldcraft or Hammer.

How to Reproduce:
Create a brush.
Tie it toEntity (eg. make it a func_door)
Create another brush.
Select both brushes.
Tie them toEntity.
Oops, now there's a func_door without a brush.

What is going on:
The editor when it creates an entity from a brush, takes the brush data moves it out from under worldspawn and puts it under an entity like this:
"classname" "worldspawn"

"classname" "worldspawn"

"classname" "func_door"
So what happens when the brush is already within an entity as above, the brush data gets moved/stolen from under the entity it's already in (worldspawn is an entity!), then put under the new entity. Like this:
"classname" "worldspawn"
"classname" "func_door"

"classname" "worldspawn"
"classname" "func_door"
"classname" "func_door"
Notice that there is nothing under the first func_door. And that is why the editor puts in at 0 0 0 and it looks like there is one superbrush covering all of reality. But really, there's nothing.

Best Practice: NEVER create an entity out of brushes that are part of an entity.

Source: I've been a mapper for Quake for over 10yrs. Also, the .MAP file format. 
this happens in gtkradient 1.5 as well, took me a while to figure wtf was going on.

"Best Practice: NEVER create an entity out of brushes that are part of an entity."

now I know... 
This Can Happen In Pretty Much Every Editor 
Best to keep it in mind and check the map for it before release. BJP's Glquake prints a warning if it detects a rogue brush entity, but none of the other ports do. 
Not In TB ;-) 
Someone in here asked for polycount reduction tips or where was it? Just stumbled across when fixing links on 
Also, For Negke

What I'm desperately trying not to suggest is that complete mis-alignment of textures is the way forward. That is underkill. I've almost said aligning of textures to edges isn't important. That's a lie. It is. What is important however is knowing when to do it, when it is worth the time, and when it isn't. 
very helpful/informative links! 
I see where he's coming from, but I feel patronized by the article. There's a point about putting too much focus on "unnecessary" (debatable notion to begin with) detail at the cost of gameplay. Yet, just because the players may not see or appreciate certain details, or because they may not add to the gameplay, it doesn't mean it's bad practice. Besides, the On A Rail chapters doesn't work as a general example for all kinds of games and maps like he seems to be doing. 
It's Pretty Badly Written And Incoherent. 
In a nutshell, the point he's trying to make is that details shouldn't interfere with the overall theming of a level's design.

But he focuses on pointless detail (funny considering that's what he's trying to write about) and doesn't resolve the topics he's bringing up.

Yes ok, On A Rail was bland but it worked. You could say that about most of Half Life. Why not mention that software improvements allow us to have better graphics without sacrificing game play?

Yes ok, LDs shouldn't waste their time sticking doorknobs on things. Why not discuss using prefabs or other tools? 
It's worth noting though that the page was written in 2001. Some angst from back then about aesthetic fiddling getting in the way of playability is understandable (especially from someone working against commercial deadlines). 
I Refuse To Accomodate Empathy 
Damn You 
There is also a follow-up at 
That's better. 
I remember this when it first came out, and it was definitely controversial because it's hard to accept what he says if you believe in cleanly built maps.

The non-controversial part is that an increase in visual detail does not always cause an increase in quality of experience -- an obvious example is high-res replacement textures in quake. The harmony of many different ingredients is more important.

The controversial part is "misaligned textures can be better." I think the best way to re-state this so that I can accept the idea, is to say "impressionism can be better" -- this could be because the "magic" of quake and doom is the low-res, low-poly filter that we see that world through, which gives the player room to imagine the rest. It's hard to do this in high-res, high-poly. At low res, 8-bit lighting, there are so many filters that muddy everything up that you can't always see the texture misalignments, they are hidden by dithering and aliasing and palette banding. These filters help the player experience the whole and not focus on the details, since you can't see the details very well anyway. 
Well Put 
The higher fidelity and realism of the graphics the more visible the flaws, not only technically, but artistically.

Maximum realism is the goal of most modern games, but I don't think we're quite there. IMO, it would better better if designers worked within the boundaries of the tech and made cohesive, artistic interpretations instead of attempting realistic duplication. "pushing the boundaries" is not the safest route, as I feel people push them too far. 
Always On Spikeshooters 
How do you make them constantly fire? 
Use trap_shooter instead. 
Not Everybody Uses Quoth 
Its An Id1 Enity Iirc? 
Just use trap_shooter. For trap_spikeshooter I think you can set its target to a info_notnull. 
I Was Correct 
If memory serves I believe that trap_spikeshooter uses a rotation flag or a up or down firing flag and is dependent on what type of level it is in the worldspawn (lasers in tech levels and spikes for everywhere else).

But I might be wrong on that, it might be possible to put spikes in any level or lasers in any level. I never really played around with them. The timing just seemed a bit too fiddly to get right without a lot of blind tries and recompilings until you got it right. 
Ropes And Chains Models 
Do I remember someone having some rope and/or chain models, and if so, can I pick them up somewhere? 
Honey By CZG 
they were actually .bsp, but does that matter?
Just look into the file at quaddicted.
And Ijed has some chain models, hanging from ceilings, maybe he�s so kind to distribute them? 
are also to be found on the tome of preach, its the cable model with skin set to 0.

Thanks to both 
Plats Vs Doors 
is there some sort of specific reason to use plats instead of doors?

I ask because I have a use for one but the plat is a bit finicky so I'm using a door instead. Is this ok or is there something more to plats that I'm missing? 
You're Right 
Plats are slightly easier to set up in an "inactive, then autonomous" way, but when you need better control then a door is the standard solution. 
thank you 
How The Hell 
do you set the gravity in a map? I want a low grav map in my quake episode.... 
set in worldspawn.
I don�t know the actual default value, maybe 800? 
Only Way To Do It In Id1 
Is to name it e1m8.bsp. 
Scourge Of Armagon 
had a patch for it, I thought.
Maybe in the qc somewhere. 
It may be in the QC as both of the official expansion packs came with a patch to the engine but far more likely that it's in their own custom progs.dat otherwise all of the new features would have been carried over so anyone with a 1.08 Quake engine could take advantage of, lets say particle walkways or rotating objects (or anything else that didn't have a special sound or model attached to it) in Vanilla Quake levels (ie in the ID1\maps folder). 
There's a hack to execute console commands like sv_gravity, but it's messy as it has negative side effects which would have to be worked around.

If you go for a custom progs dat with universal gravity support, be sure to also fix some of the common standard bugs like fish count, death solid frames, and so on. 
Necros Sent Me A Progs.dat 
That fixes it. No idea if it fixes anything else 
Am I using the wrong combination of compilers, or does using func_detail really make it impossible to compile -onlyents? Building BSP with TxQBSP 1.13 XT -onlyents, func_details apparently don't get stripped out they way they do with a normal compile, leading to a corrupt unloadable BSP with extra bmodels in it. 
Sounds Like An Oversight 
func_details are added to the map as if they were entities, it's only because the compiler knows to do something special with them that they get removed in a full compile. It wouldn't be surprising that unaware compilers would leave them in for an onlyents compile, and I expect it's just an oversight that an exception hasn't been added to compilers that do support func_detail.

Two workarounds I can think of:
1. Save your map, then select and delete all the func_details before you do the onlyents compile. This should work just as if the compiler had skipped them, and they should appear in the output map because they were included in the original compile.

2. Use adquedit to extract the entities from your map into a text file, make the tweaks, and export them back.

Neither of these workarounds are things you'd want to do regularly (they'd be useless as a way to save time on a "changed lighting" compile as they take longer than you save by using -onlyents). But if you just need a last minute tweak to a few ents on a fullvis'd map they might be just the ticket. 
Try This Test Build 
I should probably roll this out as official soon. 
And Maybe Host It In A Less Shitty Way 
Regarding The Question 
func_detail don't make it impossible to -onlyents, it was a bug. Afaik TyrUtils handles this properly too. 
I'll give that compiler a shot just to give you feedback but I've been strongly considering just going full Tyrutils (already currently using tyrlite, because, who doesn't?) 
Well, those tools work great. Fixing my fucking batch files also helped. :( 
Those Tools Are Great! 
WTF! Who did this? Is there a documentation anywhere? Or a readme? 
De-activating Trigger_hurt 
in quoth? Can this be done? For example making a forcefield should be a simple case of setting a targetname and adding wait -1 but wait appears to be used for how often the damage ticks.

I am struggling to find the appropriate way to do this. 
give the trigger_hurt a targetname, then setup a trigger_once or trigger_multiple whatever with killtarget set to the trigger_hurt. Can even be set on monsters and only works once, you can�t reactivate it from there i think. 
Cheers Mfx 
Helps a lot! 
Also Ran 
Alternatively, the func_togglewall you're probably using for the physical part of the forcefield can be made to damage players that touch it with the "dmg" key. Saves an entity or two and a bit easier to set up - it's also the best way to do it if the forcefield can ever turn back on, as killtarget will remove the damage irreversibly. 
I can't seem to get togglewall working to be honest. The brush doesnt appear in the game. 
Well 5th 
thats intended. Spawnflag 1 + once triggered makes it appear. You can trigger it near the playerstart, when its out of sight, to make it appear. Everything iirc. 
Map Optimizations 'n Such 
I stumbled across a tutorial using the source engine and Hammer, the topic was optimization. He kept talking about visleafs and func_detail... which started to make me paranoid.

Some time ago I released a small part of a map in its early stages on QuakeOne. Of the complaints, the one that really disturbed me concerned high r_speeds.

I've been going through the map, merging wherever possible, mitering convex corners, making new textures in places where I had originally used several brushes to do the same job, using func_walls where appropriate, etc, etc.

However, my ignorance of the way quake works is allowing my mind to wonder and assume the worst.

When running around with wireframe I see some (sometimes rather large) areas being drawn even though there is absolutely no way it could be visible.

In some ports (DirectQ) some doors/illusionary disappear at certain angles. I'm not sure if this is because I'm doing something wrong, or if it's just quake/DQ. I don't get any errors when compiling.

Here is the lates bsp log (TxQBSP), does anything look odd? Like some number being too big or small in relation to another? This is my only map so I have no point of reference.

Now that I think about it, a vis log probably would have been helpful...

Any insight would be appreciated, I just want to correct anything I'm doing poorly/completely wrong. 
BSP Mysteries 
Logs aren't very helpful in this respect. The best data you've got is r_showtris 1 in engine.

First off, are you doing fullvis? Thats a requirement for properly vis blocking your level. The -fast option should only be used for testing, and to be honest if you're using hint brushes properly then you won't even need the -fast option any more.

I've seen some great tutorials on this down the years, but can't seem to find many good quake specific ones now due to the various websites closing.

Here's a short one which gives you the overview:

But from what you've posted it might be the exact same one.

This is a programmer's guide to the format;

And here's a non-quake visual discussion;

Basically, there's tricks used playing off certain factors of the Quake engine and BSP format.

- vis does not respect vertical height (if its open at any point vertically it's considered completely open)
- switchbacks help, multi-tiered arenas hurt
- Doughnut corridors (a pillar in a corridor that is wider than the entrance / exit of the corridor
- ALL decorative stuff can and should be hint brushes, the bare bones structure being solid brushwork (this includes pillars, free standing or part of the walls)

There's a lot to add to this of course. 
"- vis does not respect vertical height (if its open at any point vertically it's considered completely open)"

Isn't this just a more confusing way of saying "it's using portals"? Meaning, if you can see the portal, then you can see everything that portal can see. 
RE: BSP Mysteries 
Yes, fullvis.

Thanks for the literature.

Quake1 uses hint brushes?

IIRC r_speeds on my system are fine.

Makes me wonder how many people are still using a 386 to play these maps...

I should probably use func_wall more often, 99% of the decorative stuff is made of normal brushes. 
"ALL decorative stuff can and should be hint brushes"

No. Hint brushes are meant for manually influencing the vis portal generation. Their implementation in Quake is experimental at best and there hasn't been conclusive testing, yet.

If you meant detail brushes, then no again. These are mainly for speeding up the VIS process, but do not have optimizing effects on the polycount.

If you meant decorative stuff should be func_wall or the like - this isn't a general solution, either. It's situational and may as well increase the polycount or have other negative side effects. 
That cleared several things up for me.

I don't use func_detail as I'm not sure how it's different than func_wall. AFAIK func_detail is only supported by specific compilers?

Also, I've restrained from making all the decor func_wall because of the polycount. So far, I've used this very sparingly. 
Instead of func_wall, func_detail creates so called tjunctions in your bsp, which prevent the flickering edges. Iirc. 
Ok Then 
Willem, you're assuming someone who's asking for the basics will already know what a portal is.

Sorry, yeah I meant func_detail, and that's why I was talking about the -fast option earlier.

They just allow you to reduce portal creation, but that's no help to poly count.

func_detail has the advantage over func_wall in that it can cast shadows. Additionally, most engines still have the flickering entity bug - if a func_wall crosses two vis leafs or more it will go invisible when viewed from a leaf the engine considers it shouldn't be visible from.

Basically, it assumes that brush models will always be of a comparable size to a point entity.

Additionally, func_walls are not made static, so will consume resources during runtime, while func_detail is not treated as an entity by the engine at all. 
The difference is func_wall is a (dynamic) brush entity while func_detail is only relevant to the compiler which will disregard these 'detail brushes' when generating VIS information and subsequently convert them back to world geometry. This is only supported by a few compilers; those without support will treat func_details as normal brush entities which will then make them disappear in game since they're an unknown type (QC).

Mind you, turning stuff into brush entities (e.g. func_wall) CAN help with optimization, but it depends on the areas/situation and some random factors, so it's not automatically the ultimate solution to everything. It requires careful testing and evaluation. 
I wasn't aware it cast shadows and isn't counted as an entity. That's pretty nice.

My understanding of portals is pretty shoddy, an article for them has yet to be written on quakewiki.

I'm not able to see if TxQBSP supports func_detail in any documentation, I guess I'll run some tests after work. 
That Third 
Article I linked explains portals relatively concisely.

I'm using Tyrann's compilers for the detail support since they've also got a load of nice little features like per brush entity minlight and coloured lighting as well as all the light controls you'd expect coming from Tx. 
I'll Have To Try Those Out 
vis does not respect vertical height (if its open at any point vertically it's considered completely open)

I don't think this is true, is there an authoritative source for this? 
yeah, I read that and declared aloud "are you fucking kidding me?" 
Surely this would be testable ny making a vertical map 
Nope. It's something I got from early Q2 mapping and assumed was the same for all.

Maybe I should do a test map before each post. 
It almost reads like mapping lore they gets passed along and nobody ever really understands or questions it.

Like, I have friends who make Quake maps who clip and miter every brush so that nothing ever overlaps. Ever. Totally clean construction. I've tried to explain they are wasting their time and QBSP takes cares of all that but they will hear none of it! "It makes for cleaner and better performing maps", they say. I say it makes for a lot of wasted time that could be spent more productively... 
Mitering convex corners is optimal. 
In what sense? I mean, if you're slamming up against engine limitations, sure, go for it but otherwise ... What's the point? 
For The Sake Of Optimiztion I Suppose 
It still comes out a more efficient map to run, however negligible the gains might be.

A few weeks ago I went through my map to try to get some vertexes back, as I'm nearing the limits of bsp29. I mitered most convex corners and got about 2k verts back from that alone.

I also fixed a lot of my early brushwork, it was really shoddy. brushes in brushes in brushes in bushes, all sorts of random shit of all sizes, off the grid even, all in one big mass of noob mapping.

After going through and optimizing the map, I had about 6k back and shaved 30 minutes off the compile time.

I can't explain it, those were my results. 
You better miter those brushes damnit!!

I'm partway through making a vert map right now with a door in every ceiling (it's a 768 map), I just tested this theory using r_showtris 1 and it doesn't appear to be true, it's definitely not drawing every single floor. 
Prepare for a possibly dumb contribution to the visibility discussion, but FWIW, what I remember from Q3 mapping was along these lines (it would be easier to do this with pictures but oh well):

Let's say you have a big cube of open space. A vertical wall divides the cube into two halves, but the wall is only half as tall as the cube. So you essentially have two rooms sharing an open space overhead.

The visibility here depends on how the compiler chooses to subdivide the space.

If it first cuts horizontally along the top of the divider wall, then the nodes for the space of each "room" will end up being only as tall as the divider wall, and they can't see each other.

However if the compiler first cuts vertically up the side of the divider wall, then there is going to be a tall node on that side of the wall, that goes all the way to the ceiling of the cube. In this case the nodes on each side of the wall can see each other.

The solution in Q3 was to have a horizontal hint brush face dividing the cube at the level of the top of the divider wall. So even if the compiler chose to chop vertically along the wall face first, the cut and therefore the room node would stop at the hint face.

If I'm misremembering/misunderstanding, or if the Q1 visibility issues are different, please clue me in... 
That's a really clear explanation. 
In that example, the compiler is going to prefer cutting up the side of the divider, without being given a hint. Every plane in the map is ordered based on preference for splitting. Vertical planes are higher priority than horizontal ones, and axial planes are higher priority than slanty ones. The map is assumed to be architectural in nature, so this assumption makes the compiler more likely to catch doorways or subdivide large spaces in a way that respects the layout. I think that's what we're really talking about.

This is why outdoor bits with lots of rocks tend to go kaleidoscopic, the compiler doesn't have a lot of vertical axial faces to go on so it digs deeper and starts using the sides of your wacky boulders to slice the space up. 
qbsp will usually clobber any fancy brush mitering you've done anyway.

i remember the doom3 compiler being really amazing about mitering things. i don't remember ever seeing it cut a wall up in anything but the best way.

quake bsp compilers aren't that good and rarely make the right cuts. to be fair, they are working under more stringent limitations (such as max face size) than doom3. 
you can FORCE qbsp to honour your face divisions by offsetting textures by 1 unit (because then the compiler must consider them as a separate face) but you're just giving the compiler less leeway to work with and it'll probably perform even worse.
i find it's better to keep your brushwork clean enough so you can work well but to not fuss overmuch with what the compiler is doing. 
Isn't Q1BSP more of a software era thing? Cutting things into small triangles to minimize overdraw. Iirc the software renderer only uses z-buffer reads for models and the world bsp is rasterized front to back? D3 doesn't have those limitations and does a fair bit of culling at runtime afaik. 
IIRC the old QBSP used to or at least had a tendency to produce weird results on overlapping brushes or multi-face walls even if they were all on the same plane with the same texture and offset. This is why "clean" brushwork was propagated. Another well-known example apart from mitered corners is that technique where the brushes on arches are turned into triangles that meet in the upper corners.

Newer compilers take better care of such cases, although their results can still be arbritary at times. I found that occasionally "sloppy" constructions caused better splitting than "clean" brushwork for whatever reason. 
Newer compilers can combine faces, while older ones only split them. Doom3 doesn't need you to do any mitering because any extra cuts in a continuous surface that are introduced by the brushwork are optimized away again.

Doom3 also doesn't do any previs calculations, instead relying entirely on designer-placed portal surfaces that it tests for overlap in screen space in real time. (you can turn on r_showportals or something and see them turn red and green as you run around.) This is much simpler, and completely avoids any wacky how-is-qbsp-hacking-my-rooms-apart trouble, but also means you can't build any kind of large or interesting space that can't have its visibility constrained by little doorways. Yada yada yada and you get Doom3's level design.

This room was a bitch:

That big solid platform in the middle blocks the view of doorways on either side of it from each other, but because those portals overlap in screen space they were always considered open. The proper solution is to have some kind of occluder or antiportal inside the platform, which doom3/quake4 didn't have, so we had to - surprise - cut the room apart in wacky ways with huge portals instead. 
wow, that looks really pretty. 
I Read About D3's Occlusion Culling System 
And assumed there was some stuff I was missing because of handling cases as described above. The reality seems rather depressing :) 
but only for special cases like that. i found that usually it was a very easy system to use. 
Was it similar to how mapping in Unreal Tournament was by putting a non solid plane in doorways to make each room its own portal? 
sounds very similar.
in d3, you make a brush with a non-solid texture on all but one face. on the last face, you put the portal texture and that becomes the portal. 
Setting Up A Lightning Trigger 
in a map.

So I made a test map just to see if it works, it works fine. so I copy and pasted the whole set up into my actual map and now the lightning no longer fires at the target... anyone have a clue what the hell is going on?? 
Lightning In Standard Quake? 
If you're using the Chthon lightning entities, you should know that they're a bit hacky, and you can only have one beam of lightning on the go in a map. Might it be that in your copy-pasting you created two overlapping endpoints, and so the lightning beam is zero-length? 
I'm using quoth...

I re-did it all again several times and on the 4th time it now works again. 
Door Lip 
I want a door with lip 0.
Setting it up causes it to reset to default(lip 8). So after a while i found that lip of -0 is doing the trick, i have a door with no lip.
Is this in any way bad? For gamelogic or sth? 
From a technical POV that is cool. It has always been a little problem in QC that you can't distinguish between a key that hasn't been set, and one that's been set to zero. It would be nice to make the convention that -0 means "explicit zero". I don't think there's anything immediately bad with it while it works. What I do worry is that something might break it somewhere - I can imagine two ways:

1) An altered QC compiler might just be able to add a bug-fix everywhere for this surprising behaviour, and end up cancelling out the feature.

2) A new engine also might notice buggy behaviour relating to this and patch it out.

In both cases you'd end up back with 8 unit lip. The question is whether anything breaks it already, and if not, whether it's compelling enough as a feature to become a de facto standard, so engines that deviate are considered buggy instead. 
How About -1 

Surely this couldn't be broken. And having minus 1 unit isnt so bad. 
but what if you actually WANT the lip to be -1? 
You can add little brush for door in invisible zone (e.g. inside wall) and use neg. lip 
Door Flush With Frame When Open? 
Another way to do this is place the door on the position you want it to be when open (flush with frame). Set spawnflag "start open". Make the door 8 longer (or whatever the lip is) on the side that would be hidden in the frame and leave lip at default.

bam. kinda clunky, but it won't break. May wanna add a a trigger, depending on the situation. 
My Brain Wasn't Working 
Just tested it. When I thought of it I pictured the default trigger to be hidden behind the wall for some reason, that's not the case it seems. Works fine, no extra trigger needed.

-0 doesn't work for me btw. 
Oops, Lighting 
Lighting the door properly would be a problem... lol, disregard everything i said. 
Other QC Solutions 
I've not tested this either, but if you tried it and it didn't work, it could be the result of your compiler or your map editor "correcting" a -0 to a 0. Checking the entities in the BSP file might be necessary to verify if this works.

There are other ways this could be fixed from a QC perspective. The first way would be to acknowledge that 0 is a valid value for lip and not apply a default to it - but obviously that's not backwards compatible. It is still a thing to consider for new entity classes.

The other thing to do would be to add a new spawnflag to the entity called NO_LIP, which would override the default (or any other value set) and make the lip zero. This would preserve backwards compatibility for doors. It might also be a useful pattern for some new entities, if zero is a permissible but rarely applicable value for the field, and the default value is much more sensible. 
I'm trying to make an info_trap shoot towards a moving func_train to emulate randomness, but the projectile keeps flying towards the map origin instead.

The next thing I tried is using func_train_rotate... which then keeps saying "Next target is not path_rotate" when it clearly is. :(

Any halp? 
Leak In Map 
After doing some really heavy duty optimising in one of my maps it's started saying I have a leak when I compile

Using a couple different compilers points to slightly different areas of the map... I'm at a loss as to where it is! 
my shoddy brushwork created some terrible microleaks...

Which idiot was it that was saying mitre'd corners were pointless??? 
Try using a func_train_point (or if that fails a misc_teleporttrain). The info_trap aims for the origin of the targeted entity, but brush-based entities in quake treat the origin key as "displacement from initial position", hence why it's firing near to the origin. I really must write a blog post which explains this properly, it's a common source of confusion. 
Teletrain did it, thanks. 
"Which idiot was it that was saying mitre'd corners were pointless???"

Probably me. Hey, welcome to Quake mapping. Leak hunting is part of the experience. 
A month or so ago I had a leak in a stupid big map. I had just done about and hour or so of mapping without checking, so it could have been anywhere (the pointfile wasn't much help).

Long story short, I just made a big box around the entire section of the map and would slowly shrink, recompile, shrink, recompile until I got the box to be about 128x128 with the leak in it. Takes only a few minutes and works when compilers fail. 
I had made some brushes in a way that I knew was a bit shitty... looks like they had finally degenerated to the point where they microleaked.

It's my fault really for not being more cautious. I put part of the blame on func though for putting pressure on me for saying that my map pack has to work on the normal quake exe (actually it works on winquake, there's no way I'm testing this shit on the dos version).

The worst part of this is I had already completed maybe 70% of the first episode but I have had to go back and redo huge areas (or restart some maps from scratch) to get them to work. Currently redoing one map entirely now that I had finished months ago, I have tried for a week to fix it but I can't optimise it properly so it's just going to be a different map with a similar theme. 
No Ambient Sound For Water 
I've noticed in my maps recently that they do not have ambient sounds despite the map named *water or *04water

Any ideas? 
It's Forced By The Engine 
For particular texture names included in the id1 wad. And I think some of those don't work as well. 
Like sky a water not have sound if you compile map without VIS. 
which compiler are you using ?

I know there exist some options with aguirRe's RVIS and so maybe derivative, aka:

"-noambient", "-noambientlava", "-noambientsky", "-noambientslime", and "-noambientwater" to better control ambient sounds.

Are you sure you do not use one of these options ? 
None of those options are being used JPL. I'm using Tyranns tools (I think). It's kind of weird though. 
Did you try to change of water texture, and check whether the sounds is still away ? 
Any chance that the vis process is failing for some reason? You'd still end up with a valid bsp file and the failure would only show up in the logs. It just sounds like the map is unvised, so it might be worth investigating that step of the compile. 
It's Properly Vis'd As Far As I Can See 
I used r_showtris 1 and everything looks sound, I even get the sky ambience but no water ambience. The texture is appropriately named so I'm not sure what's happening. 
.. Can You Check.. 
.. whether the water sound (don;t remeber the file name) is present in your pak file or sound folders... maybe it is just missing: in that case you may have an error/warning message in the console claiming the file cannot be found... hence the issue... though...

But I admit it is weird... never faced that issue before... 
some are *mwater which don't make sound.

they have to start specifically with *water 
Trying To Find Textures 
Any good rock textures for quake? 

It's kind of a shame we don't have a system for searching wads like we do for maps on quaddicted. If we could type in "rock" or "tech" or "crate" then it would be awesome.

Or how about some kind of "wad builder" where you basically shop for textures and then download your custom wad. (it could also write a .txt file which you could copy/paste into your readme)

If only I knew how to code! 
that actually sounds like it would be an interesting project. certainly not overly difficult, but would require a lot of 'manual labour' to set up the initial index and tagging all the individual textures.

the back end stuff would probably be the easiest part. basically a db which links logical texture metadata with the appropriate wad files. you'd probably either want to extract everything as loose png files or something for speed.

the web app component-- getting search results xferred over to the client browsers while maintaining responsiveness etc... would probably be the worst.
you'd definitely need some ajax async stuff so you can load images as they come in, not sure how much of a load on the server that would be. most textures are 64x64 or 128x128 which isn't all that much, but loads of tiny requests like that would probably still be bad. maybe each wad file would be stored as one large spritesheet image or maybe the backend itself could generate these spritesheets grouping textures that have the same tag. 
That Clipnodes and Marksurfaces exceed normal engine max error.
What is the easiest way to handle?
Deleting brushes, scaling up hull textures?

For some reason I always exceed the limits. 
clipnodes can be reduced by putting clip brushes over parts where the player can't go.

they are created by things that the player can collide with, so putting clip brushes over them makes less places the player can go, thus less clipnodes.

marksurfaces are weird and will randomly go up and down. 
That helped stopping the clipnode warning.

I keep that shade blackouts on some brushes.
I've been trying with light settings, but the complete black brushsides seem hard to avoid. 
Any Tips For Good Lighting? 
Lighting Tips 
* Never place symmetrical light sources in a room
* Never use global ambient light, learn to light maps properly
* Place strong light source first before placing additive fill lights
* If a room lacks strong shadows, tone down fill lights
* Consider shadow area contrast when placing source lights
* Understand the advanced features of wait/delay
* Try to keep light/wait values consistent for light source types
* Always sync light entities to actual light sources
* Always Illuminate the primary path
* Light Flicker (style 1) can be useful for focus in a room
* Play with up lights for ceiling detail focus
* Lights can use mangle/angle parameters for directional spotlights
* Lights should always create interesting shadows
* Place strong lights for large shadows, fill lights to soften the edges
* Switchable lights are perfect for creating dynamic detail
* Place identical light sources at the top and bottom of platforms so that when the platform is in both positions it looks right for the light source 
Total Newbie Question 
Hi all, I'm just starting to learn TrenchBroom with no prior mapping experience for any game whatsoever. All of this is entirely new to me, and now I have a stupid question:

Can water brushes overlap with solid brushes? I mean, when you want to create a body of water in a map (like say you've created a pool that is not just a rectangular box, but has sloping edges etc.), do you then have to create a water brush/brushes fitting that space exactly? Or can you just create a huge rectangular water brush that overlaps with the edges of the pool/lake, as long as it fills the space you've "carved out", as it were? 
A Huge Brush Covering Everything Is Fine. 
How the bloody hell do you remove mouse invert? And which evil bastard decided this should be the default behaviour for mouse look?!?! 
Hold Mouse Upside Down 
Install Trenchbroom 
can't yet make heretic 2 maps, the version of QED you get with the latest heretic 2 patch doesnt work properly. Plus I have no idea how to properly compile Heretic 2 maps outside of Quark (Spent a good few hours trying to compile manually with no luck)

Ironically the brushwork was mostly created in trenchbroom, I just opened 2 instances of quark and copied the brushes over. 
those are some good tips sock, but how am I supposed to learn how to do lighting properly? 

Make a small map and light it. Start the game and go look around in the map. Make notes of what looks good and what doesn't. Go back to the editor and change the stuff that didn't look good. Use sock's guide to go by.

As with most things, you learn by doing. 
Another Newbie Question 
How does one make an exit trigger in TrenchBroom?

I created a brush big enough for the player to walk into, right-clicked on it, selected Create brush entity --> Trigger --> changelevel, but when I compile the map with hmap2 and play it, this brush is not there. Am I missing something? Are there certain settings I should change? 
There is a long phase at the end of a map's creation that's just tweaking some lights and rebuilding. Nature of the beast.

-onlyents is very nice to have at this phase.

Does Heretic2 have a different .map format or is it just different entities? 
... how does one create a set of doors that slide apart in TrenchBroom (instead of one panel that slides into the wall)? I've created two brushes and made them both doors, but they just slide together in the same direction. I guess there must be setting one can change somewhere, but am clueless as to what and where.

I hope this is the right thread for these absolute beginner questions... 
You Have To 
either "unlink" the doors by setting the entity flag as unlinked, or create a new key called "angle" and set them at opposite directions. 
Thanks, That Did It 
I did both -- clicked "Don't link" for both doors and gave them both a new property called "angle", and made one "180".

Thank you so much! 
Try r_lightmap 1 - it can help you improve lighting without the textures getting in the way. 
RE: Trying To Find Textures 

Trying To Find Textures
#13862 posted by RingofQuaddamage [] on 2014/06/22 16:19:30
Any good rock textures for quake? 
keep them linked if they're double doors, or they'll open separately if you stand in the right place

setting two different angles is all you need 
Thanks, Lunaran 
Any idea what I'm doing wrong with the exit trigger (post #13880)? 
You Need 
To point it at the next map - whatever.bsp or it'll not do anything. I can't remember what the key is called offhand.

Also, triggers are never visible and are only rectangles - so I big prism will still be a rectangle in game. 
Re: Lighting 
If you can stand my colour scheme (or disable styling) here's a kind of overview of lighting: 
the keyvalue is "map" ijed :)

set it to the filename of the next level, without the extension. if you don't have one, just use 'start' or the name of the same level you're already in. 
Thanks, ijed and Lunaran -- that did it. :-) 
Newbie Mappers 
Fantastic that Quake still brings in new mappers! 
More "newbie" Stuff 
Is there a way of making a secret door retract into a wall, and then go upwards? Or am I stuck with a handful of cardinal directions? 
That's What Secret Doors Do 

"open_once" once open, stays open
"1st_left" first move is left of arrow
"1st_down" first move is down from arrow
"no_shoot" only opened by trigger
"always_shoot" even if targeted, keep shootable

Maybe a negative lip allows you to reverse the first left / first down directions.

Never played with them much to be honest. 
Better Info 
I needed a door to use as a long, extending walkway. I needed it to slide out about 256 units, then up 16 units. I thought I could do it with a secret door somehow but I never could get it to cooperate. I ended up just using a func_train and used a little door hidden in the floor to provide the sound.

As far as I could tell they only go bang and pop open then slide in whatever direction they're set for. I always meant to go back and experiment with them some more but haven't got around to it yet. 
Yet Another Newbie Question 
Suddenly my map does not want to compile anymore (I've been compiling and testing every so often until now) and I get the following error message:

LinkConvexFaces: Mixed face contents in leafnode

Clearly I've broken something, but I don't know what. Can someone explain? 
Don't mix normal textures with liquid/sky textures on your brushes. 
don't have liquid brushes and sky brushes touching. 
It Was # 2 
I had a teleporter brush and a sky brush touching. Thanks so much! 
Light Question 
What to do with black washed out vertices that are placed on grid
You'll have to redo the brushes or get them back on the grid properly.

I had this problem with the rockwork in q-deck, I ended up redoing that area about 3 times. Every time I opened up the map the vertices would degenerate until they started looking like your screenshot. 
Best Advice I Ever Had 
bind "snap to grid" to the space bar and every time you mess about with the vertex tool hit space. It has saved me a hell of a lot of trouble.

That is if you're using Trenchbroom, and also make sure you enable force integer plane points. 
I needed a door to use as a long, extending walkway. I needed it to slide out about 256 units, then up 16 units. I thought I could do it with a secret door somehow but I never could get it to cooperate. I ended up just using a func_train and used a little door hidden in the floor to provide the sound.

e4m1 actually has this too. i think that that is the one thing a secret door can't do. 
I Suck 
it's e2m1. 
Force Integer 
Means you won't have to do it by hand (spacebar), unless you've already created so many degenerate brushes that you crash the editor when trying to do a global snap to grid.

But you guys won't be anywhere near that yet. 
Well How About That 
I once snapped a perfectly fine brush to grid and it offset it by about 0.00403434 units 
that's not true, I force integer plane points and get off-grid vertices all the damn time if I don't also snap to grid.

TB can be a little temperamental. Sometimes I mash the force to grid key a bunch of times just to make it "stick". I'm sure I'm being superstitious with that though.

Sometimes I will end up with a random leak after a while in a map to find that a brush that caused me no trouble before has suddenly degenerated and become off grid. It's not too often this happens now but I haven't tried to make any crazy terrain in a while.

My advice is make complex terrain as your last thing. 
I knew the force-to-grid advice would follow.
Reason I asked after they already were. 
when you clip a brush at lots of wacky angles, often the editor can't snap all the verts to the grid, because to snap one means slightly altering the angle of a plane to accommodate it, which would move several other verts by a different amount. this is because the verts don't determine where the planes are, the planes determine where the verts are by their intersections.

build your rocks and terrain out of brushes that are more ... brushy. make sure you clip them at integer ratio angles so that the planes always intersect at points that have a chance of being on the grid in the first place :) 
I always just use brushes that have triangle faces and move the vertexes as needed keeping them on grid. I almost never use clipping. 
Editors Lie 
Thanks Lun for your explanation.

I just saw the brushfaces slowly change in the editor and started again untill I had the right one.
Then, while mapping on, the sides became louzy, although I hadn't changed anything.
So going back to the right map slowed awfully down.
Now all brushes that stand on grid in editor start blacking out.

So editor snaps all verts untill I believe they do and then start degenerating.

@Ricky- all brushes in the screenshot are triangles that have moved vertexes, but they start telling lies. 
Wouldn't anglesense help here? 
Worth A Try. 
When I compile the map without light there's just a smooth surface,
so the error isn't the misfitting brush.
I could try anglesense, but there are many parts here so many extra lights.
Replacing them with brushes for light sense I never encounterd. 
what about making the entire hill a func_wall? 
those are some good tips sock, but how am I supposed to learn how to do lighting properly?

I would recommend you find a map you like the look of (light wise) and then check out the source map file to see how it was done. Break the example map down into a small sections with light entities and gradually remove the lights one by one until you see what difference it makes.

Learning lighting for old BSP compile engines is the most time consuming thing because it involved compiling and waiting for the results. The best advice is start with lots of small test maps and try to find some good source map examples. 
Critical Or Not? 
WARNING: Mixed face contents (Sky, Empty) near (x y z)
WARNING: Mixed face contents (Sky, Empty) near (x y z)

I have like 20 of those when running txqbsp. 
When I compile the map without light there's just a smooth surface,
so the error isn't the misfitting brush.

the bsp structure around all those brushes probably looks like complete mulch. I'm not surprised light.exe has no idea what to do with it.

take metlslime's suggestion, make the whole thing a func wall. and put skip brushes behind it so it doesn't leak, of course. 
This is old now but stands true on most cases:

It should you understand whatever errors you're getting. 
How About This. 
Processing hull 1...
*** WARNING 09: Couldn't create brush faces
*** WARNING 09: Couldn't create brush faces
Processing hull 2...
*** WARNING 09: Couldn't create brush faces
*** WARNING 09: Couldn't create brush faces

I started getting these after removing a brush that wasn't closed. 
Things To Try 
* Use different compilers, see if the problem disappears
* Contact compiler author if there's no obvious remedy - maybe it's a tool problem or can be fixed through a code change.

@ModFax :
Is the eMail address in your func_user information still accurate ? 
Func_door_secret Bend To My Will!

That's how you do a func_door_secret that moves up last. Hardly even feels like a map hack, but there it is! 
To quote a household name, thks Preach ! 
Blacked Castle 
@mtlslm- turned it into a func_wall but nothing changed.
I thought func_wall didn't lit light.

@rebb- I can do, but I was wondering why the compiler give normal results, before the error started.
As long as you don't send me mod faxes I'm reliable on that email adress. 
that looks similar to a bug I was helping mfx with: - In that case it was an engine bug, but I think it could also be caused by the light tool being compiled with sse2. which light tool are you using? 
@MadFox, if you'd be willing to send me the map source and compile tools you're using, i'd be interested to poke around and see if I can see what's happening 
it's way. 
your email account wasn't outdated... 
Func_door_secret Bend To My Will! 
I will definitely be trying this. I've used the func_train method in at least three places. This could free up seven or eight entities (I'm at the 256 model limit right now). 
Well, It Works But... 
The door comes out of a wall and there is no light where it starts. This is a problem. With the func_train I just place it where it's going to end up and it moves to the starting path_corner when the map loads. That way it's properly lit.

With a regular door I would use "Starts Open", but that doesn't exist for secret doors. I tried reversing the way it moved but I can't seem to get it to wait between being triggered. It either opens then closes or just stays open.

It would have been nice to free up another dozen or so entities, but I can probably finish the map without them. If I can ever get around to it anyway. 
might be a possible solution to the lighting... though it may be a little flat 
Manual Starts Open 
Here's a bonus hack, especially for you Rick. Move your func_door_secret into the open position, and as you do, measure exactly how far you moved horizontally and vertically. Suppose that's -256 in the x direction and 16 in the z direction.

What you now need to do is add another key to your func_door_secret - an origin key. Set the origin to be the vector that negates the movement you just performed, so for the example values above you'd set "origin" "256 0 -16". Negate each value and stick it in a vector, with a 0 for the coordinate you didn't change. Hey presto, lit in the open position, spawns in the closed position!

This trick works on some, but not all other entities - func_door for instance have problems in generating automatic triggers. So have fun, but take care too! 
hm, mail didn't seem to get through, unfortunately. the address in my profile is correct. Could you upload it to dropbox maybe? 
Tried again, and now it worked.
Cheque your emailbox. 
Manual Starts Open 
I was actually thinking that origin might somehow work but I wasn't sure exactly how to do it. I'll give it a try when I get a chance. If I can make this work it will be very helpful.

I was afraid I'd have to somehow try to box in the door and light it in place, but that would likely blow my marksurfaces out of the water. I only have about a hundred of those left. 
Release The Kraken Rick 
Alternative Fix 
Someday, I'd like to spend enough time learning the bsp formats that I could write a new tool. This tool would take the idea of external bsp models and flip it on its head. The tool would take a bsp file, and would look up all the external bsp models referenced. Then it would add all those models as internal models of the original bsp, and patch all the entities to load those internal models. All the benefit of external models, one convenient file!

Anyone with the know-how already Please, please feel free to steal my thunder and do this so I don't have to! It would solve the problem at hand in a simpler way, and would also let you easily prefab models, which might help with the model limit. 
Easily prefab models that would be lit exactly the same way every time, you mean?

I'd prefer something more like sub-map instancing (like CoD & Source), but that'd require both a compiler change and an editor change to allow for the visualization. But boy, would that be great. 
I finally got the sliding secret door to work. It gave me brain damage though, I guess because seems to work backwards from how I expected.

Apparently the door is lit in the position set by the origin key, but then moves to the position it was actually placed in the editor when the map is loaded.

The door is 320 units long and moves to the right (positive X) and then up (positive Z). I had to make the origin key -320 0 -16.

It does work though, slides out of total darkness lit perfectly for where it ends up. 
Easily prefab models that would be lit exactly the same way every time, you mean?

Yeah, but because it's lit independently, you'd have the freedom to give them "generic" lighting - like the ammo models do. Particularly if it's a moving model like a door, where you can't do anything better than general matching of the ambient light. 
Tyrann's _minlight 
Has solved my headaches in this department. Especially good for getting rid of black polys and for lighting glass. 
Skipped Faces? 
Updating to tyrqbsp v0.15 fixed it. 
Growing Pains... 
After having spent days using the clip tool to painstakingly carve brushes to look like rotated objects, I only now realised TrenchBroom has a "rotate" tool and I could just have, you know, rotated those brushes. You may all now point and laugh.

On a different topic: is it possible to have the player start a map with no weapons or ammo except for the axe? If so, how? 
Sometimes it's safer to clip than to rotate, though, because the latter can give you some quite ugly and offgrid results. Rotating a crate should be fine, rotating an entire room less so.

Also, yes
Preach is the wizard with those tricks.

Probably something to do with spawning onto a box of shells with negative ammo 
Preach Leaves You Stripped Sometimes 5th? 
He�s a genius in QC tricks. yep.

And staying on grid should be your 1st goal, advice from former �bernewbie. Better clip. Or rotate 26.66667 degrees?

You get it. 
Clip is better 'R' in Trenchbroom does produce bad results - I have several objects built in my current level which crash the editor if I try to rotate them.

Having said that I rotate loads of stuff. Like OTP says, just do it on props, not entire rooms. Unless you're doing something cool

ALT-ARROW however rotates orthographically and is 100% safe. 
Learning how to build a whole room tilted 45� with everything on a 3:3 ratio and all the textures scaled 0.75 is almost as important a skill as learning how to build a whole room tilted 22� with everything on a 1:2 ratio.

First you learn not to carve, then you learn not to scale, then you learn not to rotate. The enlightened zen of mapping is to never start the map in the first place. 
"Unless You're Doing Something Cool" <-- I'll Keep That In Mind. 
Wow, thanks for all the fast responses. 
Where's that bug report ;-) 
The Sound Of One Hand Mapping 
First you learn not to carve, then you learn not to scale, then you learn not to rotate. The enlightened zen of mapping is to never start the map in the first place.

This is beautiful, but it's missing the lesson about texture lock. 
Writing it on my hand now. 
Know that you can overlap brushes. And know that it doesn't matter if the intersection points are off-grid (99% of the time).

You can waste a lot of time cutting things so that they don't overlap, but there's really no need. And it's good practice to keep brush vertices on-grid, but the points where they intersect, they don't need to be on-grid.

But yeah - NEVER use the Worldcraft 'carve' tool, no! 
Texture Lock? 
Like how you'll eventually wind up with textures offset by 1 after dragging them all over the place? I thought that was a Radiant/QE3 specific bug. 
Radiant can do some weird stuff when texturelock is on, and can do weird stuff with entity angle keys. Getting scientific notation for something rotated 90 degrees is o_O

Otherwise, texturelock is perfectly fine, especially when copying things around. What you DON'T want is to make a brush, then turn on texturelock, and rotate the brush to get a rotated texture. Make the brush with a known slope, and you can just use arctan to figure out the rotation. I have planks in my jam map that are at a 1/8 slope, so that's a 0.125 slope, arctan(0.125) = 7.125 degrees. 
Re: Know That You Can Overlap Brushes 
Thanks, RickyT23. I was actually wondering about that too.

I recently looked at the sources of apdm3 and bbelief2008 and brushes sometimes overlap in both those maps ... so I started to suspect that I was wasting my time cutting things and making sure they line up perfectly. 
Make the brush with a known slope, and you can just use arctan to figure out the rotation. I have planks in my jam map that are at a 1/8 slope, so that's a 0.125 slope, arctan(0.125) = 7.125 degrees.

This would have been very useful in the past two weeks. 
I wanted a window with a beveled frame at a 45 degree angle, but I couldn't figure out how to make it from scratch (Radiant wouldn't let me move the vertexes the way I needed), so I built it on axis, then rotated and scaled it to get the final result.

(image has been lightened a bit from the original .tga) 
God I Want To Play That Map. 
I worked on it a bit today, first time in months. There is one area where if the player falls in the water, they can't get out.

I stared at that room for about an hour without coming up with a fix that didn't look stupid and fit in with the rest of the area.

I have a few hundred marksurfaces left to play with, I guess I'm going to have to spend them on that room. 
Make It Lava! 
in the original Well of Wishes it was slime. Only now the player has to go into it to reach a previously hidden area, but until the area opens there's no way out if they fall in. 
You're remaking wishes.bsp?

I love you. That map was a huge influence on LunSP1. 
Thanks for the compliment.

I started in 2007 just wanting to fix the flaws in the original, then it evolved into a sort of quest to see how close I could get to the normal Quake engine limits without breaking any. I haven't worked on it continuously, there were years when I didn't touch it at all.

It now only bears a vague resemblance to the original. I think you could probably fit the entire original map into the open area in the center.

Anybody that's interested, at there's more screenshots. They all have Wish or Wish13 in the name. Some are of things that have now been changed though.

It really is pretty close to being finished. 
Probably something to do with spawning onto a box of shells with negative ammo

With a normal ammo box ...

Why isn't it working for me only when i use the restart command when i am placing the info_player_start above the ammo box? 
I have no idea coce... I just trawled through preach's website to see if I could find the trick but no luck.

I know it's something to do with spawning on top of an ammo box (or maybe a backpack?!) with a negative key. 
I've Fucking Linked To It. 
Yeah, I meant to say earlier: thanks very much for that link, OTP. 
No Probs 
Negative Everything 
Cocerello, Fifth, it's post 13950. Here it is again
No, No 
I was talking about placing a completely normal ammo box with no modifications in to increase the ammo of the player.

The question is Why the ammo box dissapear when i begin playing the map with the restart command instead of writing again map xxx?

And yes, i have read Onetruepurple's link, very interesting indeed, but this is a different issue. 
It's a well known issue in Quake, although I've never got exactly to the bottom of the sequence of events in the engine. The basic problem is that when you restart the map, the player entity is added at a different point in the startup sequence than when you load the map normally. It's all done with a bunch of behind the scenes console commands and messages.

I think that what happens is that in the normal case, the player is not added to the world until all the items have dropped to the floor, so everything works fine. In the restart case, because the client is already connected, I think the player's entity gets added before the items have a chance to drop. Because they spawn inside a player, they count as stuck, and so fall through the floor.

Anyone with good engine know-how able to back this up? Or better yet explain where in the code the differences arise? 
Cool Tricks 
I have to wonder though. Using an info_notnull why not just set it to just remove 25 shells instead? Why go to the trouble of giving all the ammo and then removing it using a door? I just removed the 25 shell ammo in a test map and it worked fine. 
Because They Are Removing Weapons Too 
Response To A Post From 2006/ Barrage Of Idiotic Questions 
Sorry Cocerello, I misunderstood your post.

About the ammo/weapons removal thing, I have been playing around with it and now I have several questions (mostly to Preach, I guess):

1) It says in that tutorial OTP linked to that you should use "a brush based info_notnull", but I only seem to be able to add "info_notnull" as a point entity in TrenchBroom. If I create a brush and then add an info_notnull, then I have a brush with an info_notnull sitting on top. I also tried changing the class name of the brush to info_notnull, but that changed the classname of all the brushes in the map, which seemed like a very bad thing to do (yes, I have no idea what I'm doing. But I'm learning). Just having a point entity seems to work, but I feel like I'm missing something here...

2) If you add/edit the "items" variable for a door, do you use the name of an item as value, or does every item have a specific number? In particular, if I want the door to remove only the player's shotgun, do I type "items" and then "shotgun", or "items" and then some number?

3) The reason I'm asking question 2:

If the weapons/ammo removal only has to happen at the start of the map, where you know the player has only a shotgun and 25 shells, does one need all three entities (the two info_notnulls and the door) or can one do the same with an info-notnull with the values
touch BackpackTouch
think InitTrigger
nextthink 0.2
ammo_shells -25

and then a door that just removes the shotgun? (I tried doing this, but I'm not sure "items" --> "shotgun" was the correct value.)

Or is there a reason why this is a terrible idea even at the start of the map?

4) Is there a way of muting the sounds of ammo/weapons being added and subtracted? 
Fifth, it is explained in the thread Onetruepurple linked.

Preach, thanks for the info. I checked it a bit more, and it happens too when you put the info_player start above the ammo box, while separating both boxes by 16 units. 
I can't talk for Trenchbroom - in Worlcraft you can type the entity class names.

What you can do is use Notepad++ or similar to modify the .map file.

.map files have pretty easy to understand contents. Just make your brush into a func_door and give it a unique 'targetname', then search for the targetname in your text editor and edit the class directly. Then when you re-load in Trenchbroom, the entity will be what you wanted :) 
is really easy to mess about with this as you can just rename the entity in the top right and whatever fields you desire. 
Ah, ok, that solves the mystery of the brush-based info_notnull -- I knew how to change class names in TB, but didn't know I needed to turn the brush into a func_door first (otherwise it changes the class name of all the regular brushes in the map).

I am guessing the advantage of having a brush-based entity here rather than a point entity is that it is easier to make sure the player falls though it at the start -- am I correct?

Thank you, RickyT23 and FifthElephant.

One question down, three to go... :) 
Question For 5th 
what good does "snap to grid" do? 
Not snapping to grid is why your maps kept bringing up errors when compiling. 
for me, snap to grid just decreases the grid size. is this normal? 
snap to grid moves all vertices of the selected brush(s) to their nearest corresponding point on the grid.

It never changes the grid size. 
That should probably be - it changes float vertex positions to integer. 
Another Dumb Question 
how do I decompile maps? 
Dont Do That. 
Get the map files. 
On Second Note 
If you just want to see the entity lump, you can
load bsps in QuArK 6.66. Or extract textures.
But dont use QuArK.
Dont do that. 
use winbspc

note: the decompiled map is not going to be that useful to build with or see how it was built, as it would be impossible to recover the original brushwork.

you should NOT use it to lift others work! if the author intended to allow you to do that, they'd release the .map.

you CAN use it to see how entities are put together or how a trick might have been done. that's basically the most useful thing decompiling can do. 
Two more silly questions:

1) Which is the best wad for the standard id textures (i.e. all the textures that were in the original game)? There are so many different wads on Quaddicted that I don't know where to start.

2) Is it better to add textures as you go along, or at the end, once all the brushwork is finished? I've been doing the latter, but now I'm starting to think it may have been a stupid idea... 
I believe has all the ones you want 
Most People Do It As They Go 
Willem tried blocking a map out without textures but didn't end up finishing... 
Thanks for the wad name and for the advice. Yeah, now that I've started "colouring in" what I have built so far, I see what a bad idea it was not to texture from the start... 
it depends what textures you end up using. Some textures like bricks and stuff are fine but if you're making something like a base map then it would be difficult to align the textures properly once you have blocked everything. 
Luckily it's a medieval map, so mostly bricks and wood. Still, it's proving to be a bit of a pain, especially getting the wood grain right everywhere, and texturing tiny details that I could have copied and pasted already textured. Oh well, better to realise the mistake now than several weeks or months later...

Besides, it's a beginner map, so chances are I'll need to redo most of it sooner or later anyway. 
Which is the best wad for the standard id textures (i.e. all the textures that were in the original game)? There are so many different wads on Quaddicted that I don't know where to start.

You can combine wads together. 
Textures, Part II 
I've been using hmap2 to compile the map I'm working on from time to time to test how things work (being inexperienced, I am still trying to get a feel for scale, etc.).

Now, having added textures to much of the map, every time I compile there are certain brushes that are still displayed without textures. hmap2 claims it cannot find the wad -- but the rest of the brushes do show up as textured, and they use the same wad. I've tried changing the textures on those brushes to something else, but the problem persists.

Does anyone here have any idea what the cause of the problem might be? 
Use This To Compile

The guy who made these versions of the compilers set the standard. He added many features and bugfixes that are now taken for granted.

I would recommend it. TxQbsp is as solid as a rock. Use that to compile the bsp.

Recently Tyrann has done some excellent work on his version of the compilers. You could also try these:

They are now, also, as solid as a rock.

One other thing you could try - before you compile the map check the wad paths in the .map file. Save your .map file from your editor, then open the file in Notepad++.

Look for the wad paths and check that they all add up.

The other possibility is that it could be a problem that you are having with the specific textures that don't show. Which wad are you using and which textures wont show? What are the dimensions of them? Are you using .wad or .hlwad files? 
Thanks for the recommendations, RickyT23. I've installed tyrutils, but can't get qbsp to work at all. I guess I don't understand the syntax yet; hopefully I'll figure it out.

The other possibility is that it could be a problem that you are having with the specific textures that don't show. Which wad are you using and which textures wont show? What are the dimensions of them? Are you using .wad or .hlwad files?

The same textures I used elsewhere in the map, that do show up on other brushes. Mainly city6_7 from as recommended by FifthElephant above. I'm using just this one wad at the moment.

One other thing you could try - before you compile the map check the wad paths in the .map file. Save your .map file from your editor, then open the file in Notepad++.

I'm on Linux -- does it have to be Notepad++, or can I just use a different text editor? I am able to open my .map files with the default text editor, but maybe that does not show all the information Notepad++ would show. What am I looking for?

You can combine wads together.

Thanks, necros. I wanted to restrict myself just to the id textures to begin with, though, which is why I was looking for a wad that contains all of those and nothing more.

Thanks, Spirit. I used that when I opened TrenchBroom for the very first time and it was tremendously helpful, but I don't think it solves my current problem. 
Try tyrqbsp with the -oldaxis switch. 
Re: not appearing textures.

Check the concerning brushes, maybe you�ve got duplicates there.. I had that once. 
Mfx, You Are My Hero! 
That was exactly it -- duplicates!

Wonder how that happened? 
and Gin? 
That Would Probably Do It. 
Hehe :-)

Actually, I didn't even know there was a Ctrl+D function until now.

I rather suspect it has something to do with selecting a brush and then Ctrl+ clicking something else to select it too, and inadvertently moving the first brush and moving it back without noticing. 
An indispensable program:


Open all the wads you want, drag all the textures you think look good together into one wad, only load that wad in the editor. Export/import from sane image formats to create your own additions! Hide stupid messages in your trigger texture! In a solid, utterly bug-free (albeit windows only) GUI app.

It's the best tool. Does what it says on the tin and it does it well.

What ever happened to Mickey? I heard he disappeared because he went broke and had to start couch surfing but that was ten+ years ago. (the economy is way better now!) 
Is awesome. 
OK, The Compilers 
I assume you might be using an editor that exports a .map file and runs the tools automatically? Whether that is the case or not, realize that the tools are standalone apps. In order to make a playable and lit .bsp file, you need to run three apps, in order.

Export your .map file from your editor and put it in a directory on your root hard drive called 'compile' or something. Now you should't have to worry about the wads not working, because inside the .map file there there is a little bit of text where the full location for the .wad textures are. <