use the other (tx vs tree) 

silent flags on teleporters doesn't affect the teleport affect at all, rather, it determines whether the ambient sound is played.

as for flashes not appearing when multiple teleports are in progress, that's an engine limitation. not enough particles to go around.

i think you can change that by adding -particles 50000 or something like that to the command line, but i don't really remember. 

TreeQBSP's default setting is non-transparent (opaque) liquids. If you're seeing something else in-game, the map is probably not vised or you're using a custom engine that disregards vis info.

Both Tx/Tree compilers can be set either way. 

ok, i already suspected the missing flashes to be an engine limitation. nevertheless multiple silent teleporters do make a sound.

my bad about the qbsp thing. i switched to txqbsp at some time (maybe because it has -oldaxis enabled by default = good) and forgot about it. -nowatervis is the key here. in treeqbsp water is indeed opaque without -transwater. the sky, however, is always transparent with both. 

transparent according to vis AFAIK. I don't even know what the -transsky option does. Again, what you might be seeing is probably engine related.

Some engines don't render animated sky leafs properly and others have issues with skyboxes, which is an old Q2 bug. 

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 : - ).