nico: dunno about distrans' solution, but it sounds strange to me to have proper sky brushes on all sides but a solid bottom...
as for the trigger_hurts - upscale their texture (to 99) to reduce light times.

vondur: huh? sky faces, at least in sky cubes, are only split into two polys anyway, so what's that trick about?

bambuz: sky textures are not affected by scaling iirc. the outside faces are always solid, shoot at the sky with the shotgun and showtris on. making only one face sky texured destroys the transparency. being able to look through sky brushes from the outside is a feature of fitzquake (thus client related).
there was a similar discussion before - better read the corresponding posts by aguirre some ## above. 

Thanks distrans, vondur and neg!ke for the hints (vondur is taking time out from world domination to speak to me, wow).

oh mighty one, can u explain what you meant by "fit one sky texture to the one side of the sky cube"? use sky texture only for the inside? or scale them?

neg!ke of the speedmappery, how would you go about the lighting of scrags in the void if you dunno about distrans' spotlight solution?

anyway, I hope to be mapping away soon. I just learned how to copy and paste properly and as a result nearly shot myself (lucky I "don't have a gun"). arrgh. so much time wasted.

when u guys speedmap, just how excessively do you use copy and paste? do you grab some brush that looks approximately like what you need, c and p it and just modify it slightly? Or are most of the brushes in your maps newly created, innocent brushes?

and I suppose when terrain mapping, obscene amounts of copy and paste are used?

also when speedmapping, do you pick a standard wall texture first or do you create the architecture now and texture later? or do u texture as u go?

a side note: oh metlslime, func_msgboard sometimes gives internal server errors like "maximum process count for uid xxxxx reached" or so. just fyi. 

just to make one texture fit entire face of the cube (inner sides of it). but as nek!ge said it might had no difference if you use modern compilers... but i'd fit it anyway ;) 

...I'm not 100% certain, but I believe one needs a solid non sky brush on the bottom for the monster-in-void-spotlight-trick to work.

If it's not required... even better performance! Easy to check & fix once the map is built though. 

Make the bottom brush that actually seals the map area a normal skybrush. Then make another brush that's about as wide as the skybrush, but place it so it's top surface is just below the top surface of the skybrush.
What I did in Chapter's "He Falls Like Lucifer" was to make the skybrushes 64 thick, then make the "black" textured brush 32 thick, and place it inside the bottom skybrush with a gap of 16 all the way around in all three axes.

Light the top of the black brush with spotlights that are set to have a cone less than 180 degrees ( this is so the light they emit only hits the top of the black brush, and doesn't seep up the sides of the actual architecture ).

Overscale the black texture on the inner brush by a lot, and do the same to all the sky texture too. 

hmm, all methods are i thought of turned out to be useless (light entities next to the monsters, well lit spawn rooms, even sun-/ambientlight). the spotlight trick distrans posted works. apparently the important thing for lighting monsters in void maps is that there has to be a solid brush beneath them (not necessarily the bottom of the cube).
iz's quite awkward, but then again maybe also adds some tension when the player can only see the scags once shoot or reach the structure.

copy/paste galore! i rarely create new brushes, most stuff is pasted. mostly because new brushes - at least in quest - always have the size of the texture�, whereas a pasted brush has already one or more dimensions right.
textures have to be applied as you build the wall/room/whatever. if it looks ok, you can move on and copy it around. building the architecture first and texturing it later is more than impractical. 

ah, i see. nice idea. 

Trying to compile my old q1 maps using Sleepy's Map Converter and a .bat, and while some maps compile fine, others get the following message, followed by none of the compile progs doing their jobs and a lot of nothing being accomplished:

Parsing file c:\quake\id1\maps\bleh.map...Exception EConvertError in Modul mapc
onv.exe bei 000077B6.
'' ist kein gⁿltiger Integerwert.

With any new maps I start, it will get up to the 'Parsing file c:\quake\id1\maps\bleh.map...' part, and just stick there. Again, it works fine with other old maps, so I'm thinking everything is set up to work. If anyone else has run into this and has some sort of workaround, I would very much appreciate some help. 

it is finding a floating point number in your map in a place where it expects an integer.

Biff, are you using quoole? Biff, is this true? 

I regret to inform you that this post is almost entirely worthless. The only thing I can say is that I remember getting that error two or three times, and each time it was 6-12 months apart so that I never remembered what the problem was when I encountered it. Since it's been about that length of time, and I don't use Sleepy's tool anymore, I don't remember exactly what the cause was. However, I do remember that each time it happened the problem was something trivial with the .map, and I would subsequently dopeslap myself before moving on.

Some things to check: is the map already in Q1 format? Are you giving the player a message that includes quotation marks? Do you have any crazy brushes with no volume, faces with no area, or other technical problems? (MapSpy could help determine the answer to this last problem.) Are you wearing sweatpants? 

1. No CZG, I am not using "quoole". I stay away from the hard stuff anymore.

2. RPG, what are you using instead of Sleepy's converter?

3. WTF is MapSpy (I'll prolly Google for it in a bit)...?

4. No sweatpants, but a pair of pajama bottoms my cousin and his wife gave me for Christmas. The weather here (as you may well know) has been too damned insane for consistent sweatgear wear. 

I don't know what RPG is using, but AguirRe's compile tools do the conversion for you, you just got to set the switch in you .bat or whatever 

At least the later versions of AguirRe's tools do. 

But I'm not too swift on this .bat stuff: Is it possible for me to stick AguiRe's stuff in a seperate dir than the .wads, and still be able to compile, or do I need to have it all in the /id1 folder (where GTK needs the textures)? 

wad and tools in maps folder
textures extracted (.jpg)in id1/textures/q1_biffs tex

batch file eg,
qbsp.exe -q2map -oldaxis -transwater biffs.map

-q2map being the conversion switcheroo

can you have things in a different dir, dunno, prolly not, but I don't know, I've always only done it the one way, come to think about it, that's prolly why my wife left me, hmmm 

if you put stuff in a different dir, you just need to specify the relative or full path to it in the bat file. Or, you use "cd" to switch to the qbsp dir. But, you might have to add the full or relative path to the map file in that case. 

GTKR 1.5 can save directly to Q1 .map format, which eliminates the need for a pre-compiler like Sleepy's. That's what I'm using.

MapSpy is a very cool program which was originally written to solve a Q2-specific game error, but has been expanded to help track down generic .map errors, such as brushes with no volume, brushes with infinite volume, faces with no area, etc. http://mapspy.gamedesign.net/ No matter how much I tell people to try it, no one seems to use it. I distinctly remember explicitly telling someone it would solve his specific problem, but he still refused to download it and try it for some stupid reason--I think it was because he thought it only worked for Q2 maps, which is simply not the case. When you run the program, just ignore the Q2-specific output and look for any QBSP errors it mentions.

Regarding compiler locations, I have maps, compilers, and maps in id1/maps, and the wads in id1/. From there, I reference the full path of the .wads from the map ("wad" "d:\quake\id1\metal.wad") and just run the .bat compiler from id1\. Here's what the .bat looks like:

set BASEPATH=D:\Quake\workingq

%BASEPATH%\maps\qbsp.exe -oldaxis %BASEPATH%\maps\%1.map

%BASEPATH%\maps\vis.exe -level 4 %BASEPATH%\maps\%1.bsp

%BASEPATH%\maps\tyrlite.exe -nocount -extra -nominlimit %BASEPATH%\maps\%1.bsp 

Got it sorted out, I think -- the .wads in /id1, along with the compile.bat, and the tools in a separate folder. One more question, tho: I'm using AguiRe's stuff, and dunno where along the line to use his Bspinfo prog...

Thanks RPG and the rest, though -- looks like I'll actually be doing some Quake mapping this weekend =D 

put it this way, use it when you need to use it ;) 

I was wondering how the skybox is used in Quake1 maps. Not the regular one, but the same as in Q2. 

Is your email working? 

Is there an easy way to allow monsters to use this: I do not want to use trigger_monsterjump? 

Monsters are effected by trigger_push by default.
They won't actively seek it out in any way, but when they touch it they will be sucked in. 

I'm dropping a spawned ogre onto a trigger_push and he just does his own thing?

If I go onto it, everything is fine... whoosh. But he just runs up and down the length of the trigger and even stops in the middle of it if I no_clip and hover above him.

Any ideas? 

:(