Hayt & Jinx
Texture Sizing - Avoiding Blurriness
Although any texture whose dimensions are divisible by 16 is usuable
in Half-Life, you should always use textures whose dimensions are powers
of 2. In other words, the sides of a texture should be 8, 16, 32, 64,
128, or 256. The reason? If a dimension is not a power of 2, Half-Life
samples it down to the power of 2 below it, then blows it back up to
fill up the space. This will make your textures appear blurry in-game.
Click on the picture below for example:
As you can see, the area of each texture taken up by the sign is the
same. But because I added some extra space to the second texture (the
blue) to make its width 128 (not 96), it was not sampled down to 64
and blurred. Obviously the preferable thing to do is to make/use textures
whose dimensions are powers of 2 to begin with though!
Making Night Maps Without Model Lighting Bugs
You've probably noticed this problem on some dark map like Inner City
and 110thst- how player models are not properly lit on the map. The
reason? When a map has no light_environment (even a 1 brightness setting
is too much for a night map), the model lighting is carried over from
the last map. I noticed this when testing Storm Vale because sometimes
player models with purple after playing 5am!
How do you get around this? First, make little box away from the rest
of the map- put a light_environment here. Now, in your hlrad settings
add the parameter "-noskyfix". It used to be that you needed
a separate light_environment for each (sealed) area of the map, and
this parameter makes it that way again. Since there is a light_environment
in the map now, model lighting will not be taken from the last map.
However, since the light_environment will only effect the little box
it is in, the rest of your map will still be dark and unlit by it.
Env_sound - Just Say No
First of all, you really should not use env_sound in a multiplayer map.
They tend to get "stuck"; because they work by radius it is
hard to get the transition between them right. Once a player has been
effected by one, their sound will only change again when they encounter
another env_sound- so you end up with bugs like in 5am where you get
stuck with the echo effect because you missed the env_sound that was
set to normal. What is worse, env_sounds can get stuck between maps.
So if you were in the tunnel in 5am when the map changed, you may well
be stuck with that echo effect on the next map.
This is why you a) should not use them in multiplayer maps and b) should
put an env_sound set to 'normal/off' in the middle of your map, with
a wide radius. That way, if the map before you used an env_sound, your
map will turn the effect off for players!
Avoiding Lag From Water Entities
This is not an r_speed tweak, but it is something that can effect performance
just as drastically. If you have a large amount of water on your map,
it can cause not only fps drops, but noticable lag as well. Transparent
water, lovely though it is, causes even more lag. Rather than the "func_water"
entity, I suggest that you use what is called "World Water"
instead. World water is a normal (non-entity) brush covered on all sides
in a water texture (a texture whose name starts with and exclamation
mark). If all sides of a normal brush are covered in a water texture,
it will be created as water when you compile the map. World water has
an opaque surface, and blocks both VIS and light. You can set its wave
height in Map Properties.
advantage of world water is that it it does not cause lag the way a
func_water can. Also, since it blocks VIS, it can lower your r_speeds-
the brushes and surfaces underwater are not being drawn when you are
above. The fact that world water blocks light can be a problem since
this means you need light sources actually in the water, but this a
this doesn't mean you shouldn't ever use the func_water entity, or transparent
water. The amount of lag that a func_water causes seems to relate to
its size, so a small puddle or pool of transparent water may be no problem.
If you have your heart set on using a func_water for transparency, see
how it effects performance before giving up on it.
Setting Angles for Spawns
This is such an obvious thing but a lot of mappers don't even think
about it. Player spawn entities like info_player_deathmatch are affected
by what angle you set. The angle set determines what direction the player
faces when they spawn. Most mappers do not do this, which means there
are some irritating spawns where you appear facing a wall etc. It takes
only a minute to set angles and will avoid a lot of player frustration,
so do it!
Avoiding Z-Buffer Flickering Sign Bugs
You have probably noticed this bug on maps- when you move far away from
a sign, the sign starts to flicker and you see part of the wall behind
it too. This is because the faces are so close that the engine is not
sure which it should be drawning. To fix this, make your sign a func_wall
and embed it slightly in the wall behind it. This fixes the bug, and
since the sign is an entity it will not break up the wall's face into