... that's really useful information. I am able to open my map files with my humble text editor (Leafpad) and now I can simply find and replace textures if I suddenly decide to use a different texture on 1000 faces. Thanks! 

Checkout jEdit some day, it rules!

Leafpad has some nasty undo bugs that can corrupt everything iirc. 

What is the upper limit (if any) to the number of brushes one can have in a Quake map? I'm not even done with one third of my map's basic layout and there's a lot of detail to be added, and already I've got ~800 brushes ... at this rate I'm going to have thousands of brushes by the time I'm done. Should I be worried?

PS: Thanks, Spirit. I'll check it out. 

I don't think there is a limit. The limits exist in the resulting BSP file. 

The standard bsp format is bsp29.

There's a newer one called BSP2 which needs support from compilers like Tyrann's: http://www.disenchant.net/

Where you need the -bsp2 switch to make it compile.

There is a size limit on how far away from the world 0,0 you can get - if the player leaves this volume in game then strange things happen. Can't remember the distance.

Finally, the most difficult limit to overcome is your own sanity. Slaving away on a gigantic BSP2 monstrosity is not for the faint hearted and can quickly suck the fun out of mapping if you let it. 

 

To clarify:

There's are various limits to what can be compiled into a working bsp that you can play. Most of these are based on the hardware that was available in 1996. Things like how many entities and so on.

These limits, all apart from the +/-4096, can be removed if you use the BSP2 format.

For a beginner though, you really want to avoid that - keep it small and fun to start with. 

Thanks for the info, ijed and Scampie. Does that mean anything with +4096 or -4096 as at least one of its x/y/z coordinates is too far away? (I assume it does not mean that 68 719 476 736 is the maximum distance.)

I did start with something that was very tiny, but it was pointless to play. Now I'm trying to create something that would be reasonably enjoyable to play while looking fairly decent -- so not trying to make the next ne_ruins or something_wicked, but hopefully something not completely broken and somewhat better looking than beach1 or rohling. It just seems to have taken on a life -- and scale -- of its own... 

Though AFAIK you can go over if you've got a the right editor/compiler. Which compilers allow you to go outside of that space? 

And I think most other modern compilers will build the brushes as well.

But the engine doesn't allow you to move around outside of it, instead you get lots of HOM and weird shit.

I've got various vistas and stuff outside the playable area of my current map, but the player never goes there.

4096 from the 0 position (centre of the world) in any direction, up down, left rright, backwards, forwards. 

is there any way to do this on vanilla quake? 

 

Vores are transethnic otherkin. 

Sorry to have to ask this here as I'm sure this is basic knowledge for everyone else, but I can't seem to get sunlight figured out.

From what I've read, I gather I have to add certain properties and values to anything with the classname "worldspawn", which would then make the skybox textures in the map project light -- but so far I haven't been able to get it to work. Possibly I'm leaving important stuff out or using the wrong properties and/or values.

Would someone be so kind as to give me a list of all properties and values to add to worldspawn to get this to work in TrenchBroom? I realise there is a lot one can change and customise and that there is no definitive way of doing this -- but I would like some sort of starting point, where I have at least some sunlight in the map, and can then start toying with the angle, brightness, colour, etc. 

I believe you add the key _sunlight to the worldspawn.

"_sunlight" "n"
Set the brightness of the sunlight coming from an unseen sun in
the sky. Sky brushes (or more accurately bsp leafs with sky
contents) will emit sunlight at an angle specified by the
"_sun_mangle" key. Default 0.


"_sun_mangle" "x y z"
Specifies the direction of sunlight using yaw(x), pitch(y) and
roll(z) in degrees. Yaw specifies the angle around the Z-axis
from 0 to 359 degrees and pitch specifies the angle from 90
(straight up) to -90 (straight down). Roll has no effect, so use
any value (e.g. 0). Default is straight down ("0 -90 0").


"_sunlight_color" "r g b"
Specify red(r), green(g) and blue(b) components for the colour
of the sunlight. RGB component values are between 0 and 255.
Default is white light ("255 255 255"). 

_sun_mangle 128 -64 0
_sunlight 100
_sunlight_color 64 192 255

This should make a blue sun light come down 

Thanks very much, FifthElephant, but for some reason that still isn't working. Odd. I have no trouble getting light to work when placing light entities in my map, but sunlight does absolutely nothing -- it just looks like an unlit map.

I must be doing something wrong.

On an only marginally related note, can someone explain to me what this means?:

WARNING: CutNodePortals_r:new portal was clipped away 

Are you using a light tool that supports sunlight? What light tool are you using? 

It's LordHavoc's hmap2, which is a compiler with built-in light and vis functions. 

But maybe it does things differently from other light tools? I just had another look at the readme, and this is what it says about light:

usage: hmap2 -light [options] bspfile
Compiles lighting data in a .bsp and also makes .lit colored lighting data
Quick usage notes for entities: (place these in key/value pairs)
wait - falloff rate: 1.0 default, 0.5 = double radius, 2 = half radius
_color - red green blue, specifies color of light, example 1 0.6 0.3 is orange
_lightradius - forces light to be this radius (useful with 1/ types)
delay - light type: (x = distance of surface from light, r = radius)
0: 1-(x/r) fast, quake lighting, the default, tyrlite compatible
1: 1/(x) slow, tyrlite compatible
2: 1/(x*x) slow, realistic, tyrlite compatible
3: 1 fast, no fade, useful for sky lights, tyrlite compatible
4: sun slow, directional sunlight, uses target direction like spotlights
5: 1-x/r*x/r fast, looks like darkplaces/tenebrae lights
What the options do:
-extra antialiased lighting, takes much longer, higher quality
-extra4x4 antialiased lighting, even slower and better than -extra
-extra8x8 antialiased lighting, even slower and better than -extra4x4
-nolightvis disables use of visibility data to optimize lighting
-relight make a .lit file for an existing .bsp without modifying the .bsp
-harshshade harsh shading rather than the normal soft shading
Options from here on are incompatible with darkplaces realtime lighting mode
(it does not know if these options are used, and will require manual rtlights
editing to look good)
-intensity scales brightness of all lights
-radiusscale scales size of all lights (including 1/ types)
-defaulttype <number> sets default light type by number, see delay above
-overridetypes forces all lights to use the -defaulttype setting
-minlight raises darkest areas of the map to this light level (0-255)
-ambientlight raises all of the map by this light level (0-255)

So maybe it ignores the settings of the .map file and requires one to set sunlight via the command line?

Or is all of that stuff jut about coloured lighting? 

I use tyranns light tools combined with necros compiling gui. I can't really see a reason to use anything else. 

which I finally figured out. So I recompiled using qbsp and then I ran light, like this: ./light mapname

Once again, all my light entities work, but there's no sunlight in the map (despite my using the exact values from post 14047), and areas where I put no light entities yet are surrounded by sky brushes, are pitch black.

What am I doing wrong? 

What version of trenchbroom are you using? For me, snap to grid just reduces the grid size to pixel size. 

not just one face? 

That is the case; the entire brush is textured with sky texture.