Assorted Mapping Hints

a grab-bag of knowledge!

This tutorial combines a lot of little things I have learned over the years as a Half-Life mapper, but which aren't quite major enough to justify their own separate tutorials. Those still mapping for Half-Life 1 will find some of these very useful, though.


Texture Sizing - Avoiding Blurriness

Although any texture whose dimensions are divisible by 16 is useable 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. And yes, many of the default Half-Life textures suffer from this.

Here is a clear example of the huge difference this makes in-game:


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 and blurred. More commonly, you may resize a texture to fit the proper dimensions, then stretch/squeeze it in the editor back to its proper dimensions. In the example above, I could have just warped the sign to the proper size for the engine, then used "Justify: Fit" in Hammer to fit it to a brush that is the proper size. When it comes to the primary textures in your map, the preferable thing to do is to make/use textures whose dimensions are powers of 2 to begin with, though.


Avoiding 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. This is a bug with the z-buffer; the faces are so close that the engine is not sure which it should be drawing. To fix this, make your sign a func_illusionary or 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 extra polies. Just be sure it doesn't extend outside the map, or you will get a 'leak'!


Night Maps Without Model Lighting Bugs

You've probably noticed this problem on some dark maps- how player models are not properly lit for the map. The reason? When a map has no light_environment (even a 1 brightness setting is sometimes too much for a night map), the model lighting may be carried over from the last map. I noticed this when testing Storm Vale because sometimes the player models were purple after playing 5am, which has a purple light_environment!

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 separate, sealed area of the map. 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 Problems

First of all, I don't recommend using 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 where the player is stuck with an irritating sound effect because they missed the env_sound that was set to normal. What is worse, env_sound can get stuck between maps. So if the player is in the area of an env_sound when a map changes, they may get stuck with that effect on the next map.

This is why you a) probably 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 noticeable engine lag as well. Transparent water, lovely though it is, can cause 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 an 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.

The main 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. You can use this as an opportunity to add more detail to underwater areas. 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 small inconvenience.

Note that this doesn't mean you should never use the func_water entity, or transparent water. Your mileage may vary on this one, sometimes the lag is a problem, sometimes it isn't; it seems to vary by map. The amount of lag seems to relate to the entity's size sometimes, so a small puddle or pool of transparent water is rarely a problem. If you have your heart set on using a func_water for transparency or for some other reason, see how it effects performance before you make your decision.


Setting Angles for Spawns

This is 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!

Easily Include All Used Textures

I always found -wadinclude very annoying, because often I didn't know what textures were going to be used in my map when I started. This made hunting them down and putting them in a separate wad rather irritating, especially when I might only use 1 or 2 textures from a particular wad.

Before the -wadinclude parameter was added to hlcsg, there was simply -nowadtextures. The former includes used textures from the specific wads listed in the final bsp. The latter included all used textures in the .bsp. The reason people use the former is because they don't want to include any stock Half-Life textures, since this would be redundant and bloat the size of the bsp.

However, if you aren't using any default textures, or just a couple tiny ones, -nowadtextures is a much easier solution. I may have 12 wads loaded into Hammer, and be using at least a couple textures from each. But -nowadtextures will automatically hunt down every single texture and put it into the bsp for me.

Obviously if you are using stock Half-Life textures and just a couple custom textures, this isn't for you. But if you are using almost entirely custom textures, this makes life much easier. Here is an example of the parameter being used:

hlcsg.exe -nowadtextures hldm_tower.map

A lot more elegant than a bunch of -wadincludes, isn't it?

Another thing to keep in mind is that many default Half-Life textures are poorly sized and often show up blurry in-game. This is yet another reason to avoid them and go custom.

Hopefully some of these hints will be useful. I'm sure some will disagree with a few of these assertions, so please comment if you feel I've suggested anything in error.