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. 

if you're on windows then best just using this tool -
http://shoresofnis.wordpress.com/utilities/ne_q1spcompilinggui/

Here's a mapfile I made which has the sunlight set up. As long as you're using tyranns tools it should work right -

https://www.dropbox.com/s/afzmvlm0wvs3spt/sunlight.zip 

In Worldcraft you just go Edit -> Map properies, then use the UI to change the values.

Check your .map file.

Here are the first few lines from my honey map jam map (with an example of sunlight):

{
"classname" "worldspawn"
"classname" "worldspawn"
"message" "Yellow Brick Grotto"
"_sunlight" "123"
"gravity" "800"
"sounds" "5"
"light" "12"
"_sunmangle" "40 -45 0"
"_sun_mangle" "45 -45 0"
"fog" "0.03 0.025 0.055 0.14"
"mapversion" "220"
"wad" "\program files\worldcraft\textures\skip.hlwad;\program files\worldcraft\textures\honey.hlwad"
{
( 496 0 -512 ) ( 368 0 -512 ) ( 304 -32 -512 ) CITY2_3 [ 1 0.......

Incidentally, I don't know why the worldspawn is declared twice, it just IS. Anyone? Is this an error?

Either way, if you .map file looks like that in your text editor, then something else is going on. If not, try making it like the above... 

I checked my map file as you suggested, and it turns out I had made a mistake with the _sun_mangle values. Fixed it, and now sunlight finally works.

Thank you so much, FifthElephant and RickyT23!

In response to your question, RickyT23: in TrenchBroom, when you select a brush you can add and edit properties. By default if it is a regular, non-func brush, it only lists classname, spawnflag and wad (if it's textured). Everything else (e.g. "_sunlight") you can then add manually (if you know what it is called).

worldspawn is listed only once in my map file, by the way.

Re: 14057: Thanks, Fifth, but I am on Linux. 

Bizarrely, though, I cannot open it with TrenchBroom (although I can open it in a text editor). 

It's just empty, right?

Sorry; with every consecutive post I must seem like more of an idiot. 

It's a simple box room. 

Oh, right. Just needed to rotate the camera almost completely. Yes, it's all there.

Well, as I said, with every consecutive post I must seem like more of an idiot. 

it's probably because of where the geometry is. I can't leave what I was working on there, probably going to do something special for the next jam.