transparent sky means that (the sky brush appears non-solid and) projectiles are removed upon touching it. this feature is always determined through qbsp - older versions always made the sky a solid surface (see id levels). so maybe the -transsky option is just a remainder of the time when it this feature was new and its usage had to be carefully considered by the mapper. i don't know... 

but then you're talking about different things. Transparent means you can see through it after vis is run, therefore the sky is always opaque. It's also solid in the sense that most entities collide with it, except e.g. rockets. Even grenades bounce off sky.

However, you're right about older qbsps not setting the CONTENTS_SKY attribute for sky leafs, thereby invalidating sunlight in newer light tools. In my Light you can workaround it by adding the -solidsky option.

And Tree's -transsky doesn't affect the CONTENTS_SKY attribute, I think it tries to set the sky leafs transparent (like liquids), but the engines don't care it seems.

You can however add the -solid qbsp option to remove all liquids and force sky to be "oldstyle" solid again. This can help loading some troublesome maps in normal engines and ease leak hunting. There's also the -noents option to remove all entities except world and players. 

If you load dm3 and noclip/spectate above the map, you can still see the megahealth hill from outside the map. Ie, the sky brushes behave just like solid walls in that they have no "other side" so they are transparent from outside. Same with all id stock maps.

This doesn't happen in ztndm3, the sky brushes block all visibility if you float out. That happens actually in ~any new map.

Why is this?

I'm sorry, I haven't tested at all if this is (vanilla/tx/tree) qbsp's or whatnot's fault (I still don't have net at my own comp and am lazy as hell)

I recently made this big spiral test map and had problems with sky textures causing lots of extra lightmaps and I'm now asking did id actually do stuff originally differently so that there weren't any new lightmaps, and if, why isn't it so anymore? 

as we said, the older qbsps treated sky brushes just like regular brushes, i.e. only the face on the inside is visible.
newer qbsps leave the entire sky brush intact and add the contents_sky attribute. it is then treated like a water brush in some way - at least this is what i think regarding the splash sound when grenades bounce off (...probably nonsense - should have waited for aguirre to anwer)
in fitzquake the sky brushes do not block visibility from the outside btw

aguirre: thanks for clarifying. it should be mentioned, however, that projectiles are removed at the back face of the sky brush (the one at the outside, so to speak). therefore, if the sky brush is not deep enough one can still see the impact of shells and nails. grenades bounce off at that face as well and when they pass the front face again there is the splash sound.

this also makes me wonder why the engine can't recognise a grenade touching a water volume just like that and no only after it has bounced off some wall (splash sound again), but i guess this has already been explained to death. ;) 

(and shouldn't) "back up" sky brushes with solids; sky seals just as well. In that case, I don't think you can see any rocket detonation no matter how thin the sky brush is.

As said earlier, there are a *lot* of different engine opinions (and cvars) of how sky should be rendered, so any observation must be with that in mind.

The splash sounds is also another weird matter, with some engines or bot paks you'll hear splashing noises continuously throughout the entire level even if there are no liquids anywhere near you. 

i didn't say anything about "backing up" sky brushes with solids. no question, that's pointless.
there are no explosions of course, rockets are removed upon touch, but shotgun impact sometimes shows on 'thin skies'. everything works perfectly fine with sky brushes that are 32+ units high.

let's just blame the engines before we continue talking past each other... :) 

. 

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.