i didn't say anything about "backing up" sky brushes with solids. no question, that's pointless.

Believe it or not, back in the old days (1997) you had to do this if you wanted sky to absorb projectiles -- qbsp used to make sky brushes on the outside of the world into solid leafs. 

Gom asked about q4 editing in IRC when I wasn't around so he wasn't available when I came home to reply, so here goes:

Yes, there are good reasons why the Q4 DM maps are blocky and scant on detail. It was deemed that the best looking way to texture in Q4 was the very discrete, panelized look of q2 and d3, where almost no textures end in any edges without a bevel or a crease. Thus whole texture sets were made like that, and there's limits to how crazy you can be that way. When I was thrown into the DM pool the exact phrase given to me was "Let the textures do the work." If you look around Q4 you'll probably notice a lot of repeated workhorse type textures (like that dark grey trim) on the edges of damn near everything, because it's one of the only textures that repeats along an axis.

I'm looking forward to custom maps with custom texture sets by artists that decide to ignore panelization in favor of textures that repeat without panel seams on one or both axes, because then we'll see more inventive designs (not to say that the raven maps aren't such) with slanty wierd brushwork and stuff. That's what I perceive as the only real limitation to more detailed architecture anyway.

On scale, I keep instinctively building to a q1/q3 scale and it always winds up feeling way too tight. A 128x128 hallway is now small, because the bbox is 72x32x32 (I think) and the viewheight is 68 (I think). 192 is a good place to start with hallways, and atria wind up seeming gargantuan in the editor grid but appropriate in game.


Fire away with more questions. If I build up a big enough battery of responses I could put it all together and stick it on the Q4 SDK page. 

That answered my first questions but you'll surely have to suffer from more as soon as they come up.

The biggest problem I currently have is the following: At the moment I'm working with the ba_ textures - the ones used in the stock DM map Sandstrom - and no matter what I do, my map looks almost identical to Sandstorm.

Why? Easy: As Lunaran already said there's almost no way around the dark grey trim texture to bring some structure to your map. You can design different panel styles but having to use that trim texture makes it hard to set your map apart from others.

Anyway, I should stop whining and get back to mapping. 

How can I place them in a horizontal position (facing up) without:

A) knowing any QC
B) editing the MDL

There once was a map where the torches were all turned upside down (like the level itself). Maybe it can be done like that somehow?

Thanks in advance :) 

...give the entity an 'angles' field with value '90 0 0' that should work, otherwise muck around with the value numbers till you get the effect you want. I think the three attributes for the values numbers are <tilt> <null> <offset>

cheers! 

hey, thx.
this is a pretty cool trick that also works on all other models, like monsters, torches and flames (as you said), exploboxes, trap_shooters. rotating models like the weapons work, as well, but placing them correctly can be tricky. lava balls and air bubbles don't seem to be affected.
giving a teleport_destination stranges angles results in twisted view and controls for the player, as we already know. 

:) 

'Angles' works like 'mangle,' <pitch> <roll> <yaw>.

Using <90> <-90> <0> gave me a crucified zombie on his back, facing up, with his head pointed North and his feet pointed South. 

...if someone was to send me Kell's 'Labyrinthus' skybox for Quake I'd be ever so thankful. 

sunlight is cast as lightstyle 0, right?

... what about minlight?

in theory, you could make all normal lights be, for example, style 63, instead of 0. then code a thingy to flash lightstyle 0 every once in a while, and that would affect only sunlight and minlight, right? 

style 0, yes. As for the effects, I don't know. 

Just rewrite the code for the custom lightstyles so that style 1 is simply "m", rather than whatever it was originally - some kind of candle flicker I think. Then just make sure every light in your map has lightstyle 1, the only thing that won't be affected is minlight and sunlight as you say. You could then make an entity to do the flashing, but the best place to do it would be in StartFrame(). Just have a global for the time to the next flash. If time > that global + 0.1, reset style 0 and generate the time for the next flash. Else if time > that global, change style 0 to a bright light and wait. Otherwise do nothing. 

Of course, that sketch of the code doesn't include a thunderclap, which is a dreadful omission. Now, at first it may look a little difficult to include a sound, if you play it when you brighten the lights, then it might start playng several times, as most people have a high enough fps these days to have multiple frames in 0.1 seconds. Instead, make the sound play when you reset the light style to "m", that way it will only play once. This may sound like a compromise, but if you think about it, it makes more sense, as you see the lightning before you hear the thunder : - ). 

So there is no simple way to incorporate lightning and thunder in a quake map? I mean without coding, just using some "Teaching Old Progs.dat New Tricks" method? 

i think there might be a way, sort of...

but it wouldn't be random, it would only happen when triggered.

you could put in an ambient_thunder, this will precache the thunder sound, even though the entity itself never worked.

then, make a door with the 'noise' key set to the thunder sound, then you trigger the door and flicker the lights (have a relay to switch the lightning lights off again)

anyway, i was just fiddling around with an idea i had to make thunder easier to implement, but i think having to make mappers put all normal lights to a lightstyle other than 0 is probably annoying. 

You can have things triggered at random intervals with a lovely little hack. Make a big room with a gib spawner and a trigger_multiple with the hack to make it trigerable by anything that touches it. Set up the trigger so that it will sometimes be hit by the gib, but not every time. Then have it spawn gibs at a suitable frequency. Every time one hits the trigger, you get a burst of lightning.

In addition, wouoldn't it be possible to write a custom light exe(well, hack the existing ones abit) so that minlight and skylight also generate a lightmap for style 32, which is always fullbright wherever it is hit. Combine this with the above and a single switchable light(which should be style 32 itself), and you'd have the whole package without modifying the progs. 

It is possible to light a map without minlight or sunlight ... i've done it. The trick is to use regular lights, some of which are up in or near the sky brushes.

Then you can set all lights intended to represent sky light to the same targetname. 

no matter what I do, my map looks almost identical to Sandstorm.

That's why they're only used one and a half times. :)

Try pairing them with some /stroyent textures. stroy_pillar2 and stroy_pillar2_alight are your best friends. Try something new with the lighting too - see if cool colors look any good with the orangy rust. 

Thanks.
That's what I was thinking about. Some flickering lights triggered by a trigger. The triggers could be placed in some chosen places to get the best effect.
I have a question about setting up the "thunder door". What should be the exact value of the 'noise key'?

The event could be also triggered by an semi-random logical gate. 

Not my own invention but I don't know where it comes from...

"classname"-"func_door"
"angle" "-1"
"target" "extranoise"
"sounds" "0"


"classname" "info_notnull"
"targetname" "extranoise"
"use" "train_wait"
"wait" "-1"
"sounds" "1"
"noise"-"items/armor1.wav"

This gives the door an armour sound when opening.

It doesn't work with thunder because the thunder sound itself is broken: not looped and therefore does not pre-cache. I think... 

Why did it truncate 'door' and 'armor.wav'? 

Set "sounds" to "5", and "noise" and "noise2" (IIRC) to the .WAVs you want to play. Must be precahced. 

How do you pre-cache sound from the editor i.e. no QC? (I think this is what Ankh wants) 

I was thinking that to pre-cache something you have to put it somwhere into the map. So I just have to put the ambient_thunder entity somewhere. I will try that out.
With Hammer it should be easy to set the sounds for the door. It has the required fields implemented with the fgd file already, I think. 

yeah, like i said, even though the thunder sound entity is broke, it still precaches the sound.

keep in mind that players will see that warning about non-looped sounds everytime they play your map. :\