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
Necros & PuLSaR 
Both your latest maps seem to have excessive # marksurfaces (> 32k), check the compiler log summary for details.

Some engines might behave unpredictably (e.g. crash) while playing as a result. PuLSaR has already noticed this behaviour in a previous version of his map. Unfortunately, even with the bad brush rebuilt, marksurfaces are still too high.

I haven't been able to actually produce a crash in neither of the latest versions of your maps but some engines clearly have this limitation (and don't enforce it).

I've added warnings in my upcoming compiler version for this and other limits. 
Who's Mark Surfaces? 
and what does it mean? you mean, just plain surfaces? like wpoly? 
Mark Surfas 
Mark Surfas was the founder of PlanetQuake, and therefore the owner of GameSpy Industries. He's also $20 million richer than he was ten years ago thanks IGN buying him out. 
Metlslime (or Any Knowledgable Soul) 
On what we previously discussed. If you were to resample the pixel resolution of the Quake textures in use in your map to twice their normal density you wouldn't significantly change the visual quality of the texture (without touch up work, like adding gradients), but it could noticeably increase the qualitiy of the light map resolution? Do I have that right? Would you think it worth the evening of experimenting I plan on doing tonight? 
Could Be Definitely Be The Geekiest Post Ever 
Any one know where I can find an Elvish font type set? (I am so emberassed) I need it for some textures I wittling. 
I'm Wittling 
spelling/gramatical error compounding my red cheeks 
yeah, becuase lightmap resolution is tied to texture resolution. 
Look in the compiler log summary for the marksurfaces value.

Unfortunately I don't know what they are or exactly how to reduce the value. I assume they are related to brush faces somehow and by reducing complex geometry, they will also be reduced.

What I do know is that if they exceed 32k, some (or maybe even most) engines might behave unpredictably or crash at some point while playing the map.

It's a bug in the original engine code, the bsp limit is actually 64k. 
These are pointers to actual surfaces. Each leafnode has one marksurface for each actual surface that touches the leaf. Since QBSP merges surfaces, a surface may be shared by more than one leafnode, so there are often more than one marksurface for each actual surface. 
An "actual surface" = a wpoly. 
Mark Surfas was the founder of PlanetQuake, and therefore the owner of GameSpy Industries. He's also $20 million richer than he was ten years ago thanks IGN buying him out.

Yep, "Bastard" Is His Quake Alias 
Error Help 
hi everyone. i just tried to load up the latest build of my map in winquake, and it crashed with this error message:

"SZ_GetSpace: 8002 is > full buffer size"

can anyone shed some light? 
Too Many Entities 
this is a usual error in big maps, remove some entities (better bmodels).
I think you need to remove only 1 or 2 entities. 
Thanks Pulsar. 
bugger. that makes sense, as i've added a load of bmodels since my last build. (and i had planned to add a load more!).

i really don't know where to start cutting down... :( 
I've Seen Those Funny 
error messages a lot lately ... 
That's My 
fave error :)
cuz sometimes engines crash without any errors. 
Related Question... 
in quake, you know how the ammo boxes etc. are bsp models? well, does the engine treat these similarly to "proper" brush models like doors etc, i.e. if my error is caused by having too many bmodels, could it also be solved by reducing the no. of ammo box models (replacing them with .mdl versions for example)? 
If you haven't already, take a look at the archived QMap thread at my site, there are a lot of good stuff in there. Just d/l, unzip and open in a browser. 
GTKRadiant Again 
anyone ever notice when your map starts to get big (+4000 or so brushes), there seems to be some sort of lag on the mouse, when right clicking and dragging to move the view? but not really lag... but like, when you right click and start panning the view, sometimes, it "won't let go" and keeps panning for a few seconds... like it received the +rmb, but not the -rmb..? anyway to fix this? is this a problem with the editor or windows? 
hmm, didn't notice that. maybe u got cubic clipping on? it might slow down things if it's on on a large map... 
Very Good Stuff, AguirRe 
thanks for that - quite a few tips under my belt already, and i'm only halfway through the yr 2000 posts! 
I'm currently tweaking a beta level intended for use with a mod though this version is purely vanilla Quake and the game play is complete in and of its self. If you find it mutually beneficial and within your time constraints, I wouldn't mind handing it over for you to examine, and would apreciate any advice you would have to give. 
Sure, I'd Be Glad To 
check it out technically, but I'd rather not play it through for real until you release it.

Just send me the zipped map+wad and I'll take a look at it. There's always something new to be learned. 
Beta Testing? 
anyone with a fairly powerful computer up for some beta testing? 
name the game! 
q1sp, of course. ;) 
Oh Wait... 
i'm kind of slow, did you mean that you were showing interest in testing or really was just asking which game? 
Hey, Necros, Pass It This Way 
I'd like to check it out 
your qbsp defaults to on when it comes to tjunc calculations, right? i'm still getting some sparklies, and was wondering if there was anything else i could do... 
well "high-end" to me means something that runs XXX brand new game well... which I cant do. But I run q1 quite well so i can test whatever! 
Just Check 
the compiler log, there should be a section for tjunctions if enabled (which it is default).

The red (from gl_clear) sparkles can still appear in large and/or "natural-looking" (i.e. lots of non-axial brushes) maps. Due to the high precision floats that were introduced in Tree 1.70 and Tx 0.79, sparkles are reduced, though.

My guess is that either you have some minor brush misalignments in those areas or the compiler hasn't been able to get all junctions right.

To see the effect more clearly, set a low uniform light by using the command light -fast -nolight -light 50 -sunlight 0 mapname. Then load the map and move around with gl_clear enabled and it's easier to spot the thin brush seams.

Are the sparkles already there in the version I have (from Apr 8th)? 
Sorry I said those God Awful things about the colour Orange. Can you forgive me and let me beta your level? 
About Fog 

I've seen FitzQuake/GLQuake are able to support fog option: this one can be added via the console typing fog < value 0 to 1> . It adds a fog effect (fog 0 => no fog / fog 1 => you can't see anything but foggy grey screen)...
My question is: is there a method to add this feature in the level editor (using worldspawn entity or other thing) to avoid console typing, or configuration changes into .cfg file ??
I would like to add a smooth foggy effect near the ground of my map..
Is there anybody who have an idea ??

You won't be able to add it just near the ground as what you're talking about is global fog. You would need volumetric fog to just have it in specific areas eg. in Q3 you can make a fog brush to just cover the area you require.

Various Q1 engines support global fog - look in the engine help files to find how to enable it. You should be able to control the depth of the fog as well as its colour.

Some engines also allow you to set triggers to turn it on & off for example when you move between inside & outside areas although this needs to be done with some care so the player doesn't notice. 
OK, it seems to be a little complicated to add fog feature... so I have to forget it.. grrrrr... :(( but I continue thinking it should be great to add foggy environment directly with a level editor: this can clearly increase player insecurity feeling... foggy effect (near the ground or globaly in a full map) is pretty cool to prepare monsters trap, adding secret area without teleport, etc..
Perhaps future Quake engine and level editor will fully support the this stuff.. I hope..
Thanks for your response... 
If you'd map for the Nehahra, you'd be able to manipulate with many such features as fog etc from the editor.... 
I apology for my ignorance but... what is exactly Nehahra ?? 
Volumetric Fog In Q1 
It can be done in a sort of hackish way. Just use a progs.dat that lets you send commands directly to the console with a trigger (hipnotic would work) and set up concentric triggers for increasing density of fog.

It would give the illusion of the player walking *into* fog, but you wouldn't see it from afar.

Although from what Vondur said... Nehahra supports real fog? huh. 
I apology for my previous stupid question... I found the stuff on planetquake server after an internet quick search... I've seen your are involved with CZG in this projects... Nice work really reagrading the screenshots...
Thanks for the info...
I will try it in the future on a litle test map...
It is difficult for a beginner like me to ensure a correct performing of this feature, so I'm pretty sure that when my first map will be released (hoping it will be done one day...), foggy environment will not be included.... even if I found the correct way to include it.... Anyway, I seriously have to improve my mapping effort to build maps as good as some designer do... and so to be able to create some cool feature like foggy environment in a map...
Thanks again... 
Headthump, Inertia, 
just wondering if either of you got my messages. my email has been pretty wierd lately. 
yeah i did, i tried to get the mod running with fuh with -mem 32 and it still said out of memory, i will mess with netquake clients tonight and check it out 
i don't know what's wrong with the other engines, espcecially because fuhquake uses the quakeworld code and not regular netquake code.

i do know it works fine in fitzquake, regular glquake, tyr-glquake and software tyr-quake. it doesn't appear to work in regular winquake though, but it does work in tyr-quake which is essentially the same thing.

i've been using 32mb of ram all the time and it works fine.

i'm posting this here incase Headthump is having the same problem, so he can check this post out... 
I'm afraid the e-mail didn't come though. 
is you're email the one listed in your profile here? 
Yeap, I Double Checked If It Is Correct 
That is the one. I'm missing an email today Nengt as well. It may have something to do with file size. I have a 1.5 meg restriction on things sent out on the account but have never had a problem recieving e-mails larger than that. 
Well, It Can't Be That 
because both times i emailed you, i gave a link to the url.

have you tried emailing me? i haven't gotten anything from you yet if you have... 
Necros I Sent An Email 
Did you get it? 
i replied directly, so if this doesn't work then... heh :P 
I Got Mail! 
<no topic> 
I Had To Go Watch The Daily Show 
Hence the odd time delay. 
aguire: what is the theoretical maximum amount of brushes your qbsp can handle?
These brushes would be very small (roughly 8x4x16 units, not necessarily rectangle) and mostly detail type stuff, not sheer size of the map type brushes.

what other problems can crop up from having a lot of detail type brushes?

say the actual map size is actually small to medium in size, maybe 1.5 times the size of e1m1, or like my nesp16. 
Brush Limits 
are in TxQBSP 64k and TreeQBSP unlimited. I've recently tested with one of Mike Woodham's maps that had 32k brushes and neither of my compilers had any problems with the brush amount.

However, having extremely many brushes will significantly increase compile time and increase the risk of float errors piling up and finally create leaks, clipping errors and HOMs.

Also, normally it's not the # brushes that kills the large map, it's the resulting # clipnodes, nodes, leafs, marksurfaces or other objects that have limits, either in the tools and/or the engines.

Not to mention vis processing times when vis leafs/portals go through the roof ...

I'd suggest that you start easy and check often that the tools/engines can still handle it. 
Re: FuhQuake 
I made a brief test of your ne_lend_q1 map with the latest FuhQuake and it seems to have problems with it, even with -mem 64.

I checked the source too and it doesn't seem to have done anything at all to the limits I've fixed recently. That may explain why it can't deal with your map.

Even FitzQuake 0.75 has problems with it if you e.g. set -heapsize 29000. After loading, the engine starts to choke, consumes a lot of virtual memory and then finally aborts with an error message.

I hope metlslime can find a cure for it, it's a bit tricky. 
Quake Game Skill 

I' about to finish my map, and I started to add some monsters... but in order to play several game skill (easy to nightmare), what are the requirements when adding a monster entity in the map ?? ... I mean, do monster entities need a special field to specify clearly the skill they are involved to ??? Or does the game upgrade monsters aggressivity itself ???

You can use the spawnflags to control at what skill levels an entity appears. On Nightmare skill they automatically have a more aggressive AI. The other skill levels all use the same... you just get more difficulty by having more monsters appear in those skill levels. 

OK, thanks, I have to add a value to spawnflags field... but what are theses values ?? I think easy skill have its own value, medium as well, etc.. How these values are used ???

I think monster agressiveness varies a bit between easy, medium, and hard. 
JPL Again :) 
I'm not sure what editor you're using but in Worldcraft, setting flags is a fairly simple affair. Screenshot...

Look for something like that. 
I'm currently using QuArK 6.4, I'm sure that spawnflag is visible in the entity description, but I can't verify now what are the avalaible fields (I'm currently at my job office, not at home...). I don't know if skills can be set like Worldcraft, or if the required value are directly number (0,1,2 or others... ) 
Let you know,
I've got it up and running without any problems. It slows down in the first large open area, giving the Tenebrae Crunch, but other than that it plays smoothly on my GeForce2 MX series. Officially this system is 733 mhz (pIII) but it actualy clocks substantially better than that.
I have to run in a little bit but I'll be able to give you a full e-mail update this evening E.S.T. time. 
you're playing in tenebrae? jesus crap i didn't think that was possible!

aguire: i don't know what you mean, when you say FQ has problems with the map if you only allocate 29000kb of ram. if you allocate more, those problems vanish.

it also perplexes me why fuh can't load the map while normal glquake can... the original is better than the port? hahaha :D


and yes, i do know about the clipnode limits. :( i've run into problems with that already. although, that's not a problem because all you need to do is throw clip brushes on top of the detail geometry and you're fine.
i don't know about Nodes and leafs though...

and, if you have a big map, with an upper area that mostly is there for the sky (think, beginning of nesp09 at the top), if you clip the whole area, does vis not have to do calculations for that area or no? 
Skill Settings 
I think monster agressiveness varies a bit between easy, medium, and hard.

That's a little known fact. The time delay between attacks decreases each time the difficulty setting is raised, until you get to Nightmare where there is no delay at all. Try it. On Nightmare, if you stand under a ledge where an ogre can see you but not hit you with its grenades, it will keep firing indefinitely with no pause between each shot.

AFAIK, the only other difference between skill settings is the speed that Vore balls fly at. They fly faster and faster for each incrementally more difficult skill setting, until they are traveling faster than the player on Nightmare.

So, if you know how to exploit it -- and if the map is built in such a way -- Nightmare can actually be easier than Hard. 
The delay between attacks and the voreball speed only changes on nightmare skill. On all the other skill levels they are the same.
Exception is Chthon that has only 1 health on easy and 3 on other skills, and his fireballs try to lead the player on hard and nightmare.
Also, on nightmare monsters don't go into their pain animations more than once per 5 seconds 
I can't see any reason for any program to start consuming all virtual memory just because you manually haven't figured out the magic limit yet ...

As for clip brushes, they can only reduce # clipnodes, they won't affect the visible hull at all (and therefore cannot help vis). 
there's no way to tell regular vis to 'forget' about processing a certain area? would that be doable without changing the engine? 
The Only Way 
I know is through manually changing detail world brushes into e.g. func_walls. It's without doubt the fastest way to significantly reduce vis leafs/portals, but it has some drawbacks (e.g. no shadow casting). See my ToolTips for more details.

Newer games have e.g. area portals or explicit detail brush attributes that help reducing vis times, but I believe they also need careful planning to be used effectively.

In theory, you could change qbsp's portal handling to automatically cluster small leafs to help vis, but I don't know how to do that. I'm not entirely sure that it wouldn't require specific engine support either. 
well, it was worth asking anyway ;) 
That problem is easily solved by placing a simpler poly go version of the func_wall object inside the func_wall to cast the shadows in its stead. 
A Regular Brush Model I Mean 
but then you get like double the r_speeds... O_o that can't be good! :) besides, i don't really like wasting a bmodel slot for just details/reducing vis time when it could be better spent on a cooler door or something like that. ;) 
remember you can group all your func_walls into one within certain limitations. 
Did you get my 2nd attempt of the buzz73 report or was it also lost in SpamFilter County? 
I Just Double Checked The E-mail Account 
It isnt showing any new messages from you; though it to be honest a lot of people I know have been having trouble this week getting their e-mail. I finally got Necros' and a few others last night.
Also, I don't filter the e-mail for any content except for virus protection though I can see how a filter may interpert buzz73 as a gratuidious drug reference though at the time I was looking for a simple word at the beginning of the alphabet for the file name.
I'll e-mail you and see if that goes through. 
Strange Message In Console.. 

Thanks for those who helped me yesterday about monsters' skill settings: I found the stuff in QuArK.... :))
Now, my map is 99% finished, and a strange message appeared yesterday night in the Quake console at the game start during a building test: TOTAL_CHANNELS == MAX__CHANNELS ... What does it mean ??? I use FitzQuake0.75 and it's the first time I have this message (never encountered it before, even with other engine...). Does somebody know what's the problem ???

that means you have too much sound sources in the place. try either removing some monsters or ambient_sound entities... 
hmmm... I didn't set ambiant_sound entities yet... it can only comes from the default ambiant sound, water, lava, monsters, and func_door...
Does it mean the game is able to crash ??? Or is there a method to increase channel number to avoid this problem ?? 
it won't crash afaik, it'll just print that message on console until you exit the area with that many sounds... 
When i load my map in glquake i get this error, 'AllocBlock :full'
any ideas? 
hmmm i forgot how i fixed that, but try -heapsize 32000 first 
-heapsize 32000 didn't work. The map loaded in winquake, but it looks like a brush goes on to infinite. 
OK, I think it's possibly linked to the last hall, because it appears only once at the beginning of the game (starting from a test_player_start). I will check all entities' sound settings (if a field exists) to make sure nothing is missng...
Just one other questions: what is the effects during the game ?? I mean, I've noticed nothing while playing... so maybe this message is just informative ... and it's not usefull taking into account this message ....
yeah, it's like info warning, the game shouldn't crash 
hmmmm, well rebuilding problem brush should do then... 
Thanks, I'll check the stuff this evening, thank you for your help.... I was afraid the problem was destructive...
Thanks again.. 
I've got your email and I've sent mine for the 3rd time, this time without the buzz word in the subject. 
Take a look in my Q1 ToolTips document in the Engine Problems section, you'll find it here: 
Just ignore TOTAL_CHANNELS == MAX__CHANNELS. It shows up in lots of big maps with a buttload of flames and torches because of all the fire sounds. (see perssp2, rpgsp1, etc.)

When you reach the static entity limit, that's when you need to start worrying. :) 
Thanks, I know how to look for now... the final hall is quite big and numerous torches are used (at least 24 if I remember well).. if I add lava, monsters and buttons and doors, total sound number must be quite bigger than the game can support...
Just a precision, what is the TOTAL_CHANNELS maximum value allowed ??? 
I think it's 8. 
hmmm... does it mean that only 8 different sounds are allowed in one closed hall (for example), or does it mean that only 8 sounds are allowed in a full map ???
As I said previously, I've seen no effects during the game... So what should be the effects on sound "rending" during the game ??? 
It can't be in the entire map so I presume it means within audible range at any one spot. I forget now how "audible range" is defined in quake but I think it is a matter of a certain number of units distance from the source.

Probably during the games some of the sounds don't play but if it's just the 9th flame sound that cuts out your hardly likely to notice. 
So, if I understand correctly it really doesn't matter: only the 8 nearest sources can be heard, and the others are "switched-off"... Am I right ??? 
I Think That's Right 
bit I'm not sure exactly how sound channels work or how quake prioritises monster sounds over ambient sounds for example. You might learn more from the QC spec 
AquiRe It May Be Butting Up Against The 
1.5 meg size e-mail limit on my account. Previously, this has only effected the size I send out however, and not what I recieve. 
After a quick read, it seems to detailed only the basic C functions and not the entire engine architecture in itself... sound function can be found, channel max value is 8 for entities, and channel priority is not described (I didn't find the stuff...)
Anyway, thanks for the informations...
It can't be the size; it's just four kb. I've now sent it a fourth time. Do you have another address I could try? 
it's funny... like three days later, i got the mail undelivrable message for the second email i sent you, HeadThump. your mail is funny. :D 
Did you get my e-mail regarding the HOM effect? Looking at the posts, lately there seems to a problem with e-mails. 
Holy Moly 
Does this email thingy work at all? Mike, yes I've got it and replied, trying again right now.

It's a conspiracy, I tells ya ... 
Total Channels 
I have *never* noticed a sound problem while playing any map that exceeded total channels == maxchannels. 
You Think That Is Weird 
I've discovered a second account I have under instead of It had a back log of two years worth of e-mail and a handful of legitimate mail from friends. Absolutely mind blowing. I had no idea it was there until I looked into my Window resources under Outpost and saw I saw the name. 
Hey, Give That Address A Try, AquiRe 
It does work. I e-mailed my main account. 
Fifth attempt here we go, this time to alan643 instead of alanr643. 
I Didnt Recieve It 
This is really raising my blood pressure exponentialy. I am noticing many of the design flows and eyestabbing aesthetics (grotesque in its cloy toyishness, like the Volkswagon Bug)of my msn client that I have learned to gloss over since I have had this account. I'm going to grab a beer and come back to this later. Anyone have any recommendations for free e-mail account services? 
it's the most popular thing around... 
Sixth Attempt 
This time directly from my MyRealBox account to alan643. 
It's There! I'm Actually Looking At It 
A miracle! 
Thanks AquiRe That Helps Alot 
There are more off grid vertices in the map then I realized. These are usually caused by the method I use for cutting brushes. 
Got it!

I have played with Bob a bit and cleared the leak-through-solid-brush just by Brush Merging. But the invisible brushes remain (each connected with badly aligned brushwork) and one superb HOM, which because of the ceiling being a mirror image of the floor, really is like looking in a mirror.

I will probably just 'square-up' my problem brushes, or maybe put a door there!

Thanks for your help. 
... the entrance to a cave where Willy the Spider lives! 
Spagetthi Code 
Wanted to add a new monster to Quake1.

Made a rat.qc - changed some things in the ai.qc - and added a rat.qc to the progs.qc

Now the console tells :
callo 1453
ai.qc : ai_run
rat.qc : rat_run1
monster_start_go : nofunction
stack overflow

I tried to set the rat.qc on my homepage, but it won't come through.
Is it really that hard to put in a new monster
and not substitute one??? 
well, no too. if you know what you're doing, it takes about 5 minutes to get a new monster going just by cnping another monster's code.

just make sure you change the name of all the functions to new ones, which i think you did, otherwise you wouldn't have been able to compile it...

i'm not sure, but this looks like something i got earlier... are you trying to have attack functions alongside ai_run functions? i ran into this problem with the gaunt monster i'm working on with kell. it looks like there's too many function calls in the same frame, so you might have to write your own movement code, and put in the shooting code with it like i ended up doing. it leads to lots of writing, sadly. :\ 
What compilers are you boys using? 
Re: Q 
aguiRe's txqbsp + vis, and Tyrann's Tyrlite. 
all of aguire's utils 
I rewrote the code for the dog and the enforcer. That was relatively easy, as all the code is already there.

Adding a monster is changing the code, so I am hopefully comparing the rat's code from
But as they are both different progs.dat, I have something as a rat.qc This has already all the rat's actions in it, but then the ai.qc starts recalling the rat.qc...
Frikqcc gives an outcome, but doesn't spawn the monster_rat. So I'm compiling, but it's kind of a hard carrot for me poor coder. 
I was asking necros + madfox what qc compiler they were using. 
I Beg You C+code? 
Frikqcc don't sound compiler?
then my spagetti codes macaroni... 
LTH: i use proqcc. i know frikqcc is newer but they are all the same to me. :P it's not like it takes five days to compile code, so speed increases don't mean anything. ;)

HeadThump, Inertia: how's the testing coming along? 
Q1/Radiant/*Water Fux0rage, 
Dunno what could be causing this, but for some reason water textures aren't making it to my .bsp files. The .wads are compiling properly afaik (in other words, all the other textures of the same .wads as the water textures appear in the finished map), but no water textures are present. The only thing that I could come up with is that the .jpg files used in Radiant to represent the textures aren't capable of using an asterisk (*) in the filename, but use a hash (#) instead -- but that wouldn't affect the compile, would it? 
Hey Necros, 
Though the vising isnt completed, its smooth enough now for a second run. I wasn't sure if I had to cheat the first time because of system crunches (scags being able to catch me on the fallow through spit when they normally would not) or because it is a difficult level. Probably both, but I'll get a more specific update before I crash in bed around 1:00 am EST tonight. 
Biff, It Cetainly Would 
I keep water, teleport, lava and slime textures in a pak that do not have the '*' in front of the name, and a seperate wad of the original Quake textures with the asterik that I use for compiling manually.

When I'm ready to compile, I open the map with Notepad and replace 'water1' for example with '*water1', save and then compile. 
The First Pak Is For Use With GTKRadiant 
Ahh, Cool. 
Thanks, Thump =D 
The version of Mapcon that I use has a -chars switch that automatically converts the # symbol in texture names to *. That's version 1.3.0. 
Making Decent Rocks In WC 
I'm trying to add rocks to an outdoor section of my map, and my attempts so far are really bad looking.

any advice for a rock n00b? 
Sound Problem, And More... 

I fixed my TOTAL_CHANNELS = MAX_CHANNELS , but now, near the same location (in the map, during the game) a door sound is not audible... The func_door entity have its sound effect set, but it can't be heard during the game: what's the problem ???
I also have a PACKET OVERFLOW<b/> message apearing during the game... what's this ???

Take A Look Here

Several of your recent problems seems to be listed there. Packet overflow errors generally means that you have too many things happening at one time. The server part sends too many messages to the client part which overflows.

This can cause missing sounds and entity flicker; the engine is choking.

Running fast/fullvis on the map (so less things are visible for the player) will probably help, but might not cure the problem completely. 
Thanks a lot for the link... it gives me some cool and usefull informations...
About my problem, it seems that packet_overflow and sound disappearance are linked... Well, I know where to look for now: there is too juch entities in this area... grrr... I will make some tries reducing its number, hoping it solves the problem... So, the big challenge will be now to preserve the map difficulty I'm looking for... hmmm...
Do you think it will be helpfull to finish the map without any monsters (removing all of them if necesssary), and adding it gradually to avoid this kind of problems ??? What would be the good method ??
More Stuff 
About my problem, it seems that packet_overflow and sound disappearance are linked... They usually happen together, when you're in a really big fight with lots of corpses / gibs / nails / grenades / voreballs / etc. all in one place. 
... of course, if you were to use a newer engine... 
... I apology for my poor english, but I'm not really sure to understand what you mean.... 
Have you fullvised the map to see if the problems persist? Many maps expose these problems when not vised, so the engine must render too much.

Try also enabling the r_speeds cvar in GLQuake and check out the epolys value, this indicates how many entity polys that are visible. If too many, you might have to consider reducing visibility.

My suspicion is that this is your basic problem. You can also run Win/TyrQuake, enabling r_draworder and see how much of the map that suddenly becomes visible.

Try also a Google search of "packet overflow" quake and see what turns up ... 
Engine Refers To A Rebuild 
the Quake executable. You wont get packet overflows with DarkPlaces because entity management is handled by a higher bit extension then Quake was originally built in. So you could have several thousand models in a single level if you so desired. 

Yes, I made the try running full process (BSP + VIS + LIGHT)... and the problem remains....
So, considering all previous advices, I will try to enable r_speed cvar in FitzQuake in order to check out epolys value, but, what is the maximum value value I must reach.. some says 800, others 2000 (If I remember correctly, Vondur said that in a previous post...)... but what's the good one according to your experience???
And, if I need to reduce visibility, how can I do ??
Thanks a lot..

There Used To Be 
certain recommended values to aim for (especially in DM maps), but I doubt they're still valid today.

What I meant was to use these numbers and methods to quantify your current situation, which seem to choke the engine. When you see the numbers go down, you know you're making progress.

Reducing visibility can be done by using vis blockers, i.e. donut designs, walls etc. Think of a large open arena with many small objects (faces or entities) as the worst possible scenario for vis or the engine.

Look at many older Q1 maps and you'll see that most of them have a layout and entity amount/placement that prevents the arena situation.

I believe one of the challenges in Q1 mapping is to make interesting and fun maps while still keeping them playable in most engines. 

I did it last night, I mean trying r_speeds value... after a full process (bsp + fullvis + light) there seems to be some very big value... As you felt, in the main big area, the r_speeds number increases up to 10000 (more or less..) I achieved to reduce it down to 1500 by an additional wall that cut the visibility....
But still remaining the problem of packet_overflow and sound disapperance... so I tried removing all monsters... packet overflow error disappear, but sound is still "inaudible"... and other problem, a big HOM problem appears at the beginning of the map while it doesn't exists before .... (and no errors/warnings occured during compilation...)
It's very discouraging to see these problems incoming while the map is almost achieved...
Anyway, I will try removing back all groups, one by one, to find where is located the problem... with a bit of luck, it can work...

Send me the zipped map+wad and I'll take a look at it. 
I will do it this evening... I'm at my job office now, and till to 17:00 ...

Thanks again for your help... 
This is probably one for you:-

I have a sealed i.e. no leaks, map of 2600 brushes. I do get several Cut_Node_Portal erros but the map runs fine in its own right.

I have a second sealed map of 600 brushes, which again runs fine in its own right.

So I import smaller map into larger map and get a leak through a solid brush when building Hull 1.

I have changed the brush concerned, overlapped surrounding brushes etc. The brush is one of many (terrain type triangles) on the 'floor' of the level but I have also added a large 'sealing' brush beneath the terrain to try to avoid the misaligned brush problems (this is not one of my large terrains!), which has been in place long before the import.

The only slightly unusual thing is that at present the imported map is entirely unconnected in any way to the larger map: I have imported it just to see how I can fit it in. I have not exceeded the world boundary - close to the edge but 32 units to spare.

If I delete the imported map (select Group and CTR X) without saving or reloading, I can immediately compile without leaks.

Bit long winded... any pointers? Anyone?

And I still have one more section to import! 
Not Exactly Any Help 
but maybe some kind of attempt to explain why it's happening. The compiler quickly translates all brush faces in the map file into infinite planes with a normal (perpendicular to the plane) that specifies direction and a distance from origin (0 0 0).

This pair identifies the plane and they're represented by float values (in my compilers 64 bit double precision). One can rather easily suspect that the more of these infinite planes there are in a map, the more risk of planes getting too close (i.e. coplanar) for comfort due to numerical inaccuracies.

I believe that this might be one reason why bigger maps sooner or later start to exhibit weird leaks or clipping errors. I know maps where it appears nigh impossible to get rid of these problems.

In your case, you have two maps that you merge together and both are terrain generated, which means many triangular faces and as I've mentioned before, this appears to be extra provoking for the compiler.

This is all only a theory, though; I can't substantiate it. Still I recommend to inspect the areas of the warnings and try to get rid of them, in my experience the warnings seem valid and should be corrected.

If you can't proceed, send me the map and I'll see what I can do. 

The build process for the enlarged map was:-

1. small terrain (honestly!)
2. then one self contained non-terrain map
3. then the linking brushes created on-the-fly in the new map
4. then the attempt to bring in the later map

Each map compiled ok on its own.

I think perhaps I will just release the terrain + one section as a stand alone 'quickie'. At least I can cram it with monsters and end up with a Serious Sam style arena fight at the end.

It seems that I am fighting a losing battle here with the limits of the tools ... I know "a bad workman blames his tools".

Trouble is, time is tight and I go in three weeks.

You're welcome to have first look as you have helped a lot over the last few weeks.

Thanks again. 
One Thing I Would Try.. 
is moving the imported section nearer in than 32 units from the edge. I seem to recall having problems myself with brushes that close. 
... but no good. I am working with very little room left in the 4096 world-space as this has become a very 'flat' map. Ho hum, start map and three small additional maps then.

Two general questions:

How many units from the player can a generated sound be heard? I do not want the player to hear monsters being teleported in so am wondering how far away from the spawn site I need to set the trigger.

Can I switch off the monster-spawn sound from within the monster's .qc file? I cannot find a reference to the spawn .wav (r_tele5.wav?) in the .qc but has anyone tried this? Maybe it's hard coded in the engine? 
Tele Sounds 
The function that plays ALL the teleport sounds is play_teleport() on line 282 in triggers.qc, so if you wanted to make ALL teleports (monsters, player) silent, you could just remove the contents of that function. (Or at the very least, comment away line 299, you might want to keep line 300 though...) 
Tusen takk!

(sum total of my trip to Hemsedal last Christmas) 
Wait A Second... 
Isn't there a "silent" spawnflag on the teleporter? 
yes, but that only gets rid of the 'humming' ambient sound that trigger_teleports emit. 
Teleport Sounds 
Zerst�rer has a spawnflag for truly silent teleports. 
My last map suddenly run out of light.
What can I do?

142entity - 130lights
GetFileSpace : overrun 
What Light Are You Using? 
if you're not, i highly suggest using aguire's light util, because it seems you have hit a limit which aguire's stuff probably removed. 
Aguire's Light Tool 
I deleted 16 torches, and the problem was solved. Could be something in the animated light count.

Never had the message before. 
If It's My Light 
tool, it must be a very old version < 1.14 (Aug 2002). Later versions have another more informative error message. 
Q1 Tools Update 
at . Main features are new attenuation formula (delay 5) and improved additive minlight in Light, engine matched validation in compilers and a new GLQuake engine especially made for mappers. Please also see readmes for more details.

Any comments are welcome. 
Gtkrad 1.5 
I'd like to start using GTKRadiant 1.5 but turning off 'Freelook in camera view' doesn't seem to work in the Preferences. Is it just me having that problem? 
What are the mapper specific features in your version of glquake? 
thanks man, this is awesome stuff.

first of all, the engine is a great idea. there are times when every engine i try to use packs up and leaves. i doubt i'll use it for much playing, because it doesn't look like you've made it any more efficient than the regular quake, and i doubt i'll make a map specifically for it either because of that, but this should help immensly with testing and such. at least now, when i hit a limit, i can keep building and testing while i try to figure out what's wrong as opposed to just stopping and searching and waiting and such. :)

also, i'm a big fan of delay 5. i didn't use many delay 2 lights in my maps after i started using fitzquake, because the overbright feature would make the lights way too bright, and i realised that this must be what it looks like in software... being able to specifiy a max light limit is great, and Kinn rocks hard for coming up with something like that. (but thanks for implementing it in your tools, aguire)

i haven't really experimented much with the new minlight setting though... i try to stay away from minlight as much as possible. :P

cheers on excellent work! 
like he said in the readme, there aren't really any features for mapper, the only feature is that almost all limits that would normally crash quake before even letting you see the map are bumped way up (ie: edicts from 600 to 2048)

it's not really meant for normal play or for mapping specifically for. 
Fuck, Triple Post... 
one thing i forgot to mention, Aguire:
don't name your engine glquake.exe, because it's not meant to be a glquake replacement. glquakebjp is perfectly acceptable ;) besides, it makes unzipping it a pain, because now i have to unzip to another directory, rename then copy it into the quake directory. same me some steps, eh? ^_^ 
I have experienced the same problems. I've also reverted back to using the beta 1.3.11 because I find the changes in the interfaces of the newer versions iratating and counterproductive to what I try to accomplish. 
The "GLQuake Mapper version" just means that its focus is on loadability and viewing of large troublesome maps.

Since mappers at one time or another create maps that indirectly (e.g. via leaks) or directly exceed normal engine limits, I hope this version is of special use for them.

It's not meant as a replacement for FitzQuake or other engines, just a complement. 
I toyed with the idea of making up yet another engine name but decided against it, since all my other tools also kept their original names.

Since I don't plan to make that many more improvements to this engine (unless someone finds a reasonably valid bsp it can't load), I hope it won't be too cumbersome with the file renaming.

I'm glad you like the tools, let me know if you have problems with them. 
Thanks AguirRe.. 
Sorry I didn't spot the isn't in the zip. That sounds very useful.

Headthump..I fine with 1.4 but I definitely need to turn freelook on. I've reported it as a bug. 
Your Huge Map 
Day of the Lords was one that I tested the engine capacity on. Sometimes when compiling that map you get a leak near the beginning of the map.

The resulting bsp is normally not loadable in any engine, but now it is. Just fly around and inspect the whole outside of the map when it's not removed by the compiler. Then load the pts file and you can find the leak spot immediately.

Even the old SoE map soe2m4 which was mega huge before Tronyn decided to split it can now be loaded and inspected for the leak trail.

Maybe the engine can also handle the upcoming project that Tronyn is working on. 
I've Noticed 
with 1.4 the default settings uses the QeRadiant standard 'delete - insert' for the zoom-in, zoom-out instead of the 'shift mouse drag' that is second nature for me now. Changes like that are a bit irksome though I do have 1.4 set up for Half-Life mapping. 
Yes I had that problem intermittently - strangely I got it to compile (without a leak) by slightly moving one of the entities in the beginning outside area. Not sure why that would work other than perhaps reshuffling the entity order in the map file. Where is the leak?

HeadThump-shift RMB drag does work in 1.4 in the 2d windows. 
It's The Same As 
we discussed before; the leak is in the rocks to the left of the entrance cave in the open area.

When inspecting the leak, it seems to be one of those that there really isn't any explanation of; all brush junctions seem OK (although a bit complex) in the area. By manipulating one of the brushes, the leak goes away.

My only guess is that it's the size of the map that finally puts the numerical errors in the float calculations over the edge. 
Hi dude, I'm glad you like delay 5 (and massive thanks to AguiRe for implementing it in his light program). What I find looks awesome is to use it in conjunction with "wait 2", e.g. for a nice, dramatic walltorch, try:

light 600
delay 5
wait 2 
I wated to synchroon func_trains, as I am using 5 related through eachother.
Found it somewhere at 3D-Inside, but lost it.

Can't find it...again. 
Gtkrad Keys 
Anyone know if it's possible to change the keyboard assignments for gtkrad 1.4 upwards? Specifically I'd like to change the freelook camera move arrow keys to a wasd set up. 
you can create your shortcuts.ini file with your key bindings. this file should be placed in your q3/rad1.4 dir. 
but..the freelook controls seem to be really buggy once I've changed them. They work fine using the default arrow keys but with a new set up (actually esdf) sometimes they work, sometimes not, sometimes the key off doesn't work so the camera carries on moving. I've changed the other shortcuts that clash. Any ideas? 
not really, cuz i avoid using freelook. sorry.
i use arrows and ctrl/shift modifiers to move in 3d view. 
I agree! (although I use RMB + ctrl)..but non-freelook in v1.5 (Spog's q1 branch) doesn't support it. If you feel like it you could encourage Spog to add support by commenting in this bug report:

See also: 
make sure caps lock is not on, because that will affect letter keys.
also, the key releases for the arrow keys are bugged as well. if you press up and then 't' or something that brings up a window, the view will continue to move forward, even if you let go of the forward key. you need to close the windows and press the same key to stop it. 
Where Can I Get Q1 Textures? 
Where's the best site for Quake 1 texture sets? I've tried searching google but it's all QUake 3 stuff coming up with the occasional Q2 bits. 
Look For Links 
in the Definite WAD Collection thread: 
Texture Dimensions. 
A quick texture question. I have a texture that's 128 x 8 pixels, and it crashes Winquake. Keeping the width at 128, what's the smallest height for it to be valid? 
Textures can't be smaller than 16 pixels in any direction. 
I'm making a Q1 terrain map. All goes well until I'm adding the last sections of detail and refining gameplay when:

TreeQBSP v1.96 -- Modified by Bengt Jardrup

Input file: C:\quake\id1\maps\
Output file: C:\quake\id1\maps\kellmet4.bsp
---- LoadMapFile ----
*** WARNING 06: No info_player_deathmatch entities in level
Title: "Blah"
18989 faces
3486 brushes
270 entities
39 unique texnames
271 texinfo

Building hulls sequentially...
Processing hull 0...
---- Brush_LoadEntity ----
*** ERROR 32: Face coordinate out of range (100000.000000)

1 warning

Elapsed time : 0:02

Peak memory used : 3.5 MB

The terrain mesh is 32x32, though I have a smaller section to generate separately and bolt on to one of the corners.
The terrain squares are 128x128 units. I was using 256x256 but it looks cack and makes traversing the terrain awkward.
There are three large bits of architecture on the terrain and several smaller ones. All of the large bits contain pseudo-curves ( domes and pipes ) only some of which I was able to make into func_illusionarys.
Compiling worked fine up until I added just a few more brushes for a small chunk of techy architecture and *wham*...above error.

I suspect I simply have too many surfaces in the map now and will have to prudently chunk some of my detail.
Is this the case? 
Func_illusionary Vs Func_wall 
You do know that you can use func_wall instead of func_illusionary if you want to have collision detection for it but not block vis, right? I dunno why you were only able to make some stuff into func_illusionary, but if it's due to lack of collision detection then that might help.

Err but I think you knew that. 
I don't think I've experienced that error before, but I've seen it mentioned at QuakeLab . The original error message was CheckFace: BUGUS_RANGE ....

It appears to be a face that the compiler thinks is too big. I can't find any limit that indicates that there are too many of anything.

If you wish, you can send me the zipped map+wad and I'll take a look at it. 
RPG: yeah, I know the difference. I just prefered illusionaries in this case because of the collision thing as well. I can then build simpler, rectangular solids inside them ( out of clip or black ) to approximate collision.
By 'only some ' I meant, there is some pseudo-curved stuff that needs to be solid to cast shadows, or interiors will look floodlit :/

aguirRe: thanks, I may send it to you. I hope it is something to do with size of a face rather than total number; the map's almost finished and culling superfluous detail always makes me anxious.
I'll have a look around the map when I get home and send it to you tomorrow.

Thanks for the info guys. 
Thanks Czg 
that's done the trick :) 
Kell, Do You Use Gtkradiant? 
you can run the map through the brush checker and it usually gets rid of busted brushes. 
Be Sure To Back It Up 
Last map I brush checked like that started leaking like a sieve. 
mmmm, yes. that tends to happen... but i don't think the map would have started leaking after the check because it basically does what qbsp does. when qbsp gets wierd brushes with duplicate planes and such, it tends to mutate them much in the same way the check does, so it's likely that qbsp would "make" the map leak as well. course, there could be some exceptions... (aguire, any input?)

the nice thing is that after the check is done, it selects all the modified brushes, so you can check to make sure the modifications didn't leak the map or somesuch. 
Entirely My Fault 
for including my 'itty, bitty' brushes in the hull. Oh well. Live. Learn. Get Luvs for those messy spills. 
when qbsp finds duplicate planes, planes with no normal etc, it just drops the plane, it doesn't change it.

What might happen though is that when this particular plane is dropped, the brush isn't closed anymore (i.e. doesn't form a closed volume) and this isn't good.

In the latest version of my compilers, I've added a check for simple axial brushes (i.e. cubes) being closed. I haven't figured out how to check non-axial brushes.

PuLSaR actually had this issue in his upcoming map and when fixing it, the # clipnodes went down pretty much and in a big map this might be crucial.

I've also added some info regarding this in my latest ToolTips. 
Re: Face Coordinate Out Of Range 
Well, I had a very recent back up copy of the map and compiled that successfully - error gone.
The last brushwork that I was adding before the error, involved some cloning of existing brushes ( to get the same variations of texturing on the faces and lock the brushes at the same height; they were wide steps ) and I started to use Radiant's edge manipulation. As is sometimes the case, the brush disappeared instantly, indicating an invalid of some sort.
I ran bobtoolz brush cleanup and it removed the offending step straight away.
Thing is, when I continued to work on the same feature in the same area, I created and deleted some brushes myself, then CTRL+Z'd. When the brushes returned, some of their faces were white, like a point entity. No texture. I couldn't change the texture afterwards either.
So a combination of Radiant and my sickly HDD probably cause some mutant brush error that I couldn't see properly in Radiant to fix. Even brush cleanup didn't recognise it.
So anyway, not entirely sure what the problem was, but it's gone.

The map's coming along nicely btw, due in no small measure to aguire's bsp coping easily with my huge terrain mesh. Thanks for that :) 
I've added coordinates to that error message, should it appear again. 
Brushes Disappearing In Radiant 
I remember having trouble with brushes that were edited in Radiant and then disappeared. That was back in the olden days, and David Hyde used one of my maps as a reference for getting MapSpy to detect those brushes. Even though it's targeted at Q2, Mapspy can be very useful in tracking down rogue brushes of that sort. It outputs the brush number, which makes it pretty easy to track it down even if the editor isn't displaying that brush. 
Hey guys, I'm new here - glad to see there's still people who mod for Q1 ;). Anyhow here's my question; do Hexen 2 maps require special compilers designed specifically for them or can I use ones for Quake1 as well? I tried to use aguirRe's bsp and light compilers but light gives me this error for one map (I used it for another map and it seemd to light fine):

************ ERROR ************
LoadBSPFile: odd Model lump size

while bsp gives me this error for any map I try to compile:

************ ERROR ************
Invalid brush plane format on line 14

This is line 14 in the .map file:

( 3630 525 -105 ) ( 3630 524 -105 ) ( 3960 524 -105 ) rtex066 0 0 0.0 1.000 1.000 -1

Meh, I wouldn't be trying this if the people in the H2 mod scene didn't amount to my hand's digits :(. 
i'm afraid you have to use h2 compilers only... 
Thought So 
Thanks, Well I'll just be off to bug the dude making NewHexen, he's done some pretty good stuff with both the compilers and engine so far.

I may be back! ;-) 
has more hulls than Q1 (5 or 6 I think), so my utils won't do I'm afraid. It appears to use the same bsp version number (29), though. I've never tested anything with H2 maps (I don't have the game either). 
Hexen 2 
I looked into Hexen 2 stuff a while back... yes, you do have to use the Hexen 2 specific compilers, and unfortunately (when I looked, at least) they're pretty basic and didn't include all the fancy things we've come to expect in the updated Quake tools.

However, I last checked something like 2 years ago, so perhaps someone has released some modified tools since then. 
Well they are still rather basic, although we do have colered lighting and a few other options like minlight, fade and range that's really all.

Maybe I can get Korax to look and see if he can add more options to them. Which compilers that are out are the best right now? I can only think of Tryan's and aguiRe's tools. 
want to beta test a q1sp? an engine that supports external texture replacement is recommended (fitzquake, tomazquake, ...?) not necessary though. 
Gamma Problem 
Several people seem to have problems setting the gamma (brightness) in my new GLQuake engine. Just add the -gamma x command line option, where x can be e.g. 1.1 or any float value that gives a good result.

GLQuake only sets the gamma at startup, so it doesn't help changing it in-game.

This information has also been added to the readme. 
That Engine Is So Useful! 
helped me load a map that was over the limit on marksurface, clipnode and lightmaps. :D 
I'm Glad To Hear That 
necros, thanks! 
Necros, The Same Level? 
Did you get my e-mails from last week. One of which was quite legnthy though I don't know how useful it may have been. 
i hope you backed it up...

the last email i have from you is dated apr30. :\

did you get the reply i sent on the 30th? 
I Found The One Dated May 3 
I've just re-sent it.

I believe it to be the lengthy version. Last dated e-mail I have from you is dated April 28. 
I Also Sent A Note 
about having difficulties with the demo file play back, and it may need to be broken down with Keygrip due to the legnth -- or just redone from the start at a quicker pace perhaps. 
thanks for that. there was no demo though... 
Should i have an email thread where people can ask each other whether they recieved various emails? It seems like it would get a lot of use, considering the last few months... 
Just add a private messaging feature so people can use that rather than emailing each other...

Or don't, because that'd be a whole lot of work and not really necessary. I seem to be volunteering you for a lot of work lately, feel free to tell me to get bent. :D 
I think that would be a really great idea. The conduct of e-mail in these past few months has been unbelieveable. Necros, I'll do another demo run of the map tommorow night (tonight I am one tired little Quake Guy). 
alright, thanks a lot. i appreciate it. it's been hard to get beta testers lately. 
I was joking. Just get email that works! 
File Hosting 
Ok, my map is ready to be unleashed on the world, but being a noob I don't have access to any sort of file hosting.

It's a 6 meg zip. Can anyone recommend anything? 
Ignore Above Post 
ignore the above post - i've sorted it. 
it was worth a shot 
Oh Bugger 
Sorry, it turns out I haven't sorted it at all. Ok, I know this might be a bit of a stretch (being new round here 'n' all), but would anyone here be willing to accept a ~6 meg email attachment and stick it on a server temporarily until I get some hosting sorted out? 
Private Messaging Feature 
Then we would see a lot of posts about "did you get my private message?" 
Well, It Could Get Ugly 
But when has that stopped any of us? 
Hosting Problem Solved 
To reply to your post in the bastion thread - what are marksurfaces exactly? 
are contained in one of the many data "lumps" that the compiler and other tools put in the bsp, you can see the amount in the bsp summary at the end of the compiler log.

I don't know what they are exactly, but they're probably related to the faces in the map. Metlslime explained more about them earlier in this thread.

In your bsp, the amount is above 34k and most Q1 engines cannot properly handle more than 32k. There seem to be some fuzzy margin that the amount can be exceeded by without causing obvious problems (like crashes), but I don't know how large this margin is.

I know for sure that exceeding the 32k limit can lead to engine crash. In my engine, you'll get a warning when loading a bsp that exceeds certain limits, e.g. the marksurfaces.

I can't say that you'll have to do something about it; other released maps have exceeded this limit and still seem to work. I only mentioned it because some players seem to experience strange engine behaviour while playing your map and this is one possible cause.

I actually blasted through the entire map in god/quad mode as brutally as possible while running the engine in debug mode to see if anything bad would happen, but nothing did. Only packet overflows, which wasn't very surprising.

The gameplay *was* a bit insane at places. I fear that I might not make it through the later parts alive without cheats ... But I'll try! 
Thanks for the info. It seems that marksurfaces are a bit of a hit and miss thing.

Also very encouraging to know that the map handled a god/quad blast through, especially now that the monsters produce even more gibs. :)

The final area is tough, but search around for a 666 (easy to find) and a quad (hard to find). 
Thanks for your help a few weeks back -- I finally got the time to take your advice and (click my heals) that thing is finally sealed. A few days working on the texture alignment and it'll be out the door. 
Quake 1 Texture Sets 
Where's the best place to go to look for Quake 1 texture sets?

I've stuck with originals and Q2 textures, for now, but I want something else and preferably with some kind of preview which is hard with ftp sites like

So where would you guys suggest looking? 
check out this thread for texture sets: 
i tried to watch the demos, but they refused to load. it looks like you used DP to record them? so i downloaded Dp and tried again, but still no luck. what should i do? 
That's Odd 
yeap, I used DP for its effecient rendering -- that's a whole heapin' lot of polies there.

I believe I know the source of the problem. I checked out my hunch; not only is dark places demos incompatable with older versions of Quake (thus the problem using KeyGrip earlier) but versions of DP are incompatable with one another. I tried the demo with a slightly older version of DP and it didn't work,

Here is the thing. Lord Havoc has neglected to update the site info in some time, so the latest build showing is the one from December. This link will get you the newest Beta which I used for recording. 
Efficient Rendering. 
well, that worked, thanks for the demos man. really helpful! :) 
Recommended Map Utils For Quake? 
What are the "recommended" map compilation utils for Quake maps these days? I am using wqbsp, rvis+ and tyrlight, but I keep hearing of some newer utils. What are their advantages and where can I download them? 
i recommend all of aguire's compilers without any reservations. they are simply sooo awesome.

the qbsp is robust and handles almost any kind of brushwork
the vis has a freakin' save feature which pwns me
the light has sweet new things like _softangle for spots, delay5 to keep overbrights for going nuts and just anglesense so that lights on the same plane as other faces get lit.

i'm a fan now. :D 
I Wholeheartedly Concur 
Accept no substitutes :) 
Thanks Guys 
Your excellent maps and continuous stream of new challenges are what keep me going.

Btw necros, where *is* that new impressive map of yours that I've been waiting for? 
for the other maps in it's pack to be finished. ;) 
As A Betatester, 
I think I can leak to you that the map you are inquiring about is simply awesome. One unique situational fight after the next. 
Spagetthi Talk 
As I want to make appear a message in Quake1,
and this message is more than 4 sentences, I would like the appearance take place longer than standard time, how should I do this?
I tried delay, but this makes the trigger take place at a later time, while I mean longer.

Another not so common question:
Playing Quake in senquences one appears at the end level. After this I want to return the player back in the start level with no bossgates, and all triggers off.
Should this be:

spawnflags => kill alltargets

I'm just guessing. 
on your first question, there are two ways of doing it.

one: make a bunch of trigger relays with all the same message which have incremental delays, 0, 2, 4, 6, etc... and have them all fire in order... basically, quake will keep outputting the same message, beeping each time.
two: open the quake.rc file in pak0.pak, and store it in your own pak file. add a line that points says centertime.cfg
now create a file called centertime in the same directory as quake.rc. in that new file, write "scr_centertime 6". now, all centerprint messages will stay for 6 seconds instead of the default 2.

on your second question, i don't think it's possible to erase the player's status with runes without qc. i may be wrong though... 
Thanks For Your Answer... 
I'll try the first with four triggers and delay time, as it feels the most easy way.

By my second one I was wondering, because on the moment one plays the end.bsp I think this option was implemented by the trigger_changelevel.I just can't find the argument, maybe it is also in the quake.rc
In the original Quake I never succeeded to complete the end level without god-mode.
Then the game just start from the beginning with all counts off. 
Something That Puzzles Me 
I have always noticed in Quake that rockets/grenades sometimes pass straight through shamblers without exploding - any idea what causes this?

Also, I have noticed in some maps there are places which cannot be navigated by Shamblers, but other Hull 2 monsters can navigate them perfectly. Has anyone else noticed this and do you think these two issues are related? 
There Was A 
discussion recently about this issue and scrags flying through walls in one of the threads but I can't find it again. I don't recall any explanation was found, though. 
Found It 
The shambler thing has got to be one of Quake's greatest mysteries. The scrags-through-walls could just be a bug in the flymonster code, but the fact that all hull 2 walkmonsters share the shambler's movement properties just makes it baffling that this is a shambler-only problem.

Perhaps it really is arcane magyck at work.

Hmmm... "Quake's greatest mysteries" - I think I've coined a new discussion topic :) 
i honestly think the flying monster ai stuff was a last minute addition to quake, and id just sort of threw it together real quick. 
do you think the "shambler only takes 1/2 dmg from explosives" thing was a last-minute fudge to hopefully reduce the no. of people noticing the aforementioned missile-collision bug? 
Q1 Doors 
OK, a newbie Q1 mapping question: I have a door that consists of 2 parts, one is going left, the other is going right. I want both parts of the door to open at the same time. As of now, when I approach the door structure, one of the parts starts moving first and the other follows as I come closer to the door. How do I "link" them to open and close together? 
there is no way to team doors up.
only workaround is to make them work together out of trigger... 
If the two doors are touching, they will team up automatically unless the "dont link" (or whatever) flag is set.
So don't listen to Vondur ;) 
well, that one i'm entirely sure about...

i think it's more likely that id did that to make the shamblers more difficult without raising their health levels to ridiculous amounts.

i don't really see how reducing the damage they take from explosives would prevent people from noticing rockets going right through them... although, it could be that the warning which was in the quake manual acted as a deterent, so people just didn't use them against them, although grenades are still fairly effective even with reduced damage. 
RE: Actually 
"If the two doors are touching, they will team up automatically unless the "dont link" (or whatever) flag is set."

Err, they are touching each other and the "dont link" flag is not set. Yet, they are not linked... Hmm? 
This means you have failed the test. 
Are you the same guy that released the dnspq1 map in '98? I learned a lot about Q1 tech stuff while trying to seal that map and it was good-looking and fun as well. 
RE: Jago 
Heh, talk about a "blast from the past". Yes, dnspq1 is indeed my map. "dn" in "dnspq" stands for "Dan Naumov" (my name). It was my first map I had ever released too. I then went ahead to create 3 or 4 Quake 2 maps and 10 maps for Unreal. Then had a huge break in mapping, but am now trying to get back to it. 
What Tools Are Used For .spr Editing? 
Unfortunately the format isnt native to Wally 
the only one i know of is adquedit.
i don't have a link handy, but try googling for it.

if anyone knows any others, i'd like to know too :) 
Thank You Kind Sir 
I believe FC has a link to it on his site 
WARNING: CutNodePortals_r: New Portal Was Clipped Away 
Please go here;

Whats going on in these screenshots is some sort of noclip wall effect. you can pass through it to the other side and the map will vis. Theres no actual brush there, Just seems like the game wont draw anything past that point untill you pass that point! Below is the QBSP_LOG.txt with some errors in it. 
Take A Look 
in the Q1 ToolTips at my site, especially in the Leaks and Portal Problems sections. There are also descriptions on some of the warning/error messages, like the one you got.

It's likely your HOM is caused by small brush misalignments in that area.

If you can't sort it out, send me the zipped map+wad and I'll take a look at it. 
Film At Half Past France 
I tried installing Keygrip16 on a Win98 for tracking Quake1 movies.
As I installed the program, it said one file had to be renewed: kgdemo
I don't have this file, and can't find it either.

Using the program leads to a first screen of Keygrip and freezes.
Manual says again to renew the kgdemo, which I haven't. 
Sounds Like You Need The 
kgdemo.cfg file. If so I'll send it to you. 
Better Than Icecubes 
I would appreciate that. 
I Went Ahead And Sent It Last Night 
looking through the manual it became apparent it is the correct file. Let me know if you have any furthur problems. You may find this utility convient for Quake recam or movie production as it allows you to edit camera positions in map. The Dead On Que folks who produce it are a splendid group of people. 
Ice O Late 
I installed keygrip16. The manual said to delete the kgdemo file and replace it. But I don't understand how to replace a file by a new one that isn't there. Not at keygrip16 or anywhere.

If you say it is the right file, why does it freeze at: welcome to keygrip16 ?
Should it be the Win95 it has to be run under, and not Win98?

I could change a frozen camera, but... 
The .cfg File 
goes in a folder named 'move2id1' beneath the keygip16 folder. My version of it works fine even though I haven't loaded it since last summer.

A few other factors. Check the preferences. Make sure there is a WinQuake path listed and a dem path listed. It does need a .dem file to load correctly. The three Quake .dems will work fine for that purpose.

So if it continues to freeze, open up the kgdemo.cfg ('cfg' is for configure) in note pad and supply the necessary file paths and be sure to match them to your Quake directory and where you keep your .dem files. 
There used to be a submit link on UnderworldFan's site? 
Attn: AguirRe 
Was trying to compile my q1sp, and got the error MAX_MAP_TEXINFO, which noone seems to be able to explain, while using TreeQBSP. Anyways, I was in #TF and RPG suggested I use your bspinfo.exe, which was included with the -- which I did, but I got an even weirder error message: "c:\quake\id1\maps\ is version 1696608047, not 29"

I'm all out, here. 
Hmm, that seems unusual, my Tree/Tx compilers shouldn't normally abort on # texinfo. The BspInfo error just indicates that the bsp is corrupt, it should always contain he magic number 29 in a Q1 bsp.

Send me the zipped map+wad and I'll take a look at what's going on. 
Response To Jago Post #1975 
Jago, since I didn't see anyone answer your question, I believe a door with multiple parts may be linked by simply grouping all the brushes together. ...At least that's what I do in Worldcraft and it works. That way you don't need a trigger and door names. 
Thanks for the tip. I'll work on it ASAP. Very informative i might add. (yr page) Provided information difficult to find nowadays.

Any suggestions on a leaky map that dosint appear to have a leak in it? Say the .pts file's line goes through what seems to be a solid brush. 
i've gotten that problem very often, esp when working with natural terrain. usually, the best way to fix it is simply to remake the brush in the editor (delete, and reshape a new one) although it's long, it's usually always works. if not, try splitting the brush up into two or more pieces. 
Figgured It Out 
yeah it seems like qbsp dont like it much when brushes are misaligned. Even when said misalignment shouldint cause a leak.

Its all right there on buddy's webpage :) 
always map on the grid! besides it looking much better ingame, you avoid lots of little strange problems like that. 
Well... the grouping of door ents might be a superstition, and they could be working for me just as CZG said, because they are touching.

/me sprinkles more giblets in the pentagram around his mapping chair to appease the Quake gods. 
RE: Doors 
I will try grouping the entire door to see whether that helps. As of now the left part is grouped together (consists of several brushes) as is the right part. 
About Lift And Walking Monsters 

I'm back with my basic questions... I never used lift and walking monsters, and would like to use it in the map I'm currently working... I've read somewhere that func_train can be used, but I would like further informations and advices to use it correctly..
Is there a noble man that can help me please ??

Target a path_corner with a monster and it'll walk towards it. (untill awakened). Then target that path_corner to another path_corner and target the second path_corner back to the first path_corner and the monster will pace between those two points.

Thats how you make walking monsters (i think) 
Thank you, I'll try it as soon as possible...
And now, what about lift ?? I would like to create a lift with "call buttons" and "stair choice buttons" ??? I mean a lift called by button that allow the player choose his stair destination... Is it possible to build that in Q1 ??
Crash On Vis Program, Tree Qbsp

There's no email in file. I need to get in contact with them. It crashes on 70% in the vis program.

Overlapping Rock Formations 
Whilst researching for my next Quake map, I godded my way through Alice, to check out the inspiring level design. Now, one thing that really impressed me was a particular style of rock formation that's used extensively throughout a couple of the maps. It appears to consist of loads of overlapping boulder-shaped brushes built up to make huge rocky structures.

Here's a screenshot from Alice illustrating this:

Now, I always thought that overlapping brushes like this in Quake was a bad idea, but this is the Quake 3 engine, so I flipped on gl_showtris to see what was going on:

As you can see, the triangles that make up each boulder aren't actually getting cut up by the overlapping boulders. Am I correct in assuming that these rocks are all detail brushes?

If I was to build rock formations like this in Quake 1, would it be a very bad idea? Bear in mind that I'm not really bothered about r_speeds, I just want to get an idea of it's feasibility from a technical standpoint, i.e. could bsp theoretically cope with all the overlapping brushes, or would it just choke?

aguirRe, any thoughts? 
What do you mean by crash in vis at 70%, does it actually crash (with a dialog from the OS), or just seems to be stuck on the same position for a long time?

The former is an error, but the latter is not unusual in some maps, they just take a very long time to finish vis due to unfortunate design. The high-score I've heard so far is 550 hours (on a pretty fast machine) held by Scragbait.

Please email me your zipped map+wad with a description of your problems and I'll see what I can do. 
Brushes that overlap a lot increase processing time (the CSGFaces part in each hull), but thanks to algorithm enhancements by Tyrann the penalty is much less than it used to be.

However, if the overlapping is minor, you can get any kind of problems; leaks, clipping errors and HOMs. It's always a bad thing for qbsp to have multiple planes that are near identical. Then the floating point inaccuracies can produce pretty nasty results. 
KInn, I Forgot To Add 
that you might also want to check the Vis Issues section of my ToolTips for detail brushes in Q1. Please bear in mind that it's not any Magic Bullet, but might be useful in some cases with a bit of planning. 
Thanks AguirRe 
The reason I'm very interested in this method is because I'm planning a large scale map that will be almost entirely rocky terrain.

I'm also currently working on another map that has a fair bit of terrain in it, but it has all been constructed with the "triangle method", which is a nice safe method that gives good results, but is very time-consuming, and isn't very useful for really freeform stuff like in the Alice screenshots.

The "overlapping boulders" method seems like a really quick way of building terrain, but the map I am planning would consist of hundreds upon hundreds of brushes overlapping in this manner - I just wondered if it would be a realistic option. 
Crash On Vis Program, Tree Qbsp 
ag>What do you mean by crash in vis at 70%, does it actually crash (with a dialog from the OS), or just seems to be stuck on the same position for a long time?

OS crash on my decompiled map elmdm5 which I fixed up since then with colored lits and map fixes. It worked just fine many previous versions of vis. It took about 1 hr to compile on my p200: treeqbsp, vis(that website), and tyrlite.

Just read the relevant bits, aguirRe, and it got me wondering: just how big can I make a func_wall? You mentioned that all the brushes of a single func_wall must be in the same area, but would I also run into problems if I made a REALLY big func_wall? 
OK, please send me the zipped map+wad and I'll try to find out what's happening. 
I've no idea how the compiler (or probably more important, the engine) will handle very big func_walls. What I know is that entity brushes seem to be less efficiently rendered by the engine so you can't go overboard with them.

Also, the reason why you should keep all parts of one func_wall in the same area is that otherwise the engine will have problems knowing whether to render them or not according to the vis PVS (potentially visible set).

In any case, I wouldn't suggest relying too heavily on assumptions of qbsp/engine, you'll have to trial and error step by step. 
Big Func Walls: 
parts of your func_wall will not be drawn if it crosses too many bsp nodes, becuase each node it crosses creates an efrag. So as you walk around, you will notice those pieces appearing and dissapearing. 
When I was a less knowledgable mapper, I was working on a terrain map for Q2 using almost all overlapping brushes for the rocks -- I'm talking 26 sided cylinders clipped and skewed every which way. When I compiled with the standard tools, it took 4 or 5 days to get half way through it, at which point my computer would just shut down. It is unrealistic to build large areas of rocks/terrain in this manner.

In conclusion, the best way to the kind of map you are talking about is to build it mostly from triangle meshes. A pain in the ass, yes, but you will have very few problems. 

It seems that major problem than mine occured these night, and then nobody answer my basic question... grrr..
Anyway, I'll retry now: I never used lift (and train as well) into map, and I would like to use them for the next one. So, How can I build a lift with for example 3 stairs, with 3 call buttons on each stair, and the possibilty to choose the stair destination when into the lift ?? It's like our real world lift..... hum...
Is there somebody who knows how to do that ??

Thanks Guys 
I think I'll stick with the triangle method for the time being, until I'm ready to move on to a newer game engine.


JPL: the closest behaviour to what you require can be achieved with a func_train, but only if you use the Hipnotic QC source, or equivalent QC which allows trains to pause at each path_corner, waiting for retrigger.

Note that you won't be able to have call buttons inside the lift though, because you can't set up buttons that move as if connected to the lift.

If I were you, I shouldn't worry about trying to do complex mover behaviour like this until you've mastered the basics. Once you can make great "vanilla" Quake maps, then you might want to start thinking about custom QC etc.

Hope this helps :) 
Thanks for this quick reply.

If I understand correctly, it will be very hard to perform a complex and complete lift feature with more tha 2 stages... grr..
And as well, I need to "trigg" the path_corner before it let move the "func_train platform"... but what about the waiting field ?? Do I need to set a wait -1 to stop it ?? But if I set wait -1, does a trigger will be enough to restart the lift ?? Sorry but I'm not sure about the right methos I have to use...

You will need to use a "func_train2" in the Hipnotic QC code to make a train (lift) that is capable of stopping and starting.

In the path_corners, set "wait -1". This will stop the lift when it reaches each destination. The train will then need to be retriggered to start moving again.

Note that this is fine for movement between two floors, but as far as I am aware, if you want to give the train a choice of paths (i.e up or down), in a 3 stage lift or more, you will need to write custom QC. 
Concerning QC custom code, I'm not a very well software designer (C code is not my "cup of tea"...)... so, forget this option ;-))
I'm currently building a base-based map using 3 stairs (perhaps 4, it's not yet clearly defined) and an unique lift to reach each stairs should be great... I will see later how to build it, perhaps with an automatic one...
Anyway, thank you very much for these quick replys, and for the informations..
You could also check out the Custents pak; I think it also has some func_train enhancements. Get Custents at Fat Controller's site . Look in the downloads section. 
I'll take a look later to this link..
...for the moment, use the Oubliette method. Have the lift (train) access all levels in a continuous loop, but restrict access to all areas until certain buttons are pushed. 
This method was the first idea I had... and it seems that I need to come back to it !! Anyway, I've just started the map, and there is still long way before designing the lift... I still have a lot of time before taking a decision about what kind of lift (or several ones.. ) I will use..
Thank you for this advice ... 
Triangle Method For Terrain. 
Triangle Method For Terrain 
Using triangle method for terrain is great to avoid huge plane terrain, or cliff in a map.. As described in VoreLord related links, you build a surface using triangles.. It is very easy to build if your map editor includes a "brush splitting" tool like described... But in some editor it doesn't exist (like QuArK).. you'll so have to build your triangle-based terrain manually using pyramid or tetrahedron polygons... and it can take you a long time (you can see an example with my "ugly" bunker map.. the dune terrain was built like this..)
You will have a cool look, but there is a bad news.. it increases painfully the VIS process time..
You will so have to find a trade off between compilation timing and polygons number...
Hoping my poor experience gives you some further infos :)

quark does have a brush splitting tool? at least it did when i still used it 
Cool Beans! 
Thx im gonna Make some kickass terrain now!

Kinda off topic but who wants to recomend a good QWbot? (a bot u kill not a bot that kills for you) 
QW Bot 
I don't know about a "QWBot", but for normal quake, you can't really go past the Omicron

especially with an .ent file(route) installed for the map. 
Terrain Meshing 
The easiest method by which to create a terrain mesh is, of course, GenSurf. It's fun. Lots.
Combining it with Terragen I can create my heightmaps from pseudo-fractals and a bit of elbow grease in PSP. This gives lots of control over the look and feel of the terrain overall and also allows specific modifications to be made in respect of conventional brushwork, Vis, LOS etc. Even to the level of adjusting one/several terrain vertices by as little as 8 units z-axis by simply changing the color of a pixel.

Optimising the terrain is another matter.
Grouping the whole lot into a func_wall requires that vis blockers be constructed inside the terrain, as per the Q3 terrain method, and with the hope of casting appropriate shadows where the func_wall sadly will not.
Using a single func_wall for a large terrain is also going to shatter the thing into a multitude of efrags, which could look bad as whole rock formations blink in and out of existence due to the vagaries of your PVS. Strategically grouping pieces of the terrain into individual funcs is better and some terrain brushes could even be left solid where useful.

I'm hitting all this stuff because I have been working on a large Q1SP terrain map for the last few weeks and have hit various problems, not least of which being the estimated vis time for a solid terrain version being something in the order of a month.
The strategic func_wall method is probably what I'm going to have to resort to, unless I miraculously gain access to a state of the art processor.
If you use GenSurf, I recommend a mesh resolution of 128 units/triquad. 64 is only really possible for small, isolated bits of rocky stuff in an otherwise 'architectural' map. 256 drops the brushcount+compile time+render issues considerably, but looks extremely naff and is a pain in the arse to traverse.
A large terrain map is a beautiful thing to make, but think very carefuly about exactly what you want to do with it and if you really want to be so ambitious. I wish I'd given more thought to my landscape.
In the absence of Q1 detail brushes, even the generous limits now pushed back by current compilers and engines struggle to swallow massive terrain. Despite its name, even Quake can have a hard time moving mountains :P 
Tyrann's prog "Skippy", as I understand it is a bit like Quake3's caulk, where any surface with the skip texture on, will be removed from the .bsp, therefore causing the engine to have to draw less (something like that, if I have it right)which you would think is a good thing, so....

does anyone use it?
are there problems with it's use?
are there any benefits to be gained by it's use?

I noticed that the only version I could find is the initial version from 2000, so I thought that maybe work on it was ceased due to problems or whatever. I don't want to get to far using only to find out it was a bad thing.

Any help appreciated 
Re: Skippy 
I have no idea why Tyrann dropped development of it. Perhaps because there are no known issues. Anyway, it works fine for me, but I don't use it for the things you asked about; I usually use it for obscure things, such as the "statues" in rpgsmse4.bsp. (Download Quake Condensed from my site if you want to know what I'm talking about .)

Maybe I'm just deluded, but it seems like it would be a pretty rare circumstance where Skippy would actually be useful for removing rendered but non-visible polygons.

The only issue I ever had with the program was when I tried to encase a func_door elevator with a set of "skip" brush stairs to create the illusion of a moving ladder. The brushes that were inside the "skip" brush were removed along with "skip" faces, resulting in a mostly invisible ladder. 
Perhaps I have Skippy by the tail ........ 
What QuArK version do you use ?? I use version 6.4.0 and never I found bsrush splitting tool.. Perhaps I didn't find the stuff yet, and so: where is it ??
QuArK Brush Splitter 
is in the toolbar, there is a symbol of a cube with a line through it (hover with the mouse over the button and you'll get a brief description, you can also press F1 while the mouse is over the button).

Just select a brush, select the button in the toolbar and draw a line through the brush with LMB and you're done.

You can also cut out corners (i.e. add vertices) by pointing at a corner of a brush and select "Cut out corner" from the RMB menu. 
I've never seen and used this feature... I'll take a look this evening..
Thanks for this great informations ;-)
Thanks Kell 
I have played around with Gensurf before, and it is definately the best way of generating large terrain surfaces.

My current map is largely an architectural map though, with the terrain bits very much playing second-fiddle to the main castle-like structures.

I will put some screenies up when I get around to lighting it. 
Is something wrong with your site or email address? Site seems unreachable and email bounces. 
i've reached disk space limit there, mailed to isp and waiting for their actions.
so mail and index.html file aren't working atm. 
I've just deleted a lot of my stuff off kell.vondur. Might help a bit. 

looks like the site returned back to normal.
one thing that annoys it still says it has not much free space, as if nothing was deleted... i'll fuck with isp more then. 
Maybe you should change the site url in the People section, the existing one now reports "no website configured". Or maybe it's a temporary problem, too? 
Eh? works here fine atm 
My Bad 
My local DNS-cache wasn't updated properly. After flushing it, now properly routs to
After formatting C and re�nstalling all, my Arghlite seems to freeze.
Compiling and vising goes fine, but the program arglight is somehow delayed by the system. 
Large Beam Ray 
In my new Q1SP map, I would like to create a large beam-ray coming from a light, directed in a precise direction, and with a specific shape (cylinder. conic, or other...)... What are the issue to create a light cone or a large light beam like this (if it's possible) ?? Is there someone to explain me the stuff ??
You need to use a Quake engine capable of volumetric lighting - whether one even exists, I don't know.

Or did I see something like this in Nehahra? 
Did you get any of the emails I sent you the last couple of days? 
use HalfLife, it has support for that stuff. 
The laserbeam pakket from Chtong I made I put on my website.
It's not as specific as you want.(cones radials etc.)
For that you need custent.

Note that you can't use doors in it! 
Wrong Email 
Wc 1.6a And Xp Problems 

im using xp pro and trying to use wc 1.6a, i cant select and objects in the 3d window atall :( ? and my texture application tool doesn't work :( can anyone help ?

Wc 1.6a And Xp Problems :) 

every things werking now, thanks too the great help from jago, you need to turn of hardware accelleration and then restart worldcraft, then no more problems! :D

I thought that was a double post at first :) 
...Tiddles is mapping again! 
Kinn, Necros And MadFox 
Thanks for your feedback.. Even if a standard/GL quake doesn't support volumetric light, is it possible to create directionnal light beam with a cone radial value, etc.. with standard light tools (like TyrLite or aguirRe light tool), or is it impossible ?? Let moe know what your light experience is...
is the standard way to have a directional light and it has worked since the original Light version. You have to use an entity to target the spotlight and the "angle" key specifies the cone width (default 40 degrees).

Argh/TyrLite and my Light has also the possibility to direct the spotlight via a "mangle" key. In my Light you can also specify a "_softangle" key for a softer spotlight cone. Search for "spotlight" in the readme for my Light tool and see more details.

Except for the obvious spotlight effect, you can also use these lights for very interesting transitional effects by using anti- or local minlight (delay 4) spotlights.

Typically you then use a high angle value (150-180) and a small _softangle (10-90) and direct the spotlight along a corridor or down a bottomless chasm. Experiment for best results. 
Cool... It is exactly what I was looking for !!!
Thank you very much 
holy shit, i thought you were talking about special effects like the HL laser beam thing... sorry, i misunderstood! :P 
You're Welcome 
Chtong will roast me for that.... 
Never Heard Of 
Compiling a Q1bsp I suddenly receive the message at the end of
Entity tex too long

Are my monsters talking too long? 
In Older Compilers 
the entity section can only be 64k, you've exceeded that limit. Either you'll have to shrink the amount of entity data (by e.g. removing default keys or entire entities) or switch to a newer compiler with a higher limit.

I assume you're still using qbsp256, its entity limit is only 64k. 
never saw the message before. 
why on earth would any one handicap themselves by using qbsp256? O_o 
See Here

Using my ConvMap utility, you can actually do the same grid-snapping in a pre-compiler step, just run:
convmap -l2 -i mapname
txqbsp mapname.out

ConvMap will just cut off the fractional part and keep the integer, essentially what qbsp256 does. See ConvMap readme for more details. 
i got your message and replied just now. 
Q1 Tools Update 
at . Minor improvements and bug fixes in several tools and engine. Please see readmes for more details.

Any comments are welcome. 
Wad To Bsp/map To Me. 
i dont know if this has been asked before, looked on this thread and i couldnt find it so here. is are there any tools to convert a doom wad file into a bsp or map file for quake1? or at least, can it be done?

thats it. 
A Quick Search 
of wad2map and wad2bsp at Google revealed some info that might be useful. 
Me Happy, Me Horny Too 
thanks man 
I could never figure it out, what�s the exact difference between TxQBSP and TreeQBSP? 
there used to be a world of difference, but I've crossfed features between them so now they produce near identical result on any map. If in doubt use TxQBSP, that's what I use all the time.

Please note that Tx has watervis default ON, while Tree's got it OFF. Both can be switched either way via options, of course. 
aguirRe, I use Hammer and TreeQBSP, do I have any reason to switch to Tx? 
As I said, they both produce near identical result (if watervis is set the same). AFAIK, there's no particular reason to use Tree anymore, but Tx has got a nice feature to select starting hull which is very useful in big maps when hunting leaks in hulls 1/2.

Try it, you might like it ...;) 
I'm curious: what is the reason for having the two different versions? 
Well, There Were 
two versions to begin with, Tree which is made by Greg Lewis and Tx that is made by Armin Rigo (also the man behind QuArK), both building upon the work of the original tools from id software.

I just started three years ago to improve and fix the bugs that I found especially annoying then (like leak handling).

Since Tx was the only compiler at the time that I knew could handle QuArK's float maps and Tree being the most memory efficient and otherwise overall better compiler, I started to work with both tools in parallel.

Over time, they became more and more similar due to my crossfeeding of features and adding work by Tyrann and ideas of my own to the mix.

So far it's been a help for me to have two implementations that basically do the same thing but in a slightly different manner, it's like a 2nd opinion. 
are you considering merging them at some point in the future? 
I Can't See Any 
point in merging them. If anything will happen it's me dropping Tree, but that's also a bit unlikely, since I like both and they serve a purpose. 
Re: Q1 Tools Update 
aguiRe, my comment is that I'd really prefer you to put the readme files inside the zips... :)

Having the readme also available seperately is fine and good, but by leaving it out of the zip files you're only saving a few kilobytes. I find myself having to download the zip file and then also download the txt seperately.

That's hardly a big deal and it won't kill me, but nevertheless I'd prefer if the readme were included in the zip, unless there's some compelling reason for not doing so. 
But You Have To Admit, Mr Fribbles 
that they make for good reading 
My main excuse for not including the readmes in the zips are for easy updating of the readmes without having to upload the zips again. I'm still on dialup and that means max 33k upstream. 
I updated my flow yesterday with your new TxQBSP (and RVIS tool), and what a surprise !! Some non understood texture alignement warnings disappear with your TxQBSP new release (there was some r_CuteNodePortal warnings, pointing some textures location out of polys !!!)... I don't know what you exactly did, but it seems to work better with this new version !!

About readme file not included into zip file, I don't think it's a real problem... Downloading some kBytes files is not a big challenge, even with a standard 56k modem... it took approximatively ... 10 seconds at worst... I really it's not able to increase your phone bill, unless you are a little stingy...

Thanks a lot aguirRe..

I don't know why the latest minor Tx update seems to make such an improvement for you, but I'm glad it did. 
With last TxQBSP, it appeared some r_CuteNodePortal warnings, giving a texture location out of any poly face... so it becomes hard to find from where the problem comes (regarding the read of your Q1ToolTips text file: it comes for sure from a unaligned textures..) The more when QuArK "search holes in map" tool found nothing... (in most of case, QuArK "search holes in map" tool can point up problem sometimes not detected, or not clearly detailed with TxQBSP (like poly unaligned location, or texture unaligned, or others..).. Anyway, trying the new one, these warnings disappear... so that's why I'm rather happy the problem seems to be solved... I will see later if they will reborn later (hoping not)

warning has nothing to do with textures or their alignment; it's caused by brushes being off-grid or misaligned to each other.

The reason why the coordinates sometimes seem to be in empty space, is because the warning then appears in hulls 1/2, where the brushes are invisibly expanded (see also ToolTips for more info).

To find the culprit, look in the nearby area for non-axial or complex brushes and perform force-to-grid actions on them one by one until you see the warning disappear. It can be a bit cumbersome ...

Also, the QuArK built-in leak detection is not very good; it often finds a leak where there is none or fail to find one that really exists. 
Thx for these precisions... But then, why these warnings disappeared from old TxQBSP version to latest verison ??? Have you an idea ?? 
What Do You Mean 
by old version, previous i.e. 1.07?

The only thing I can think of is that I know QuArK is shuffling all brush faces around within each brush each time you perform a save-load-build sequence. That can affect all kinds of things like warnings/leaks etc.

However, in both my compilers since a long time, I automatically perform a deterministic face sort to avoid these build variations. It can be disabled by using the -nosortface option. Normally I wouldn't recommend using that option.

I know GlassMan had a similar problem in GtkRadiant when building his gmsp3 map. By manipulating a light entity, a leak would appear/disappear nearby. The editor is probably shuffling the brushes/entities around and this can affect build results slightly.

Otherwise I don't really know. 
What Do You Mean by old version, previous i.e. 1.07?

Yes, I used the previous 1.06 one before I updated it yesterday. And I still don't know why it works better now...(??)

By manipulating a light entity, a leak would appear/disappear nearby

Typically, these problems come when complex brush (i.e. staircase maker, arch maker, etc...) exist in the map... It can also appear/disappear with a polygon add/substract... It's again a mysterious work way..

Well, sure you are right in your analysis.. You are too strong man ;-)

Thanks again

Item_key Issue 

I'm back with my beginner's problem... :) I'm currently mapping a base-based map, and I would like to know how to change the key looks like in the game. When I use keys, they preserve their castle-gothik looks, and I would like a "base key card" look...
So, what is the additional field I have to add in my key description ??

If You're Using WC... map properties and change ambience to base. 
Set worldtype 2 as a worldspawn key.

Stuff like that would be easier if you were using gtk. 
Distrans / Pushplay 
Well, so I need to change the map ambiance property by the worltype field in the worlspawn description
Thank you very much, I was looking about item_key properties only, so after a carefull look at

I found what I was a looking for... Thank you very much for your help...

Please don't be afraid to post, or send me any links like the above that you come across. I like collecting stuff like that, so when I am the last man alive still playing around with Quake I can have as much info as possible at my disposal 
Happy to see you enjoy the link... Just an additional information: this link describes only standard Quake Map Specifications, and many other fields can be added (for example in lights description or worlspawn description, or others...) which are specificly used by BSP / VIS / LIGHT tools... (see light aguirRe's VIS and LIGHT tools for example..) but I'm pretty sure you already know that ;) 
Terrain Maps In Q1 
Those of you that are building Q1 maps with terrain generators might have noticed that the player can sometimes get caught on invisible objects while moving close to the terrain.

This is due to limitations in the brush expansion logic for the clipping hulls in qbsp. To get a better understanding of how this logic works, you can enable the -hull 1 option in Tx/TreeQBSP to make hull 1 visible.

Then you'll actually see the protruding objects that the player collides with. You'll probably also notice that some brush designs will produce worse results than others. 
Terrain Expansion 
A-ha! ( not the nordic pop band, mind you ) There's an example of this in my terrain map where a steep angular hillside sticks out onto a ledge; there's already limited space to move over to the end of the ledge to get a health pack, and both I and the monsters in the area get fux0red by something sticking way out from the slope.
I'll maybe try -hull 1 and see what's what.
Still can't run a full vis on the thing though, since it estimates over a month in compile time o_O 
The Player 
and most monsters use hull 1 for collision detection, while e.g. shamblers use hull 2 which is even more expanded (looks really weird).

Making the clipping hulls visible doesn't fix anything but it might help understand why these symptoms occur. There is an option -altexpand to alter the behaviour of the brush expansion logic, but it's a bit controversial and usually doesn't really fix the problem. 
Just a general question... if only large monsters use hull 2 (and the player does not use it at all), would it be possible to remove that hull from a deathmatch-only map and save some space?

Of course the reduction in file size would probably not be significant at all, so I doubt it would be worth it. I don't necessarily want to do it, I just want to know if you <can> (potentially). 
Brush Expansion 
Can covering the offending area in clip brushes sometimes help this problem? 
Installed Windows Xp 
and now my Quake1 cries with SIGSEV failures... 
This isn't what you wanted to know, but if you did that then you couldn't play the map in DMSP. 
It's pretty hypothetical but yes, in theory it should be possible (if the engine also was changed in a similar way).

Other games (e.g. Hexen2, HL, Q2) has an extra crouching hull so I can't see any obvious reason why it should be impossible to remove the shambler sized hull if there are no shamblers around that can complain.

You wouldn't save much space, though. Especially since DM maps are generally smaller and with less detail to keep r_speeds low. 
Yes, if the clip brushes would completely cover the invisible protruding objects in the hull in question.

The clip brushes get expanded the same way as other solid brushes so if you can't confirm by "feeling" that the the clip brush works, you could use another texture momentarily and build with -hull 1 to visually confirm it.

The main problem with the expansion is that it gets unexpected on complex brush shapes. It's always simple to imagine how a cube is expanded, but pointy triangular shapes that look great in the editor, can grow like cancer in the other hulls. 
I've spent some time looking at the expansion code, trying to solve the strange clipping bugs you guys are talking about. It SEEMS like the code was designed the way it should be, and i wonder if there just isn't some implementation bug. Or, a precision problem?

I never checked out your visible hull stuff, and it would probably help me understand exactly what wrong results the current expansion code is generating.

Anyway, this is one of those things i really wish could be fixed in qbsp, if anyone ever finds the bug or realizes why it doesn't work. 
AFAIK the brush expansion isn't really a "bug" since there's no obvious way to do it without getting protruding parts in some junctions.

Changing this logic is controversial because most experienced Q1 players (not to mention speedrunners) know how a map should "feel" when they see it.

Me and Tyrann have spent a long time spanning several years trying to find the cure for the brush expansion related problems, especially the theoretically impossible leaks in hulls 1/2 (when hull 0 is sealed). Same for the annoying clipping errors; there are a whole list of variants just for them.

I've also contacted XP-Cagey who works with the HL tools and he confirms the problems and it appears that in HL, the situation is even worse. Apparently, he's found some kind of solution (or at least improvement) for HL and I've tried to translate it to Q1 but I've only managed a partial implementation so far (available with the -altexpand option).

Any help or suggestion regarding these problems are welcome, but I've a feeling that the solution might be complex. The whole build process seems to be something of a hazy floating point stochastic (or even chaotic) process, where small changes can have large impact elsewhere. I hope I'm wrong ...

But check out the hull visualization, I think it's a real eye-opener for most mappers (and players too). 
I Forgot To 
mention that the brush expansion logic is also the reason why I think that e.g. creating a block of natural rock from one multifaced brush is better than several triangular ones that together form that block. Even though there's no difference when looking at it in the editor, the expansion might be different.

The multifaced brush will just expand pretty logically outwards and will not generate any weird protruding objects. The expansion is always done for each brush separately so it won't notice that after expansion, the brushes might not join nicely anymore.

There are probably other aspects of this issue too. 
creating a block of natural rock from one multifaced brush is better than several triangular ones that together form that block

Now that would be particularly relevant to Gensurf created terrain, because the t-mesh is neccessarily composed of individual triangular brushes.
The more I read in this thread, the less I want to finish my map :( 
Merging Brushes 
When I was working on the terrain in RPGDM1 recently, I noticed that entire vertical patches of triangular brushes could be exactly reproduced by clipping pieces off of a 6-sided block. That was quite cool, and really helped the clipping problems.

/me HUGs 3-point clipping

Hmm. After writing this, it seems less relevant than I thought. 
Sorry If I Sound 
discouraging, there are other opinions that promote triangular brushes instead (which may very well be right) so the case isn't clear.

I'm just trying to rationalize around the brush expansion issue to help mappers understand some of the underlying structure.

I also forgot before to add a link to XP-Cagey's interesting article in the subject:
Nice Link 
Winxp A Quake1 Killer? 
So if Quake1 doesn't work under WinXp, I tried the WinQuake program. And then it does.
But when I run my convertion with my selfmade monsters, they don't appear in game.

The program starts at the start.bsp without messages, but when I run a saved game, it suddenly comes with all those errors asking for the monsters I put in the progs.dat?!

Why doesn't it do so when I start a game? 
Are you running the game from your own custom directory? e.g. c:/quake/winquake.exe -game madfox 
remember to delete opengl.dll in the quake folder so that you can use glquake with new graphics cards. 
Point Is 
it's the same directory from C:\ I used to play with under Win98, and there was no problem.

Now with WinQuake, it seems to block out my progs content in the pak file, giving all these edickts of finding no monster_orb etc. 
RE: Winxp A Quake1 Killer? 
I�ve been running Quake1 on WinXP for years without issues. 
Just A Thought 
but how do you managed this without winquake?
it kills all my convertion options. 
RE: Just A Thought 
Use FitzQuake for NetQuake and FuhQuake for QuakeWorld. 
The only engine that doesn't work in XP is DOSQuake, all others work fine including WinQuake.

Follow Kell's advice and check out the shortcut contents and make sure it's the same as you were using in Win98 with DOSQuake. Many engine options are identical in all engines. 
XP Intruder 
If I use Telejanos, everything comes through all right.When I use DOSQuake, with the same options as in Win98, suddenly all my own monsters are gone. And I do play it from C.

I don�t mind if happening so, but I like to play Quake straight, without comparing engines before it. I found Telejanos is working so dark, couldn�t change the gamma. Made me make the levels much lighter, but then the original engine makes it too bright.

It comes to me as a surprise WinXP is capturing all my own monsters from the progs.dat 
I'm sorry, but we can guarantee that it's not the engine, or your operating system, that is preventing your mod from being detected.

Also, I'm sure you're aware of this, but you do have your mod files in a seperate game folder? (e.g. C:\QUAKE\MadFox) - I know some people have tried putting their mod files inside ID1, and then they wonder why it doesn't work correctly. 
I Just Chequed, And 
my Telejanos under C: won�t show them, although the same pak file under D: works good.

I made a pakfile with Quark,
made a file maps for the bsp�s,
made a file progs for the mdl�s,
and a file for the sounds.

Could be I have to use two pakfiles, but I find it strange the same pakfile runs good under D: and C: fails... 
Do any of your mod's files have capital letters in them? This is especially important for the files in the pak. DOSquake really doesn't like them, and so it might just not be recognising the files because of that. It's quite likely that telejano has this fixed...but of course I could be totally wrong here. Anyway, try making sure all the filenames and extentions are lowercase if they aren't already. 
Thanks For Your Answer 
No, I just get confused while I can't see why it works under D:\ and not under C:\ 
-hull 1 Question 
I have a few clipping problems in this map I'm working on, so I tried using -hull 1 -solid -noents on TreeQBSP. Well it seemed to work fine, everything was expanded, but I didn't notice anything that would have been causing the clipping errors. I'm just supposed to look for misaligned surfaces, spaces that are too short, and things of that sort, right? 
There Is No 
guarantee that clipping errors always will become visible when using that option but if you actually *do* see a HOM, it's a safe indication on a brush problem in that spot.

Typical causes are misaligned brushes or sometimes even a nearby pointy brush that somehow "pokes" a hole through the damaged brush.

If you send me the zipped map+wad and a description how to find the spot (or coordinates), I'll take a look and see what I can find out. 
I'll send the message shortly. Gotta put all the textures in one wad. 
Stupid Me 
forgot to put in the progs.dat and progs.src
now everything runs fine again. 
Great link aquirre, that explains the thing i was missing -- i thought that the qbsp bevelling would be sufficient, but i hadn't thought of the case where the blade of a wedge-shaped brush is running at an angle like that.

After further thought, i don't think xp-cagey's solution actually solves all cases -- he seems to have handled all problems caused by sharp edges, but imagine a sharp point at a weird angle, such as a pyramid with the pointy end in a nonaxial direction -- this still wouldn't be solved by his code becuase he's only looking at edges.

Still, it's an improvement to go from handling all faces and some edges correctly to all faces and all edges. I think a final bit of code to address points as well would finish off the problem for good. 
Unless Of Course... 
it's a precision problem rather than a logic problem. 
One of the reasons the map I'm working on has such a huge brush count is my liberal use of triangles, on architectural as well as terrain brushes. I haven't been that aware of the hull expansion issues until now. Bugger. 
More On The Issue 
As I think I mentioned before, HL seems to have had worse problems than Q1, so at least one of the cases XP-Cagey's describing in the article is already covered by the original Q1 expansion code.

He sent me some map examples that he claims fails in HL and they worked as expected in Q1.

I have a feeling that the problem is a combination of brush expansion, CSGFaces (brush merging), outside filling, SolidBSP (building the final tree) and numerical errors along the way.

Since I doubled the precision (to 64-bit) in my compilers, they work much better than before, so precision is involved but increasing it can only do so much. It's also interesting that doing the same to e.g. vis, doesn't make any difference at all.

Tyrann made a great stab at it in his TyrQBSP and some of the solutions he put in there, I've imported in my versions. Overall, it doesn't really seem to help, it only makes the compiler faster and a bit more consistent.

Kinn: If you don't have any obvious problems, maybe you shouldn't worry too much yet? After all, this isn't a new problem and it's definitely not worse than it was before. 
'As I think I mentioned before, HL seems to have had worse problems than Q1'

I can attest to that after spending a weekend playing the Sweet Half-Life mod (mostly awesome BTW). I seemed that it was possible to get stuck in several areas that I would not even think of needing a noclip brush in within a Quake map. 
the mappers of that HL-mod should try out XP-Cagey's tools, he seems to know lots about this and other tool issues. Since I assume that the original HL-tools were based on the Q1 ones, it's a bit surprising that they are inferior in this aspect. 
HL seems to have had worse problems than Q1

That might simply be becuase of the "normalization" thing he talks about in part 2 ... it sounds like a horrible idea :)

Anyway, i'll try to do some code diving some time in the future and see if i can actually come up with any improvements on this front. 
Texture Grid 
I finally managed some clipping in Quark64.
But it is rather a brute instrument, it took me half an houre to get the comparing textures right, the stupid thing is working like it has drunk a bottle of XXX.
If I make a same kind of brush, and add it, it is done in a minute!

Isn't there a more clever way to size the grid?
ie. move 16 up or down? 
is there not a slider on the top left corner of the screen to control the grid settings? 
Hep Meh, Hep Meh! 

Does anyone have any ideas as to why a simple but moderately large q1sp would run fine in winquake but crash out with "Allocblock : full" when run in glquake, macglquake or joequake?

Did you set memory extension in your glQuakes (like a -winmem 32 command line or something like this )?? It seems you did it with winquake... but not with your glQuakes... :o\ It's why it works fine with WinQuake but not with the other engines... 
Thanks JPL, but that was the first thing we checked. I just changed the "win" to "gl" so all other parameters were the same. :-)

To clarify. If runs in the software version of each engine (win, mac and joe) fine but in the GL version AllocBlock: Full. 
.. I have already "met" this probelm, but I'm unable to remind where it comes from, and how to solve it... sorry... :( ...
Did you made a try with FitzQuake ?? 
Take A Look 
at the TooTips at my site , it explains why it (and many other problems) happens.

There is also an enhanced GLQuake engine that most likely will load that bsp. If it doesn't, let me know and I'll look into it. 
I found this in your ToolTips

"AllocBlock: full"
This error is directly related to lightmaps in the engine, but is normally caused by a leaking or
boxed large map. Seal the map or remove box. GLQuake 1.11 or Tomaz/Win/TyrQuake can usually load
this kind of bsp.

Can I have some further explanations please, I'm not sure to clearly understand the source of the problem (the part concerning boxed large map)

Thanks, that's a big help. Investigations will continue and I'll report back later :-) 
A "boxed" map is one where the entire leaky structure is wrapped in a huge box (also referred to as a "daiper".) This is generally a desperation measure taken to get a map to work.

While doing this lets the map vis, there's still a performance hit due to visibility calculations being done for the spaces outside the map proper. Also, lightmaps are computed for this "outside" space, bulking up the lightmap data size even more, especially when the box is extremely big.

If you absolutely cannot find a leak, shrink your box as tightly as possible around the region/s in question, like I did in Swamp. 
Fat Controller 
Thank you very much, now I clearly understand the issue, and I think it's not a good way to build a good quality map...
I'm pretty sure this kind of "turnaround" can be avoided with a lot of care during the map design.. and using a lot of compilation steps... With my first map (Hatchepsout), during the first tries, I found one big leak problem, and I solve this by restarting from a stable point (from scratch here !!!)... Too many copy-paste without textures and brushes re-alignment were involved here.. But I restart with a lot of care and methodology regarding brush and texture issues, etc.. .. and no more this leak problem occurs.. Sure it can be more complicated for huge map, and when the design is almost finished.. In my humble opinion of beginner (I started mapping just since 6 months, more or less.., and I guess pros-mapper should think the same), I really think it denotes a loss of care during map design... I'm not saying the mapper is a bad one, just saying he have to take much more care at what he does... even if sometimes QBSP tools work in mysterious ways... some warnings issues are sometimes very "esotheric" -8o\ ...
Anyway, thanks for the explanations... sure I will try not to do some "huge boxed map" designs...
Basically what Fatty just said except that normally there's no big performance hit in-game, since vis will [very slowly] discover that the outside isn't very visible from the inside (if the leak isn't very large).

But it most certainly puts an extra burden on all the tools and engine. Vis time can easily be extended 10-100 times by boxing a big and complex map.

Morfans: Was it an old Q1SP map or a new one that you had the AllocBlock error in? I'm always interested in troublesome maps. 
simple question:

if you have access to the bsp compiler source code, why is anything a mystery? is it just very very complex? 
AllocBlock: Full 
Is a lightmap allocation problem. If there's too much surface area in your map, there will be too much lightmap data to store in glquake's fixed-size lightmap arrays.

In addition to leaky maps or maps with boxes around them, it's also caused by maps simply being really big. 
I'm Guessing 
you could reduce the lightmap size by strategically scaling up textures in places that can't be seen by the player. 
At least for me it's very complex, there are an incredible amount of float calculations and comparisons that easily can have an adverse effect on the results.

There are also several data abstraction models and 3D-algorithms that can be hard to penetrate.

It's actually pretty easy to write code that offer very complex results; just look at the simple fractal equations that unfold to amazing patterns when translated into graphics. 
Thanks Necros... 
for your post #2141, but I'm may overlooked something in the Quark64 program.

A slider on the top left corner? 
that's correct. 
In my QuArK 6.3 version there is like necros said a grid button to the left in the toolbar, you seem to have rather different buttons from my version of QuArK. You might consider to reset the toolbar to default (if it isn't) or add the grid button to the toolbar (if possible).

In any case, you can also set the grid in Options-Configuration-Map-Display-Grid step. 
Why was the text Grid in the last sentence replaced with dots? 
there's a limit on the length of "words" on func, to prevent the page width from being pushed out by long strings of letters with no spaces. One of my to-do items is to redo the html so that individual posts can't push out the entire table.

Hmm, but since hyphens are treated as a word-break in browsers, i should probably have allowed for that in the code. 
Ah OK 
I thought it had some similarity to the shortening of URLs. Or possibly the word "Grid" was considered offensive so I'd have to spell "G**d" ... 
But It's G00D For Me.. 
My grid texture was standing on 1, and that just doesn't worked so well.

Seems I must take some time reading the manual before strugling with these new programs.

Thanks a lot! 
it varies from person to person, but I usually work with the grid set at 8, small enough to get fine details, but large enough to avoid annoying tiny leaks and overlaps etc.

Hope that helps 
Grid Setting In Quark6.4 
MadFox: I'm currently using QuArK6.4 and I'm pretty sure a grid setting button exist in the tool bar, located in the top left corner... See this for an overview..

and these one for the settings

DaZ: Personnally I prefer to work with a grid set at 4... and so I agree with you: it depends from the designer.. 
Eh Da Fuk? 
It's not like the grid size is fixed while you're mapping is it? You just set the grid to whatever size you'd like it to be at that precise moment, it's not much more complex than hitting a button or two...

What grid size do you map on?
I use whatever size I need, u craka. 
Do you mean you are sometimes changing your grid settings during your mapping work ??!! Is it not a little bit dangerous to ensure correct brush alignement ??? I mean, changing, for example, grid setting from 4 to 32 can be very tricky while trying to place two brushes side by side, with a face touch... How do you perform that ?? I'm really very curious to hear that... 
Grid Setting 
only affects alignments made afterwards, it doesn't move already positioned brushes (unless you align them again of course). I think this behaviour is the same in all editors. 
Eh Da Fuk? Part 2 
What the hell.

I change grid settings all the time while mapping. It's not tricky.

Changing 4 to 32 only means you'll have one square instead of eight; it's not like the overall grid moves around on you.

I just shot a keyboard from my nose throught the table. You owe me a new table!!

Grid settings are for selecting at what accuracy you wish to manipulate the brush. Nothing more. What's so complicated about that? 
Grid Setting 
Thanks to all, I now what is grid setting... blah.. I'm a beginner, but not a geek... I was just saying it can be tricky to align a brush placed with a grid set to 4, and an other one with a grid set to 32... What is assuming you are able to align easily the two brushes ?? Nothing... so I thing changing grid settings during mapping mybe dangerous... that's all... 
Understanding How The Grid Works 
does not make one a geek ;) 
my "default" grid size for most work is 8, I then change it if the situation calls for it. 
What is assuming you are able to align easily the two brushes ??

That fact that 4 goes evenly into 32. If it was three brushes made with grid settings of 7,19.5, and banana, then you might have problems. 
To Be Honest JPL 
I'm absolutely amazed that you can map at all with the grid set to 4 constantly. Once you get used to using the various grid sizes effectively, you should see massive improvements in your mapping techniques. 
i just keep grid size set to 128, works perfectly for me anyway 
I am always constantly changing my grid settings depending on the what kind of brushes I am building (higher grid for laying down basic geometry, lower grid for adding details) and also depending on the zoom level in my 2D views (it doesn�t make much sense to use low grid when you have half of the map in your 2D view. 
Changing Grid 
I default to a size 16 grid, but yeah I'm always changing it. It's easy to forget that you've changed it sometimes, and you start to make a new brush you think is 128, but instead comes out to 64! You just have to pay attention to what you're doing and not be lost in space like I usually am =( 
hm... i like keeping grid to 16 when i'm working on major brushwork, but if i'm doing lots of details or working with strange shaped brushes, i like to turn the grid all the way down to 1 to get as much control as i can over the vertices. it also makes working with vertices easier in gtkr for me. 
that explains a lot :) 
More Pro Tips 
also metl, i've noticed that many of your maps are very small in scale.... if you're in doubt whether your map is big enough, I find it's good practise to select the entire geometry and drag in the x,y and z direction. Better safe than sorry I say! 
I Ment Something Else... 
while trying to clip the textures on the brushes, I was conquered by the fact that in small polyhedrons one can align textures quit easily, but in big polyhedrons it screwed the last bit of patience out of me.

So my question was not the gridsetting of the working table of polyhedrons, but the one in the looking screen for textures.

By doing this for a few houres with less results, I was reminded of the commentary of texture misalignments in maps. And now I expierenced how hard it is to do it right!

So I wanted to shout out if anyone ever would have commands about texture misaleignment in maps, he had to try to clip a texture of a big small brush, and maybe I wouldn�t be so dissapointed after all that ungratefull work...

but than it would be my loss of patience and the wrong attitude, so my question once again

it seems the texture clip setting of the choosing texture view window doesn�t seem to be affected by the brush grid setting?

sorry for my pronounced way of explaining. 
I'll Join Shrek As Donkey 
because it seems the texture clip setting of the choosing texture view window is affected by the brush grid setting. 
As I said, I'm a beginner compared to many "pro" mappers here... And regarding my poor experience, I don't see cleraly why changing grid settings during mapping will improve my work... Anyway, sure you have good reasons.. but today I'm not able to understand it...

Sure for the geek test you will have a big score ;-))) 
Q1 Tools Update 
at . Minor improvements and bug fixes in several tools and engine. Please see readmes for more details.

Any comments are welcome. 
18.73767% - Geek 
Sounds about right.

JPLambert: To understand the benefits of the grid - try sketching out large architectural features using high-ish grid settings, to get an idea of your level's layout. Once you've got the positioning of the main landmarks down, you can then go in at lower grid settings and start building the real brush work. I like to use big chunky brushes as 'placeholders' for stuff that I will go back and build properly later. The size of textures should also give you a clue as to what scale of brushwork you should be building, and thus what grid size is the most appropriate. 
15.58% geek for me... you are "geeker" than me ;P...
Anyway, I now understand why you change your grid settings during your mapping work... I do not build my map with this methodology today: I build it zone by zone, and as properly as possible from the first time... (poly placement, texture alignement, etc..etc..) so I just think it's a question of methodology for each mapper... and each mapper have its own one... Well, thanks for these explanations... 
11.4% Geekish Tendencies 
And back to our regular programming. 
... is cheater... for sure ;D 
For me, changing the grid setting while mapping is like changing which foot my weight is on while walking.


grid settings of 7,19.5, and banana

Most of kdmw was built on a grid setting of banana.
You can tell, can't you? :( 
I Own... multi-sided dice
i'd like to see a one sided die...

13.4 ... O_o 
Just make a moebius strip and mark a 1 on it. Throw it around to your heart's content. 
Round it off at 20.0 percent for taking an on-line test. 
16.765... be expecred, I guess.

Though the board seems to have a lowish geek factor. Nobody over 20 yet. 
the thing is there is a lot of stuff to know on there. half the questions contained things i had never even heard of. honestly, i like to see someone get over 75% questions right. 
25.44379% - Total Geek 
must be all the linux rapistness 
Wad Do I Wrong 
Although I searched in the manual of Quark64 for the facility of transporting new textures in the program, I just can't get it right.

Everytime I open a map with my own textures, the new 3D texture screen give me a lot -can't find texture..- 
As A 
17.357% geek 
You've got mail. 
Holy Shit 

Does that mean I win or lose? 
If You Take The Test 
you automatically lose 
But you're a hotshot Quake IV mapper - so I guess it's a win. 
Bleh. There are a shitload of people in the mapping community who are just as talented as I am (or more).

A fair part of getting that gig was previous experience, persistance, and simply being in the right place at the right time.

Granted, my absolutely gigantic genitalia might have had something to do with it. 
Granted, my absolutely gigantic genitalia might have had something to do with it.

Cool. Any chance of working that into some sort of Quake IV easter egg? 
He He He 
Put a Quake IV version of RPG's Penile Devestation in there as a secret level.

I'm just glad that there are those who scored higher than me, but then again, I am more freak than geek. 
this is not really mapness, but more of a technical question on quake. so it's more a question for engine coder dudes (metl, aguire...)

specifically, how does quake handle sound playing?

channels: how do channels work? i know basically that you can only play one sound on a channel, but there are only 8 channels available in quake, and i've heard more than 8 sounds at once coming from different entities (like maybe 10 different monsters awakening and all playing their sight sounds)
but a single monster playing sounds on the same channel will cut off the previous ones (an ogre playing it's sight sound will cut off with the pain sound if shot)
so exactly how does sound playing work? 
Another Q1 Sound Question 
I've always wondered what the exact correspondence is between the attenuation value and the "radius" of the sound. If I knew these values I guess I could place ambient sounds in the most optimised positions possible; ie maximising sound coverage of an area whilst minimising sound overlap. 
there are different attenuations for different emissions. regular sounds like monsters and guns are attenuation 1, whereas ambients are 3. obviously, this is some type of multiplier that the engines uses to calculate the volume from distance value. i find ambients tend to be heard about 512 units in diameter with origin as center... can't verify this however. 
Vertical Up Or Down Movement 
Related to RPGDM1 last DM map, I would like to have some information about Vertical up or down movement.... I tried to extract RPG's map with my editor in order to understand how you built the ladder... but I didn't find what I was looking for very clearly (perhaps I didn't look in the right direction...)... I mean, how do you allow the player to walk verticaly up in front of the ladder ??
Q1 "ladders" 
Are just very steep staircases made of clip brushes. Nothing more, nothing less. 
OK !! It explains why I didn't find the stuff: all staircases were not fully translated into polygons after conversion (it appears some "hullxxx" in the .map file) and thus they were not clearly visible in the editor.. Thank you very much... It was another stupid question from the beginner I am... ;P.... 
RPG kindly released the source map for RPGDM1 along with the bsp, so you can load that into the editor instead. 
Thanks, I'll take a look with a lot of care this evening...
ok, my new map is way over max. clipnodes (about 46K). Covering detailed areas in clip brushes should reduce this, right? Also, say a clip brush covers a "broken" floor (like the floor at the very start of Bastion) I've noticed that the floor is still sort of sticky: i.e. it's flat, but the friction seems very stiff. Is the clip brush still reducing clipnodes if it's 'flush' with the unbroken parts of the floor, or does it have to be raised slightly off the entire floor surface? 
Heh, 46k 
I guess you've already checked my ToolTips for this issue. Clipnodes only add up in hulls 1/2 (the clipping hulls), so covering with clipbrushes help.

AFAIK clipbrushes melt together with other brushes normally, so you shouldn't need to raise the level (at least I've never seen such a requirement).

I'd absolutely recommend that you check out the map in hulls 1/2 using the -hull # option, to see if there are any major enclosed volumes in those hulls that need filling (or open to the void).

Noclip outside to see if such orphaned volumes exist, they can add quite a few clipnodes to the total. It's not enough to seal hull 0.

If you wish, you can send me the zipped map+wad and I'll see if I can spot something. 
Sorry for any delays in my responses--I've been gone a few days.

As Kinn said, the "ladder" effect is created by making a very steep staircase using the clip texture. I used 16 units high, 112 units wide, and 1 unit deep. And as aguiRe said, the .map source is released, so you should be able to get a good look at it in your editor. Unfortunately, as aguiRe mentioned to me in an e-mail, there seem to be some floating point errors, but that isn't always a problem, especially if you don't compile it. 
JPLambert uses QuArK so he should be fine with float maps. QuArK can even read the original Q3 format as well, so there are several options.

The ones most likely to have problems are those that use the BSP editor (WC seems actually to be fine with floats too).

My compilers are OK too since they handle floats, even the technical notation in your converted Q1 map (otherwise you wouldn't be able to build it). 
With your latest compile tools, my map builds ok (with no leaks), and it can be loaded in custom engines that can tolerate it. I'll give it a good going over with clip brushes first; but if it's still giving me problems I'll hand it over to you. :) 
How many marksurfaces does your map contain? As far as I can see there are usually more marksurfaces than clipnodes.

I found that map crashes in almost 100% cases when it has >35000 marksurfaces. That goes to vanilla glquake or winquake.
But I may be wrong. 
46688 clipnodes
28732 marksurfaces

unusual? btw, what are marksurfaces exactly? 
I Don't Know 
exactly what they are, but AFAIK they are bad ;)

My map has 29k clipnodes and 34k marksurfaces.
Marksurfaces grow faster than clipnodes for me, but that's the experience only from one my map. 
There Is A Difference 
in how the exceeded limits affect the engines. The excessive marksurfaces (>32k) cause strange behaviour in most engines due to a coding bug, the limit should actually be 64k.

Clipnodes appear to be related to nodes which by specification cannot be >32k, since they'll otherwise be interpreted as leafs. If they are, the engine won't be able to tell how the bsp tree looks like and anything could happen.

However, I've never seen any engine actually crash due to excessive clipnodes. 
My Map 
uses a staggering amount of triangle brushes; i guess that's what is causing the clipnodes to skyrocket 
After Some Experiments 
earlier with PuLSaR's map, I found out that marksurfaces are affected by both world and entity brushes but they're only affected by the visible hull (0). Adding clipbrushes won't reduce them.

AFAIK marksurfaces are somehow related to surfaces (i.e. visible planes) in the map. 
Kinn, your prevous post has a cool #2222 
My Experiments 
show that the map with ecsessive amount of marksurfaces becomes very sensitive to adding thin detail brushes and curve constructions. 
that spikey map i was working on before was crashing most quakes with about 37000 clipnodes. 
large maps cause large problems... 
After understanding "clip textures", and doing so, I found myself stranded with the same thing for animated ones. Sometimes they appear good in Quark, but after compiling not. 
Animated Textures 
Some BSP compilers don't automatically include all of the frames for animated textures in the BSP (wQBSP is one of the culprits, if I remember correctly). To get around this, you can use another compiler, or you can manually apply all of the texture frames in the animation into the bsp (by applying those textures to hidden faces somewhere in the level, eg on the back of walls which you will never see).

Of course, that may not be your problem, MadFox, can you give us more information? 
Never Saw Tex Misaleignments, Untill.... 
After finishing the Quatrotski map with texture clipping, I noticed the lava brushes didn't compare.
So I tried to match them in Quark6.3
After doing so, and compiling, they still went separate. 
why are you using quark? 
do I play Quake? 
...errr.. there is aonly a pub banner here... or there is a hidden "subliminal" message ??? 
Need Help Making A Monster Trap. 
I want to make it so that when you kill some particular monster, two more appear via teleport. I know that it involves the trigger_multible, but i forget how. 
Are you making an uber-terrain map if I recall? If you get a minute, what sort of clipnodes/marksurfaces are you getting on that? 
Start your teleported monsters off in a hidden box outside your main level. Make them stand inside trigger_teleports, but give the triggers targetnames, that way they won't teleport until triggered. Set up your info_teleport destinations where you want your monsters to appear. Have another monster target the trigger_teleports - when you kill him, the others should teleport in. You might also want to add a delay to that. 
...strange, it sends me to the fat controller's Q1 ladder tutorial.

Are you making an uber-terrain map if I recall? If you get a minute, what sort of clipnodes/marksurfaces are you getting on that?

from my qbsp.log:

---- WriteBSPFile ----
8259 planes 165180
13898 vertexes 166776
6414 nodes 153936
292 texinfo 11680
11280 faces 225600
25868 clipnodes 206944
4035 leafs 112980
13603 marksurfaces 27206
50568 surfedges 202272
25692 edges 102768
43 textures 783216
lightdata 0
visdata 0
entdata 30840

I just c'n'p, 'cause I honestly don't know what it all means :P 
Thanks Kell 
With my map I get:

---- WriteBSPFile ----
15103 planes 302060
26567 vertexes 318804
13760 nodes 330240
847 texinfo 33880
22945 faces 458900
44954 clipnodes 359632
5951 leafs 166628
28612 marksurfaces 57224
101267 surfedges 405068
50691 edges 202764
54 textures 1130160
lightdata 0
visdata 0
entdata 30754

Already, I can see the similarity with the high clipnodes/marksurfaces ratio, which is I believe a result of loads of triangle brushes. I'm currently covering as much as I can with clip brushes, which is having a dramatic effect with reducing clipnodes, although I have a long way to go before they drop below the magic 32,000. 
If you are using Dark Places anyway, maybe you should consider the Quake 3 BSP format. You are using Q3 textures a 1 to 1 ratio would look better too.

PS. I still fear the Vonder! 
The Biggest Drawback Would Be 
you would not be able to use Aquire's tools. 
I Don't Think That Would Be Much Of A Loss 
with q3map2 and all of it's bazillion features or whatever 
I haven't researched the idea of Q3 bsp in Q1 yet. Can monsters still navigate the same? i.e. are the clipping hulls the same?

As for Q3 textures, well actually they are the same scale because I resize them 50% before I do the palette conversion.

And yes, having to use totally different compile tools would be a headache as well (not to mention having to switch to GTK). 
Those stats are after I replace the valley floors of my terrain with large flat brushes, which reduced the clinodes cosiderably. 
Same Here 
Another thing I need to do though is isolate patches of terrain that combine to form convex shapes, and replace those with single brushes. That should reduce a lot of overhead if I can find lots of instances of that. 
Good Luck 
you're going to need it ;P 
yeah - although I reckon if I go really crazy with the clip brushes, I can probably get the clipnodes under the limit. 
Would There Be 
a general interest in me publishing a high-capacity WinQuake 1.20 variant similar to GLQuake 1.20? 
That would be cool. Winquake has many useful features lacking in GL, r_drawflat for instance.

Btw, something I've been meaning to ask you; I've been using -hull # in your bsp tool recently, and I've noticed that clip brushes are still invisible - is that intended? 
FitzQuake Has R_drawflat 
Yes It Does... 
but also standard limitations on clipnodes etc. 
I previously have had no problems in my test maps with Q1 monsters in Q3 bsp's. Of course the hull construction has to be different to accomadate the crouching mode.

I had planned to send you one of my test maps, but when I tested it in Dark Places the bugger crashed! I have been tweeking the Dark Places code for my own sordid purposes, so that may be the culprit and then again, it could be a corrupted .bsp

I suggest building a small DM map with a good deal of connectivity and then running Reaperbots in the map. If the reapers can navigate in it then surely any monster set up you may have in mind would definitely work.

I'll get back to you later in the day. 
Sounds cool. I'd like to hear from any Q3 gurus, how do the hulls work in Q3 bsp? Logic would suggest that there only needs to be two hulls - a player hull and a crouch hull. Either way, they must be different to the Q1 hulls. So how does DarkPlaces handle the monster clipping? 
if you could put in the r_drawflat on your glquake engine, that'd be nice. ;) 
WinQuake 1.20 
OK, I'll see what I can do. I have already a version where most of the improvements from my GLQuake seem to work, but there are a few weird things I'll have to investigate further. WinQuake also have the r_draworder cvar that's useful for checking visibility.

Kinn: Yes, clipbrushes are always removed entirely from hull 0. I actually haven't thought of if this is correct or not when using the hull # option.

Necros: I don't know how much work that is atm, maybe later. 
The bsp was corrupt. For shame! I am compiling a new version of it at this time. Currently it is giving Q3map2 a run for its money. I made extreme rez textures (each is at least 4 megs in size) for it with the idea of compiling the light maps and then replacing the textures with lower rez ones later.

As it stands it would actually be a decent map for Quake 3 Tourney, well after the textures are replaced, and a sky box is added . . . 
AguirRe, would it be difficult to make clipbrushes visible in -hull# builds? That would strike me as quite a useful option, as it would give a true visual indication of the clipping hull.

HeadThump, 4 meg textures? o_O. I hadn't thought of the idea of using hi-res textures to generate lightmaps, then replacing the textures. Although I don't think i'll be going down that road. 
Visible Clipbrushes 
It sounds like a good idea and it also appears easy to implement. But after looking at a typical DM map where large parts of the walls, floors etc are covered with the clip texture, I'm not so sure it's such a good idea.

Maybe this sounds awkward, but you can get a similar effect by just replacing "clip" with e.g. "clap" in a temporary copy of the map file and build with the hull # option.

You'll then either see the "clap" texture (if there is one) or the checkerboard pattern instead of the clipbrushes.

Have you tried this?

The search/replace operation can be automated using a standard sed (stream edit) utility if it needs to be repeated. 
Tested With Reapers 
They played like manly men. No problems.

A few notes about the Dark Places Q3 bsp implementation that is even different from its Q1 protocol. Ambient lights are stripped out and only sourced lights are used.

Models for the sourced lights are stripped out too. Its the biggest bitch I have with DP. You have to custom cache them in your mod like you did with that huge flame in Bastion (I know this works in Bastion, I've done a little, uhm, experimenting with it on the side).

You can convert the flames to Spr32 format and you'll get some sweet high high rez particle effects with them. Also, you can use glow or luma textures on surface lights. You wont even miss the old ambient light entity everywhere.

I'll convert everything to low rez so I can ship it to you. Don't expect much from those textures. They are just place holder solids. 
Button Newbie Question 
how do i make 2 buttons to open one door? been trying to figure it out by myself for a while, but no luck. :(

this is for q1, me uses worldcraft 
AguirRe, that sounds reasonable, I hadn't thought of doing a temporary texture replacement.

HeadThump, email received, but Outlook Express detects it as a virus for some f'kin stupid reason, so I can't view it. 
give your "func_door" a targetname of "xxx" and then create a "trigger_counter" with a targetname of "yyy". Set the count of the "trigger_counter" to 2 and give it a target of "xxx" (same as the targetname of the "func_door"). Then give both buttons a target of "yyy" (same as the targetname of the "trigger_counter") and your done. 
OutLook Express, Eh. 
Of all the programs to complain about viruses. I checked that zip package with Avast antivirus before sending it out. I'm pretty carefull about that sort of thing.

But I'll just upload it to the geocities site when I get back in this afternoon. 
Cheers, that would be cool. 
Instead of clipping hulls like quake and half-life use, quake 2 and quake 3 store the original brushes from the map file and use those for collision. This is why monsters in quake 2 can be all different sizes.

How this works is, clipping hulls are basically bsps built out of pre-expanded brushes. Since they are pre-expanded, they are built for specific entity sizes. But in quake2 and 3, the brushes are expanded on the fly, which means they can be expanded differently for each entity size they encounter. 
thanks man. will go try that now. :) 
Thanks Metlslime 
That sounds very interesting. Q3 bsp is definately an option I will look into, although not for my current map; perhaps the one after that. 
And More Newbie-ism 
ok. it worked. but i cant get the door to stay closed! i gave it a 0 delay but it keeps closing. it works with a regular door but with this one it doesnt seem to work. :( 
It's the [q]wait[/i] field that determines the wait before closing. Set it to [q]-1[/q] if you don't want it to close. 
beautiful!! thanks guys, you been really helpful. :) 
No Problem 
what kind of a map are you working on? Any info or screenshots anywhere? 
actually, i havent started anything yet. just trying out stuff and seeing what i can do before i get my hands into something serious. 
'That sounds very interesting. Q3 bsp is definately an option I will look into, although not for my current map; perhaps the one after that.'

I share your sentiments. My current out put targets FitzQuake given high rez (non-palated) textures and good light sampling looks fantastic in it. Also, most lower end machines can handle it without a performance hit (though I'm less certain about those first generation Voodoo cards).

By the time I'm finished with it, I'll be targeting Doom 3 anyway. So the grand Dark Places mod I have had in mind for some time will likely never come to light. 
Yes, Doom3 looks like a really attractive option for me too. So far I've missed the boat with all the other id games, so with D3 I might get a chance to start mapping at the beginning with everyone else. Although I'd be making Evil Gothic Death Castles (tm) - I'm not sure I really dig the idea of making endless crate-tastic base levels.

I downloaded your dptest level, but when I load it in DarkPlaces, the whole level is pitch black (r_fullbright 1 does nothing) Also, I can see all the ammo/health boxes in the level at once, dotted around in space like some wierd ammo box constellation. What version of DP are you using? 
I Ran It Using The Resized Textures 
and the lighting doesn't show up. It must have something to do with my texture/lightmap experiments. Rename the texture file Venice so DP doesn't read it in and the lighting will show up.

I use the beta available on but modified with my own code (mostly to do with entity behavoir and interpolation so it should not effect the light display, in theory). 
groovy. mail sent :) 
Clipper Tool Uses Caulk 
In what scenerio would it be useful to tic "Clipper tool uses caulk"? 
When you build things that are entirely detail brushes, and you have most of the sides caulked already. The idea is that you want any new face to also be caulked until you tell radiant otherwise.

Maybe not so useful the way q3 tools handle detail, but very useful the way MoH tools handle detail. 
Q1 Tools Update 
at . Main feature is new/updated Win/GLQuake engines especially made for mappers. Please also see readmes for more details.

Any comments are welcome. 
Q1 Tools Update 
at . Main feature is new/updated Win/GLQuake engines especially made for mappers. Please also see readmes for more details.

Any comments are welcome. 
I was trying to build a praxinoscoop in Quake1.
I used the Hipnotic Mission pack for it.
After trying, I realized the func_rotate_object can't make enough speed, to melt the pictures together.

Is there an option for making it turn faster? 
a small change in the engines, I'm now finally able to play sm20_amrik, ne_os1 and others the way they were intended to.

One-Hundred-And-Eighty-Two shamblers to go ... 
No Patch/Bevel Love 
Gah, got a prob in doomedit (although I'm sure its a common thing, just dunno what to do) -- got a patch and a bevel set for it, but the bevel doesnt line up with the patch =( Its like at a lower scale or something, even though it meeta right at the end of the patch its supposed to be hitched on.

Anyone got an tip? 
More Clipnodes 
(Quake1) Do bmodels add to the number of clipnodes in a map? 
I'm Not Sure 
but I think they do since they appear in the clipping hulls 1/2 where the clipnodes originate from.

One easy way to check in your map would be to add the qbsp -noents option which will remove all entities except world and players and see if the # clipnodes change. 
I'll try that :) 
...add clipnodes ( unless they're func_illusionarys, for obvious reasons ). I know this because I tried to make my terrain into one big func_wall an the clipnode count went orbital, preventing the map from loading. 
Yep, I've just discovered that.

The good news is, my clipnodes are almost below the threshold now, after spending weeks doing nothing but optimising the brushwork and smearing everywhere with clip brushes.

Nearly there! 
...and smearing everywhere with clip brushes

Hehe, just struck me as funny. 
Did you get my last two emails? 
Yes indeed. It just takes me time to reply, cos I have to go home and extract stuff and walk back to the 'netcafe then remember I need to visit an ATM get the idea :P

Mail imminent, btw. 
Compiling Help Plz 
I was looking for a GTK q1 map compiler
that dosen't use java. I thought i saw a
version which didn't require java.
Any help.
thanks in advance. 
I believe GTK 1.5 supports q1 "out of the box". 
GTK 1.5?
I only see 1.4. 
GOD BLESS YOU!!!!!!!!!!! 
Life is good....
Now if i can only learn to map like others.
Thanks for the HELP.
what's the deal with 1.5?
when you say "much has changed" how much is much?

i realise the chief change in 1.5 is that you can load q1 .maps and load q1 .wads, but what about the controls? are they the same?

i still use 1.4 because using batch files and converting the q2 map files into q1 before compile really doesn't bother. how much am i gaining by switching over? 
necros - well, hehe, I'm a Hammer user atm, so I don't actually use GTK, but I follow its development because I will be using it to make my next map - which will be a Q3BSP for DarkPlaces. I'm sure there are plenty of 1.5 users here though that will be happy to explain the changes.

h20ryder - you're welcome! 
Question For Necros 
Your using 1.4?
What do you use for compliling may i ask.
That was my original question..

I'm going to try 1.5 anyway. 
well, i map as normal in 1.4, saving the map file as a q3 map.

since the file format difference between q3 and q2 is practically zero, i use sleepwalkR's mapconv utility to convert the .map into a q1 map file.

then i use aguire's compile tools ( ) as i normally would on a q1 map.

all of this is up in a bunch of different batch files, so i just type "quick map" and it does all the stuff to :) 
sorry for the double post.

i've got a map with 32unit thick bars every 32 units, so there are gaps in between these bars of 32 units. on the floor.

monsters won't cross over these gaps when running/walking. even if there is a clip brush which overlaps these bars and gaps.

what gives? i thought the clip brush basically added the collision data to hull1 and hull2... so why do the monsters still treat the area as if there were gaps in them? 
Yes! I've been meaning to ask this very same question - I noticed it in Bastion, and other maps and it has always bothered me. 
A Guess 
it must be something to do with tracelines in the movetogoal code only using hull0 or something. 
Part of the code that monsters use to do pathfinding uses hull0, i think. 
Could anyone point me to some basic tutorials on D3 mapping preferably non video ones as my poor 56kb wouldn't like it. 
Could someone tell me how to open the texture window with actual textures in. 
3rd Post :( 
Scrap that, got it all working, yes I suck. 
I've seen some really good tutorials on map scripting (like how to get custom machines to animate properly) at

Also, , has a forum to help level designers specifically on multiplayer matters. 
Have a dig around this site/forums, you should find some useful stuff. 
sorry, didn't see it already above in HT's post 
Anyone Using GTK 1.5 Texture Select Problem 
I like being able to load wads into the editor without all the fuss. However in 1.5 i am unable to select a single face to change the textures. Is this a bug? Or is it me.
Thanks in advance.
RE: Anyone Using GTK 1.5 Texture Select Problem 
i hacky way to get monsters to cross gaps in the floor is to make an invisible func_wall entity (like hipnotic's func_togglewall)
that way, you still can't see it, but tracelines *will* impact on it's surface.

the downside is that you can't shoot through the gaps anymore, and gibs will land on them as well...

i suppose it could be possible to make an entity somehow toggle on and off depending on if a rocket was touching it or not, but i doubt that would work well... 
i get allocblock: Full.

now, i know this has to do with lightmaps and sealing the map usuall helps, but this is a little different than normal.

the map is still very small, only 1000 brushes or so. i've had maps that were 3000 or so brushes, unsealed with tons of lights without bothering quake a bit.
this map only has half a dozen or so lights.

also, i noticed the light compile time took much longer than normal. a few versions ago, it was lighting in about 1 sec while on this attempt it took 10 seconds.

aguire: this might be some issue with the actual light utility (or something i did which made an issue with the light utility) so i'm going to be messing around with stuff a bit to see what i can do.

thought you'd like to know or you might know what to do? 
got a Gl_buildlightmaps error: excessive lightmaps 67 (normal max = 64) 
Fuck, We Need Edit! :P 
edit2: that error appeared even when i *didn't* light the map at all. how can there be lightmaps when i didn't even have them calculated? 
Last One For A While Now... 
figured out what was wrong... had one of those huge/infinite brushes, so the face count went crazy. never mind... :P 
Allocblock: Full 
Is a brush error. Try to load the .map file in a few different editors to see if some brushes don't load.

If that doesn't work, try to delete any brushes you added recently that have weird manipulations.

Also, look for microscopic OR gigantic brushes in the .map file. (in a text editor) 
Is it possible for you to try to reduce the chance of appearing of HOMs in the next version of your QBSP tools?

Or at least explain me why HOMs appear in places where they haven't been before after I place some more brushes in the room. Or does it have no explanation? 
When a HOM is on the surface of a brush and is not affected by VIS, I've found that it will usually fix the problem if I make sure all the edges and vertices meet perfectly where the HOM occurs. 
This may (or maynot) help you. Have a read of the "tooltips.txt" on AguirRe's site, scroll down to "Portal Problems"
Direct Link to ToolTips

AguirRe's Site 
I assume the first error message was when you were not using any of my engines, the warning you got when using one of my engines, is that right?

The AllocBlock: full error has no relation to whether the map is lit or not or how many lights or brushes there are.

It's only related to having very large visible brush faces (planes) in the map that the GL engines need to allocate space for. Too large and too many of these faces will sooner or later exceed the lightmap array (normal size 64, in my GLQuake it's 512).

Software engines Win/TyrQuake don't have this problem at all. 
what RPG and VoreLord said; check out brush alignment in the area and my ToolTips doc (Portal Problems section).

If you still can't fix the HOMs, please send me the zipped map+wad and I'll take a look at it. 
hehe, should have specified. :P

i was using fitzquake when it crashed with the error, so i loaded it up with your [aguire's] quake engine. man, i love that engine. ^_^

i didn't know that about the lightmaps. i just assumed if there wasn't any lighting, that the lightmap would be zero (making quake default to fullbright)

also, is it possible to make your vis and light start with different priorities like your qbsp does? it'd be nice to make light and vis always use 'belownormal' priority. :) 
I only added that possibility to qbsp since it's normally so fast that you don't have time to manually use Task Manager to change the priority of the process.

I have a small utility that you can use to start any Win32 console program with a specified priority and optionally with a timeout to wait for completion. After the timeout expires, it will kill the child process (useful when it might get stuck).

I'll email you this small utility. 
Ok, I Give Up (GTK 1.5) 
Could someone please explain to this dimwhitted australian, how I am to get the textures to show up (Quake). I mean, nothing shows up in the texture menu, so I can't load any textures. I can however type the texture name in the surface inspector and have it applied to the face I have selected. but I refuse to beleive that this has to be done all the time. Everything works fine when I load GTK 1.5 for Quake 3, or DooM3, but for Quake, well I can't seem to get it.

Please, anyone, anyone ? 
Just in time to, I was about to see how much of a mess a 21" monitor would make after being hit by a high speed mouse. 
When a HOM is on the surface of a brush and is not affected by VIS, I've found that it will usually fix the problem if I make sure all the edges and vertices meet perfectly where the HOM occurs.

It really helps. I've splitted the brush into two ones so that edges and vertices were exactly where HOM took place and it has gone. 
Quake 3 Elevator 
I am looking into making an elevator in quake3 but HOW is it done? i used the func plat and it moves up about 1 block and not any do i set the height it moves up or just make a simple elevator
Is your planetquake email address OK or should I use another? I heard Tyrann had a lot of problems with his. 
i have no idea, but apparently, i didn't get anything. :\ pq mail has never been very reliable...

send it directly to necros -AT-, that should be fairly reliable. 
Singleplayer Start Help 
I am having problems getting a few enitys to work in my start setskill, etc.
Anyway does anyone have a tut for starting sp mapping, with a list of all the spawnflags and such... i am trying GTK 1.50 nightly...
The spawnflags don't seem to all be there.
I also need to know how to define an episode beginning to end... also is 'print' a valid spawnflag as in q2?
Thanks in advance.
I sent a copy today to that address too but got some weird warning about "delayed email" in return.

Anyway, you can get the file from .

Please let me know when you've got it. 
Re: Quake 3 Elevator 
Rising platform the player can ride to reach higher places. Plats must always be drawn in the raised position, so they will operate and be lighted correctly but they spawn in the lowered position. The plat will stay in the raised position until the player steps off. There are no proper sounds for this entity, only beep noises. It will spawn in the game and work properly but it sounds silly (see Notes).
-------- KEYS --------
speed : determines how fast the plat moves (default 150).
lip : lip remaining at end of move (default 16). Has no effect if "height" is set.
height : if set, this will determine the total amount of vertical travel of the plat.
dmg : damage to inflict on player when he blocks operation of plat (default 4). Plat will reverse direction when blocked.
targetname : if set, the trigger that points to this will raise the plat each time it fires. The plat raises and comes back down a second later if no player is on it.
<snip> <snip> <snip>
-------- NOTES --------
By default, the total amount of vertical travel of a platform is implicitly determined by the overall vertical size of the brushes of which it's made minus the lip value. But if the "height" key is used, then the total amount of vertical travel of the plat will be exactly that value regardless of the shape and size of the plat and regardless of the value of the "lip" key. Using the "height" key is the best method for any kind of platforms and the only possible one for thin plats which need to travel vertical distances many times their own thickness. Setting the origin key is simply an alternate method to using an origin brush. When using the model2 key, the origin point of the model will correspond to the origin point defined by either the origin brush or the origin coordinate value.

<snip> <snip> <snip>

This should help you out. Basically, the func_plat follows a formula to determine how high it moves. X - L = H. X is the overall height of the func_plat entity, L is the "lip" value, and H is the height the func_plat will move when the player steps on it. So if the func_plat is 64 units tall, and the "lip" is set to "8", then it only moves up 56 units. You can override this by setting the "height" key. If "height" is set to "256", then the func_plat should move 256 units up.

Also, you should make sure you set the direction of the func_plat to "up". 
i got the email.

i couldn't get the thing to work though.

in my batch file i was using priority below vis %1 %2 %3 %4 %5

but it didn't seem to do anything. is it that hard to make priority settings available in vis.exe itself? 
Re: Singleplayer Start Help 
You'll need a Quake1 entities.def for making Q1SP maps. I'm not sure where you can get one online right now.

I'll see if I can get SPoG to start reading this thread, since there are some GTKRadiant 1.5 questions that he would be most suited to answering.

Episodes are pretty much only defined as a looping set of maps. I.E. at the end of each map, have a trigger_changelevel that has a "map" "nextmapname" key/value pair. If you want to have full out episodes like Quake did, then you'll need a start map with func_episodegates blocking off various episode teleporters, and the appropriate spawnflags for each episodegate. Then each map links to the next in the trigger_changelevel, and at the end of each episode you need an item_sigil with one of the spawnflags checked. And the trigger_changelevel in last map of each episode should link back to the start map.

I don't remember a "print" spawnflag for any Q1 entities. 
i wrote a little guide a while ago that should have everything you need to map for q1 with gtkr1.4

since you're using 1.5, you can still download the .def file from there. 
Direct Link: 
What do you mean by "didn't seem to do anything", didn't it run the vis program with its parameters %1 %2 %3 etc at the specified thread priority? Maybe you forgot adding the parameters to the batch file command?

It's not hard to implement, but I see no reason since this utility does the same job without any cost at all.

If you still can't get it to work, please send me the batch file and a description how you call it. 
are there any fgd files for worldcraft 2.0 or maybe hammer that would let me map for heretic2? im so used to worldcraft im too lazy to learn the one that comes with the game, and i have no idea how to make a fdg for worldcraft. :( 
Stone That Heretic 
i'd kiss you... but i dont know if you like aids. :( 
Yeah, I got your original mail. Please note that I have very limited net access and I'm a bit snowed under with content, so I tend not to reply instantly to emails. 
Light Shader Problem 
thought I would post this here too, can't figure this out. Didn't feel like reformating this post, go to the link below. 
No problem, I just don't trust Internet email much anymore. To avoid both parties waiting for responses that never come, I'd rather run the risk of being a bit repetitive.

Btw, I've been running a fullvis on the terrain map for about 78 hours now. It has reached 88%, claims that there are 13 hours to go and half an hour ago it even crashed my RVis ...

/me consults the good Dr Watson 
78hrs VIS?! Um what are you mapping for? 
the line in the batch file:

priority below vis %1 %2 %3 %4 %5

command line:
privis -level 4 map

starts vising the map, but when i check in task manager, vis.exe is assigned the 'normal' priority.

that's what i meant by "does nothing"... any suggestions? 
GTKRadiant 1.5 Docs 
BTW, anyone using GTKRadiant 1.5 may want to check out SmallPileofGibs' docs on the subject:

I've asked him to keep an eye on this thread, so hopefully he'll see when a new question is brought up, and he can let us know when the docs are updated. 
every point in the 'transition' section has convinced me not to switch to the newer version.

'select complete tall' was one of the best features of gtkr, because you could size the selector brush to exactly the right size before selecting the other brushes. 
Holding shift and dragging LMB will create a selection area in the 2D views. Not exactly the same functionality as Select Complete Tall, Select Partial Tall, Select Inside, and Select Touching, but it's better than none. 
Thanks for the clarification. You can't use NT/2K/XP Task Manager for checking the thread priority; it only shows the process priority which is of a higher magnitude than the thread variant.

Changing the process priority is actually pretty dangerous if you make a mistake; setting the priority High or even worse Critical for a process like RVis and you'll most likely have to use the power off button to access your system again (or wait until RVis finishes).

Setting the thread priority like my utility does (or via the qbsp option), is much safer and most of the time gets the job done just as well.

Either you'll have to use another instrument for checking thread priority (e.g. TaskInfo ), start another CPU intensive process and confirm that it will now take over the CPU completely or just take my word for it.

Btw, in the upcoming versions of RVis/Light, there'll be a -priority option ... 
Just as a good example of Internet email reliability, I just received another copy of your Aug 4th email ... 
I'm not mapping, only testing a Q1 map for Kell. 78 hours is not that much; I've a personal record of 350h (2 weeks) on a P4 1.7GHz and Scragbait has run a 550h (3 weeks) session on an even faster machine.

Open maps are slow to fullvis ... 
lol.. i think thats why I didn't like Q1 mapping, spent longer compiling than mapping. I love me detail brushes, my current Q3 map which consists of about 3000 brushes and is of decent size currently fullvis is 19 seconds. :) 
Detail Brushes 
didn't someone have some sort of experimental bsp compiler with detail brush type support for q1? Or am I imagining things... 
Re: Process Priority 
Yeah, just for kicks when you guys started mentioning this in here, I changed a running vis of sm82 to something ridiculous like high or realtime. Didn't make it go any faster, but rather sent my system to 100% cpu use rendering it unuseable until it finished. Won't be doing that anytime soon. 
Heh, you just had to try it, right?

Task priorites are often a cause of confusion, some even seems to think it's some kind of gas pedal. For best results, always lower the priority of a process, especially if it's hogging the CPU, like RVis or Light.

Raising a priority should only be done for processes that often block on external I/O events, like disk or network. Most of the time it's also only useful to raise it just a little bit.

If you e.g. try running an RVis session in normal priority and at the same time copy a big file over the network, you'll probably notice that the copy process is much slower than usual.

In this case, it would significantly speed up the copy operation if that program/process/thread had a slightly higher priority than normal without the RVis session suffering much of a slowdown. 
For the record, I was pretty sure it would make no difference. Although if there was some internal thread-yielding, that would make more of a difference I'd imagine.

A question I've been considering for a while to you, mister aguire the quake tools master. What is the feasibility of making a networked vis tool? I know tools like netvis have existed for other games (halflife in particular), so I'm wondering if its possible for quake1. I don't know much of the mechanics of how visibility is processed but I've done enough tcp/ip programming that I think I could handle that side of things.

Note: I'm not talking about a cluster of computers sharing processes and memory and stuff, just N number of computers running a client, with one master initiating the process and handling dispatching data to be processed.

It's certainly possible (most things are). Vis originally had a threading capability to utilize multiprocessor systems (I think id had dual Sparcs).

IMO, it would've been much more beneficial for most people if they'd concentrated more on the algorithms, memory handling etc. Qbsp had ridiculously many memory leaks and Tyrann has shown that the algorithms could be improved quite a bit, especially in worst case scenarios.

If id had implemented the "meta-leaf" (i.e. clustering small detail leafs into bigger ones) variant of vis, it'd would probably be a lot faster in big maps and most likely much faster than any parallel computing method with a lot less hassle.

Since most people don't have multiprocessor systems or even lots of LAN-connected machines, pretty few would benefit from multithread/netvis solutions. I even doubt that HyperThreading would help much. There are a lot of other factors (heap, disk etc) in the machine that serialize the processing.

In any case, it would add quite a bit of complexity to vis. 
I Concur, AguiRe 
esp. when you take in consideration the speed at which q2map2 can vis, and it does take advantage of the meta-leaf software architecture you mentioned.

Of course, you already know that given you are the Ydnar of Quake I.

Hey, what about pico-model in-map compilation. Now that is some sweet stuff. 
I Use Q3map2 Myself 
I don't think it would require as much overhead as you suggest, but its nice to know it may be possible. Again, I know not eveyone would even be able to use it, but I was thinking it would mainly benefit those vis killing maps that go on for days at a time. Did you remove the -threads option from your vis version(s)? That would be a good starting point should I decide to investigate this at some point in time. 
Yes, I've removed the -threads option from all tools since AFAIK, it never worked anyway in the Win32 version.

However, I don't recall having deliberately disabled any basic multithreading functionality, except that I'm pretty sure that the progress feedback wouldn't work. Not to mention AutoSave or ... 
I've a personal record of 350h (2 weeks) on a P4 1.7GHz and Scragbait has run a 550h (3 weeks) session on an even faster machine.

now thats committment to the mapping cause =)
can you remember which maps they were? 
Heh, it's actually the same map in different versions by Scragbait. He can probably tell you a tale or two about this map ...

It's actually not so very big, but he put a large amount of small detail brushwork into it and since it's rather open, vis runs amok. By turning most of these details into func_walls, the fullvis time will drop dramatically (usually 50-90%).

There are drawbacks with this though, mostly regarding lack of shadows and increased r_speeds. Please see my ToolTips for more info. 
Well, I know it would break a few things, and progress reporting still could be done, albeit a little differently. Although it would never be 100% accurate but would be close enough. But possible nonetheless, with a simple protocol between the master and client. 
Thanks, Aguire 
for clearing up that little mixup. i hadn't realised there were different levels of priority like that.

i won't bother checking if it works for vis, i'll take your word for it ;) 
Just start vis in either normal or below priority and then start another heavy process (e.g. Light) in normal and check with Task Manager how much the 2nd process can get from the CPU.

If you want to really make it confusing, you can also put the different processes in foreground (focus with mouse), background or even both in background and see how the CPU load changes in each case.

There's a lot of code in the OS just dealing with this task scheduling and nearly all OS versions have different behaviour ... 
re: openquartz compiler - yeah that's the one. IIRC, it never really did catch on. 
Q1 Detail 
Is there a reason it didn't catch on? The benefits of detail in Q1, considering the size of the last few SP releases, are obvious. I'm sure there are issues here of which I am utterly ignorant.

aguiRe: heh, email si teh awfull
78hrs, huh? That's pretty much around where I was expecting I guess. Though crashing your Rvis is a new event :( 
I've used the detail texture shader from rscript recently in a test of converted IKDoom textures (Ikka's textures ripped from the Reqiuem megawad), and the results were less than disirable. I used Tomaz Quake for my test. MrG has said before that RScript was a less than optimal solution (though it works perfectly fine with alpha channels and the like).

IMHO the custom engine whose shader suppot impressed me the most is QFusion which has no problem processing Q3 shaders for all the pretty things like detail, phong and the like. 
Detail In Q1 
Works like detail in q2 and DOES NOT function like detail/structure in q3 since that depends on changes made to the .bsp format. If I don't remember it all wrong detail in q2 just aids the vis process a bit by first using all non-detail brushes to split up the world and then the detail last. The purpose of this is to simplify the vis data a bit but it's important to not forget that unlike in q3 detail brushes still affect the vis data and splits up faces. 
a more careful reading of your post would have made it obvious you meant detail brushes. My eyes are blurry from mapping -- apologies 
Electric Laser Beam 

In post #2055, MadFox gives me an example of "electric laser beam" use: it was the same used to kill Chtom into last level of Q1 first episode. This link seems to be no longer avalaible today...

I would like to use an "electric laser beam" in my new map (to create some electric effects into a power zone), and I would like to have some information about the use of event_lightning entity, or a map example like MadFox gave me there were few months..

Is there somebody who can help me please ??

if Q1 detail can be done like in Q2, ie. not requiring any changes to the Q1 bsp format, then would it be possible to implement in your compile tools? 
Well, if you're going down that road, you might want to consider using some custom QC - the Scourge of Amagon mission pack has some excellent lightning effects. 
I will send you a zip file which may be of help to you. 
Rvis now reached 96.6% in 111h with still 12 to go (not very likely) ...

The crash wasn't reproducable, and since AutoSave was active, I just restarted and it appears OK now. My HD sometimes act up and slightly corrupt read/write operations and it can cause these anomalies. 
I've just read your e-mail, and it seems that it is exactly what I was looking for...
Thank you very much... 
I have actually investigated a bit into this issue recently. Unfortunately, it seems to require both qbsp and vis specific support (via a new prt file format) and adds quite a bit complexity to both tools.

Since it can't help any existing maps (you'd have to map explicitly for this format), I've decided against it for now. 
Kinn 2 
Have you received my email reply as of today? All my accounts seems to refuse to send it to you for unknown reasons. 
I haven't received it - hotmail tends to randomly bounce emails for no reason from time to time.

However, you can now send stuff to my original email address, as I have set up the account on my crappy computer. 
I've now managed to send [at least] one to each address, let's hope you get one of them.

Btw, I haven't been able to reproduce the abort you mentioned, no matter what I do.

I've uploaded yet a bit newer variant of WQ 1.22 to the same address as before. Please see if you still can reproduce the abort. 
Mail Sent 
I'll have a gander at the new WQ 1.22 :) 
q1 is dead, as this board proves :\/ 
Q1 Is Dead? 
There isn't even a game called "q1", or "Quake 1" for that matter, There is however, games called "Quake", "Quake II", and "Quake III Arena", (plus mission packs of course".

All of which are still showing signs of life, As this board proves 
wasnt quake2 a game on its own that had nothing to do with quake1? i remember reading the planetquake fuck and they said something like this. and if its true, i wish they had named it differntly.

hell yes 
You wrote above "Mail Sent", should I assume that you really meant "Mail Received" and that you haven't yet replied to me? 
No, i did send an email on the 16th, but i'll resend :) 
Re: <blank> 
wasnt quake2 a game on its own that had nothing to do with quake1? i remember reading the planetquake fuck and they said something like this. and if its true, i wish they had named it differntly.

I seem to recall some id guy saying in a .plan that they originally wanted to name it "Wor", but that may have violated someone's trademark so they went with "Quake II". I couldn't find the original .plan though, so I have no source to back up my assertion. 
you have no source to back up your ass 
Fullvis of terrain map is finally done after almost 161 hours. Your original estimation of one week was pretty accurate. Now we at least have a reference for improvements. 
Excellent. Thanks :)

How's the framrate now it's vised...? ( dare I ask ) 
is there anyway you could add these features to your glquake version?
1- gl_clear defaulting to 1, with same grey void color (or at least ability to change it?)
2- in noclip mode, having flymode movement instead of just walking on the plane you are on when you issue the 'noclip' command.

I only ask because most of these I use in fitzquake to debug/leakhunt maps in development, but as I'm working on sm82 its huge visdata crashes most all other engines, so I have been using your glquake.

I've also always thought it would be cool if there was a command that flew the player through the path of the pointfile in order to better hunt down leaks, etc.

Anyways, just some ideas. 
This is an extract from the vis.log:

average leafs visible: 819
max leafs visible: 2198 near (1792 -538 1120)
c_chains: 2193464855
visdatasize: 483 kb compressed from 807 kb
Session time : 160h 44m

Fps depends on the player's system, I didn't have any problems even before vis. What's maybe more interesting is to use the r_draworder cvar of WinQuake to see how far the engine see, especially over rocks. It appears to me that pulling down sky should help in this map. 
You can change the value of cvars in your cfg files at startup (or use a key to set god/notarget/gl_clear etc), I can't see any obvious reason to change the default.

Adding r_clearcolor cvar like WinQuake I can look into (if it's reasonably easy to implement). I actually prefer the bright red; I haven't found any better for leak/HOM hunting.

The noclip behaviour is absolutely my preference, I never liked the Q2 variant. Again, I can see if it's easy to add this alternative (like FQ).

Auto-flying through leak trail sounds a bit esoteric ...

Thanks for the suggestions. 
"The noclip behaviour is absolutely my preference, I never liked the Q2 variant."
You like being stuck at the same height when noclipping? Why? 
if you use gtkr, you can just load the .pts file as a .lin file in the editor to fix leaks. 
If I haven't screwed up the basic CnP job from FQ, r_clearcolor (GL: default 251 = bright red, Win: default 2 = dark grey) and sv_altnoclip (default 0) are now in and seem to be working in both engines.

Jago: Well, for me it's easier to move in noclip like that. If I want to slide up or down at the same time, I just press D/C (swim up/down) as usual. 
average leafs visible: 819
max leafs visible: 2198 near (1792 -538 1120)
c_chains: 2193464855
visdatasize: 483 kb compressed from 807 kb
Session time : 160h 44m

Hello, I have a similar message after a fast vis process for my last map, and it's the first time I see this... Is it a real problem, or simply an information message ??? I'm able to run FitzQuake without any HOM/leak problems, and all seems to work correctly, so what must I do (if there's something to do) ???
The Above Info 
is just statistics about the vis run. If you get warnings or errors in your vis printout, either show it here or send it to me and I'll take a look at it. 
I've no warnings/error (thanks to the Lord) during any process, and the above informations appeared after a "long" fastvis process... It appeared yesterday night, so I was a little confused seeing these messages...
Well, it's not a real problem in your opinion... anyway, thank you for your help... 
Re: 2392 
wor? hehe. it would have nice it they had used stroggos or something. im still sad about it them using quake2. but then, there is gonna be a quake4! fuck yes! 
How Did That Rule Go? 
The even numbered Quakes suck? 
D3 Mapping 
um... this may seem like a stupid question, but how does one map for d3 with gtkradiant, and not the built in gtk/qeradiant version in d3? 
Not that I think Quake II sucked, although it would be my least fav Quake, lets hope the "rule" gets broken with #4 
you can't GTKRadiant doesn't have any support for D3. There is a version in the works with D3 support, and a beta version Ive seen going around but its seriously broke right now and not working using.

I would imagine will probably be 2-3 months until a good working build of GTKR is out with D3 support. 
working = worth
Q1 Tools Update 
at . Main feature is updated Win/GLQuake engines with very high capacity and many fixes/improvements. Please also see readmes for more details.

Any comments are welcome. 
Re: Even Numbered Quakes Suck 
Some people would simply say that numbered Quakes suck. 
Re: GTKRadiant Doom 3 Support 
The new version (1.5) has support for Doom 3. There are indeed a few things broken, but that's not the biggest problem users will have. The biggest problem is that the interface has changed substantially, and old users will have trouble adapting.

You can get GTKRadiant 1.5 from

The limited docs are available here: 
Yeah... I Know... 
i've been trying just to map for q1 with the thing (1.5) and it's just not going very well... why the hell did they have to go and change such a good thing? :( 
My computer situation is fixed now. If you've sent any emails in the last 3 days or so to my V21 address, could you possibly resend to my hotmail address? 
GTKR 1.5 
The biggest problem is that the interface has changed substantially
Yes. It's broken. :( 
Have you still not received anything? I sent copies to both your accounts yesterday. 
Old QMap Threads 
Does anyone have any archived threads from the old QMap? I have the "Mapping Help" thread already, but there were many others. 
AguirRe - Mail Sent 
sorry, V21 is still chuffing me about, but I got it through on the hotmail account.

btw, my new (non-hotmail) addy is: bdwooding -at- 
GtkR 1.5.x is unuseable for experienced radiant users. You'd be better off using the editor included with Doom3 for the moment, and wait till

a) proper/full D3 support is ready in GtkR

b) Spog finally bites the bullet and puts the brush manipulation controls back to how they were (c'mon man, you know it was better that way, and 99.8% of Radiant users have told you that... so wtf?) 
GtkR 1.5.x 
I�ve been using it for over a month now (for Quake 1 mapping) and I�ve been really happy so far. I switched from WorldCraft 1.6 (having used GTKRadiant 1.2 and 1.4 for some Q3 maps that were never released) and I am one of those who actually *DID LIKE* the changes made to the interface. 
Stupid Q3 Question 
How do I make the aas file? 
Never mind. 
I'm currently mapping a base-based map, and I would like to use event_lightning item. I had last week 2 helpfull map examples from MadFox and VoreLord (thanks to them) of event_lightning use ... This work this time but... lightning effect is not permanent.. I mean that it occurs only during a half second and then disappear.. I've alreadyt set a wait -1 into func_button and func_door that respectively command and generate the lightning... so what's the problem ?? Is there a wait -1 missing into the event_lightning item, or somthing like this ?? Any good idea is welcomed ..
opening e1m7 in QuArK and inspect the relationship between the buttons and lightning mechanism. Although that lightning is also just a short time, maybe you can't have a permanent effect? AFAIK, it bogs down engines too. 
Thanks for this advice... I will take a look this evening...
During the game I am able to generate a lightning between two doors (like in e1m7, so i think I build it correctly), but the effect is not permanent, and that's what I would like to have... hhhmmm maybe in Quake C code I can find event_lightning processing and find how to build what I want...
.... I've just took a look at and it seems that event_lightning time is limited, but nowhere I found its limitation... the more I'm not very good in C programation... Sure someone else will have less problem than me, so is there a noble man to help me, just take a look, and tell me something interseting can be found please ??
Re: GTKR 1.5 
I switched from WorldCraft 1.6

Ah, that would explain it. Overly modal interfaces are not among my favourite things. D3R adds a nifty feature - you can obviate the clipper mode entirely by using ctrl+rmb to drop clip points. 
I'm sorry to tell you, but I don't think you can have the event_lightning constantly on. 
Unfortunately, that's what I suspected... And it means that I need to change my map design.... gggrrrrrr....
Thanks for your opinion... 
I used GTKr 1.5 after years of using Q3/GTKr for my Quake3 mapping and WC 1.6 for for Q1 mapping. I've found it's UI to work fine and seriously don't understand what people's problem is with it. Once you get used to it, you'll be just as fast as you were with old style radiant.

For referance, my final few q1 speedmaps were done using GTKr 1.5.

As for it's use in d3... well, it's still pretty limited, and for all it's nice points, d3edit's ability for realtime rendering and all it's other features tied into the engine make it the clear choice atm. Time will tell how well it'll be updated. 
is there a way to stop d3edit from screwing up my desktop's colour/gamma settings then? that is the main reason i don't want to use d3edit because everytime i'm finished with it, and close it, the default gamma setting is set too high, and even if i change it back in display properties, as soon as the screen is switched to full screen (from any game) back to windows mode, the gamma is back up high like before...

i use Doom3.exe +r_fullscreen 0 +vid_restart +wait +wait +wait +wait +editor to get a windowed mode. 
Try these:

1. Some triggering thing with
"target" "A"

2. trigger_relay with
"targetname" "A"
"target" "B"

3. trigger_relay with
"targetname" "B"
"target" "A"
"delay" "1"

4. event_lightning with
"targetname" "B"

and any other fields required.

What happens is that your button or whatever trips both the lightning (at the start) and starts the two trigger_relays into repeatedly triggering each other. Doing so repeatedly fires the lightning. 
NaturalSelection came with a resetgamma.exe file. I didn't play the mod for so long but I still cherish the gamma hack for the rare times q3 crashes or something. Find me in #tf >4hours from now and ask me for it. 
Or Use Setgamma 
Or Use A Couple Of Commandline Thingamajigs 
For instance,
+r_gamma 1 +r_brightness 1 
I'm happy you seem to be able to use 1.5 easily (personally I consider it unuseable after earlier versions). But the simple fact is, some tasks take longer or take more steps. It was unecessary to change the brush manipulation stuff (if it ain't broke, don't fix it!). The new brush controls might make it easier to learn the editor or might make it more comfortable for maya/wordlcraft/whatever users to adjust...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

x p
x x x

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

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

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

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

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

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

Kinn: I didn't use KillTarget.

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

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

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

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

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

All good ideas and advices are welcomed.. thanx

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

And sound, or not to worry about that?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Add one default light = 125 clipnodes and 48 marksurfaces.

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

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

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

basically you can use my code:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

your choice of emoticon is a bit odd ...

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

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

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

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

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

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

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

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

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

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

really medieval? 
really medieval?

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

It still produces better results than QuArk.

/me finishes Kinn with proctoscope dammit

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

thanks to practoscopes of the world!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Don't tell me you paid money for that.

Strange behaviour for a good editor program.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Increasing this buffer might cause net protocol incompatibility.

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

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

*Kinn is now also known as Apollo

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Any clues?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

What is RTFM?

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

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

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

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

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

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

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

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

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

*LAVA1 255 255 255 50

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

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

I have no current plans to include this functionality.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Depending on your needs though, that may be ok.

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

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

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

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

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

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

"classname"" "Worldspawn"?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Always Backup Your Maps*

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

bdwooding - at - gmail - dot - com

thanks :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Here is a screenshot of GtkRadiant:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

WARNING: Brush with duplicate plane on line XXX

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Metlslime: thanks. 
Re: Compilers 
Arghrad definitely.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

set 'pitch yaw roll'

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

this is not a matter of standing still.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Check shots from:

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

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

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

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

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

Thanks in advance :) 
Do Not Use 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ummm, don't know if this helps? 
It helps for sure... while I already see that Nemesis web site is down... grrr...
For mu first test, I tried to create th