Steam SDK notes

From Helpful
Revision as of 13:39, 20 June 2022 by Helpful (talk | contribs) (→‎Playing and building with physics)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
This hasn't been updated for a while, so could be outdated (particularly if it's about something that evolves constantly, such as software or research).
This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)


Level editing (Hammer)

Selection

Depending on what you read or tried, you may have associated the block thing that drags in 2D views make with creating objects, but it is also used as a select-many, by pressing Enter.

See also http://developer.valvesoftware.com/wiki/Hammer_Selection_Tool


Visgroups: managing a chaos of objects

Visgroups are a concept in the editor. You can assign an object to one or more visgroups, and you can enable and disable visgroups (which both means showing/hiding in the editor and in compilation/the game).

Visgroups can be handy to hide specific buildings, parts of specific buildings, e.g. to be able to edit one floor at a time,

(Note that when you want to compile only part of a level to quickly test it, cordonning is often an easier way to do that.)


It can in some circumstances make it easy to select large groups of objects. Disable the visgroups with irrelevant objects, and use Edit → Select All.

Faster partial map testing: the cordon (also visgroups)

The cordon defines a volume that will actually be compiled into the map. It's often used to test and debug a small area of a large map.

Note that if you don't have a player start in the area, you'll be created at (0,0,0), which can easily be outside the level - you'ld need to use noclip to get in.


You can set the cordon texture, which you may want to set to tools/toolsblack to avoid lighting mistakes in underground areas (verify).

(Map) units and the grid

See http://developer.valvesoftware.com/wiki/Dimensions


The smallest unit the editor easily lets you use is a map grid unit, which translates to 0.75 inch. In hammer, you can decrease and increase the grid interval (two-powers of grid units) with [ and ].

These sizes relate to some real-world sizes: a player's height (which is actually very short), how large crawlways must be, how much damage falling takes, how large models will look.


For us silly SI system people:

  • A unit is about 1.905cm (0.01905 m), which makes a meter about 52.5 units.
  • For people with floorplans: millimeters to units means multiplying by 0.051282

Reference for in-game abilities:

  • You can walk over / step onto things at most 18 units high (real-world equiv: ~34cm, a little less than a foot)
  • You can walk under things at most 73 units over the floor (real-world equiv: 1.9m)
  • you can crouch under things at most 37 units over the floor (real-world equiv: ~70cm)
  • Crouchways must be at least 33 units wide (real-world equiv: ~62cm)
  • You can't walk up an angled surface that is steeper than 45 degrees
  • Players are 72 units tall (real-world equiv: 4'6", 1.37meter)


More unit notes:

  • taking damage when falling: 2 health at 241 units (~4.5m), 100 health at 726 units (~14m)
  • L4D's infected can climb at most 180 units (verify) (~3.4m)

Basic editing/map concepts

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)
  • a brush
    • is a convex
    • By default it is a solid, part of the world/backbone/solid part of the map (If tied with an entity, it becomes a brush entity instead)
    • is pre-lit (by vrad)
  • entities:
    • point entities (monster, player start points, lights, interaction with objects, triggers, ai management)
    • brush entities are 3D volumes(/faces?(verify)) with some specific property/behaviour. They are usually created by making a brush, then tying that brush to an entity (Ctrl-T)


When brushes touch each other:

  • touching solid brushes are merged and simplified (unless they are translucent, or flush (to avoid texturing trouble))
  • touching entity brushes are simplified within that entity


  • models
    • shapes/meshes for which brushes are not handy
      • Used when you want a dynamic position, dynamic lighting, motion, state, you want something to animate, automatic generation, and/or when you want LOD to apply. You can control which of those things a model does. See the prop type overview.
      • Examples: bots/other players/NPCs, physics objects, guns, sometimes parts of or even whole buildings


Note also that models may have multiple skins, and that the entity's color may be used in rendering. Doors, cars, and some other things see some (relatively cheap) reuse and variation this way.


  • prefabs
    • ...are simply groups of brushes and/or entities. A Hammer concept, and one way of working on a map with multiple people (e.g. one does the overall placement and organization, others create details to send in) without running into versioning worries



See also:


To see what you can do with sketchup, see things like [1] and [2]

Complex objects (and working together)

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

Using existing models (static or not):

  • create entity with type prop_static, go to its properties, and open the model browser.


Hammer doesn't allow importing of levels or apparently any geometry, but it does allow opening of prefabs, which are file-backed things that come from other hammers, which seems to mean you can use these to transfer parts of levels.

You create prefab files by selecting objects and clicking the "Create prefab" button.


Object names, events, parents

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)



Game-specific level details

Run map

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

See also:


Other (technical or not) level design

There is a lot of good information on:

http://developer.valvesoftware.com/wiki/Level_Design



Fog

You generally want to fog to a color near the skybox texture's colors, so that it will seem to fade into it.

Basic fog:

  • env_fog_controller
  • change properties:
    • Fog enable: Yes

Fog start is the distance at which the fog starts affecting visibility Fog end is the distance at which it is entirely opaque.

Anything furter than the max fog distance will not be drawn.


Fog affects vrad, in that it makes for more atmospheric scattering so makes cast lights more diffuse.

Fire, rain, dust, water, and other localish detail

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)






On water:

  • cheaper-to-render water uses a cubemap and does not refract.
  • Prettier but slower to render (and >=DX9) water refracts and reflects in real-time.
  • This can be controlled by LOD (and the hardware you have), or forced to either type.

Howto:

More information:


Unsorted:


Skybox

Basic 2D skybox:

  • Apply the tools/toolsskybox texture
  • Map menu → Map properties → set the Skybox Texture Name to a skybox name

http://developer.valvesoftware.com/wiki/Sky_List is a handy list of skybox names. Note that games have specific sets of skyboxes, so things that may work in one game do not necessarily work in others (and the list in the editor may not be tuned to the game you're designing for).


Note however that a single large skybox is not ideal because of visleaf considerations. Whenever you have an indoor level or an outdoor level with clearly separate areas, use separate skyboxes for the areas in which you want a skybox. In general, keep the skybox as tight as possible.


See also http://developer.valvesoftware.com/wiki/Skybox_(2D)


A 2-D skybox is a fairly simple parallax-style texture, for example applied to a box over the level, where the actual texture is a texture that comes with the game you are designing for,


A 3-D skybox projects a completely separate part of the map, and does so at lower resolution. (Note that the 2D skybox texture is always on the background of the 3D skybox, so 3D skyboxes are an addition and not a replacement of a 2D skybox).

The idea is to make a bunch of small-scale models (1:16 scale in most games, 1:32 in L4D) which are projected at 16 (32 in L4D) times their scale in the skybox.

3D skyboxes are best used to give an impression of things at a relatively fairly far distance, and the scaledown makes it resource-cheaper. Consider for example HL2's city levels, which uses recognizable parts (like the tower) of previous/next levels for the player to recognize, while rendering them relatively cheaply. Whereas in L4D it's generally only for atmosphere.


You may wish to read up on design considerations for the 3D skybox in terms of lighting, fog, and such.

With a little practice, you can let the 3d skybox geometry appear to flow into your world geometry.

Scale matters, because the 3D objects parallax too.

While you can place models in the 3D skybox, models don't scale so you'ld need to separately design smaller models for your skybox.


See also http://developer.valvesoftware.com/wiki/3D_Skybox

Leaks

http://developer.valvesoftware.com/wiki/Leak


Glass, breakable glass

For breakable glass: http://developer.valvesoftware.com/wiki/Breakable_Glass

In L4D it seems you must build the map with the HDR setting on, or the break texture won't be there (it wil will be black/purple chessboards instead)


You can place an env_cubemap near the window - since glass reflects and things by default use the nearest cubemap entity

The cubemaps still need to be generated. You can do this in-game using buildcubemaps. This will kick you out of the level, meaning you will have to load it again to see the results.

Lighting (and HDR)

For relatively basic lighting:





Notes on physics and movable objects

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)


prop_static is for anything that won't/shouldn't move or animate. generally useful for detail that's cheap to have in the game. Not really an entity after compilation; doesn't act in IO or networking. Does affect the lightmap. [3]


prop_detail (not to be confused with func_detail) are like prop_static, but are often automatically generated (e.g. rocks, grass tufts on dirt), and assumed to be very small.


prop_dynamic is for things that should be able to move (animate, or follow something) -- but will not do so by themselves. Can break, can collide, but won't play in VPhysics.


prop_physics are used to add rigid, VPhysics-simulated models to the world. Cast dynamic shadows. Creating a prop_physics using a model that lacks physics data will effectively make it a prop_static, or cause it to be removed (which, in which cases?(verify)). To simulate a static prop in physics, use prop_physics_override (overrides prop data), which usually requires some parameter tweaking to go along.

prop_physics_multiplayer is a special case of prop_physics that is more efficient in multiplayer games, particularly for player-sized things that are thrown about (they avoid direct collision by pushing the player away, which is close enough to the behaviour you would want in most cases)

prop_ragdoll is like prop_physics, for models with joints.


Brush entities:

func_physbox is for simple brush entities to be treated in physics, e.g. simple collapsible rigid-body constructions.


func_clip_vphysics is for creating (invisible) areas that vphysics considers solid.


Unsorted: move_rope [4] keyframe_rope [5] func_tracktrain [6] path_track [7] http://developer.valvesoftware.com/wiki/Phys_lengthconstraint http://developer.valvesoftware.com/wiki/Phys_constraintsystem http://developer.valvesoftware.com/wiki/Phys_spring http://developer.valvesoftware.com/wiki/Phys_ballsocket http://developer.valvesoftware.com/wiki/Phys_hinge http://developer.valvesoftware.com/wiki/Phys_constraint


See also:



Unsorted:


Other interaction

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

http://developer.valvesoftware.com/wiki/Func_button

http://developer.valvesoftware.com/wiki/Func_rot_button

http://developer.valvesoftware.com/wiki/Momentary_rot_button

Reflection

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

Reflective things will use the nearest cubemap (that is, the nearest env_cubemap). This is true not only for solids (such as glass) but also brush entities and models.

Inspecting cubemaps is perhaps easiest by using impulse 81, which replaces your current weapon with spheres that let you see the currently applying cubemap.


env_cubemaps should generally be placed in distinctly lit/textured areas. Depending on how realistic you want reflections to be.


Apparently VRAD can't build cubemaps in both HDR and non-HDR at map build time, but when using HDR, you do want both. The workaround is building them after the fact, see http://developer.valvesoftware.com/wiki/Cubemaps#Cubemaps_and_HDR


Random level elements

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

http://developer.valvesoftware.com/wiki/Detail_Props


Doors

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

In-game debugging and commands

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

Since you'll have to do various things in-game, you can create a script to assist certain tasks.

In this file you'll probably mostly put bind commands to tie keys to actions.

Since you don't want to always have these apply, you'll probably want to create a new file, say, stuff.cfg, and either manually exec stuff, or add it to the command line options under Run Map (+exec stuff.cfg).

You place the file into left4dead\cfg (which is probably something like C:\Program Files\Steam\steamapps\common\left 4 dead\left4dead\cfg)

It may be handy to use the fairly complete config available at:

Examples:

Navigation mesh, navving

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

The navigation mesh, in general, is used to define walkable areas, and in L4D is also used by the director for spawning decisions, and necessary for a map to be playable.

It is mostly generated automatically, and you can edit it for specific effects, e.g. creating areas bots will crouch in, jump, crawl over, jump up to, and such.

See also:


If you want to be left alone while fixing navigation:

director_stop

...stops new infected from spawning (note that new mesh areas won't be used until the director is restarted)

nb_delete_all

...removes all current infected as well as teammates (you could just wait until your teammates have dealt with all of them)


(mark), generate, save

You can view (and also edit) the navigation mesh using

sv_cheats 1
nav_edit 1

If generation doesn't find all walkable areas, you want to point to each walkable area and run:

nav_mark_walkable

Any obviously connected areas will be added, so depending on the map you may not need many of these, or you may need quite a few.


To tell the game to (re-)generate the nav mesh:

nav_generate

If the level was mostly right and you want to add a few walkable areas, or when the maximum radius around each walkable mark didn't cover all of your level, you can add marks and then use:

nav_generate_incremental

(note that this saves the navmesh automatically)


Generation only detects what areas are walkable, so after each (re)generation you also need:

nav_analyse

...so that spawn areas, no-spawn areas, crouch areas, level flow and such can be generated. Not all that nav_analyze can do will always be done, depending on level structure. You may still need some post-processing.


To save the nav data into a .nav file:

nav_save


Note that:

  • Newly generated areas are selected. You may want to deselect them (particularly before marking).


Splitting, merging

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)
nav_split

will split the area you are pointing at with the line your cursor and your orientation to the area is implying.

Splitting areas can be useful when you want areas with different attributes.

Note that:

  • split areas will keep their attributes


Merging

nav_merge


Creating

nav_begin_area
nav_end_area

nav_corner_raise" or "nav_corner_lower

Selection (navarea)

Add (area currently under cursor) to navarea selection:

nav_toggle_in_selected_set

Clear selection:

nav_clear_selected_set

Operations on selections

Delete navareas in selection:

nav_delete

To connect two selected areas (2-way), select both and:

nav_connect

To select two, one-way, select one, point to the other, and

nav_connect


See also split and merge above.


Raising, lowering:

nav_corner_raise
nav_corner_lower



area attributes

z_debug 1

...shows the area ID on a corner, and the (list of) area attributes over its center.

You can mark the current selection using, for example:

mark PLAYER_START

To clear one later:

clear_attribute <attribute name>

For the attributes and their uses, see http://developer.valvesoftware.com/wiki/Nav_Mesh_Attributes_(L4D)

Some notes on the basics:

  • PLAYER_START:
  • EMPTY: no infected spawning here. Usable on areas that don't really fall in a map, on areas near player start zones, and such.
  • CHECKPOINT: used to mark rescue rooms
  • FINALE: End of a normal level. Regular flow is from PLAYER_START via CHECKPOINTs to a FINALE


Tweaking:

  • OBSCURED means infected can spawn eve when the survivors can see it () -- usually because you know they actually can't. Various bushes and thickly tree'd areas in Blood Harvest use this, to have spawn spaces in such an open map.
  • NO_MOBS: Force mobs to form in some other place than here. Probably mostly useful on campaign levels, or perhaps generally for areas where you wouldn't really expect many infected to appear at once, e.g. higher/smaller areas.


Level type specifics:

  • BATTLEFIELD is for panic events / mini-finales, and maps that allow playing in survival mode.
  • BATTLESTATION marks holdout spots for survivors (bots) to gather.

(See more on this below )

Level compilation (and some notes on optimization)

A quick explanation of the what and why of the three executables: (For those of us who remember Quake mapping, Valve's is quite like it.)

Often enough, your placement in a level means that a lot of that level doesn't need to be drawn - anything that is blocked by a large wall, that is around a corner, and such.

To be able to make that judgment quickly in-game, you need to do a whole load of precalculation.

To this end, vbsp splits your map into visleaves (roughly: groups of faces that represent an area - consider e.g. the outer walls of one room, the outer wall of another, and the walls of a simple hallway between them).

Once split up, vvis figures out which areas are visible from which other areas.

vrad will figure out all the lighting that's static.


The related jargon:

  • visleafs
    • are hollow areas of the map (that a user/spectator can potentially be in, and look into other such areas from), or more specifically, a convex cluster of surfaces that play in visibility calculations.
    • The idea is that whenever any part of some other visleaf is potentially visible from any part of another visleaf, they are visible from each other. In-game, every visleaf visible from the one we are in is drawn - in its entirety.
    • visleafs are generated by vvis, based on the BSP tree generated by vbsp.
  • portals are the edges between areas, the places where adjacent visleaves touch.
    • whether two visleaves can see each other is calculated from checking whether the portal(s) of one visleaf can see any portal(s) of the other visleaf - on whether such a view goes purely through solid geometry, or not.



The parts of calculating a level:

  • vbsp.exe
    • figures out visgroups and portals
    • can be assisted with hints. See notes below.
  • vrad.exe
    • pre-lights the map's static solids
    • Will build textures with details proportional to the lightmap detail - you can change that for each surface in Hammer. Higher lightmaps makes building exponentially slower (and more memory-hungry), and gameplay a little slower, so lower lightmap details wherever you don't need it.
    • Visibility optimization also helps vrad build time a little, because it knows that areas that can't see each other will not significantly light each other.


Notes:

  • brush entities and displacement meshes do not play in visibility, and also don't seal a level. (whether to draw these entities is based on the visleaf they are in(verify))
  • If you forget to make brushes into func_detail entities, you'll probably get a lot of small visleaves.


See also;


Seeing and influencing visleaves and portals

Having a few small visleaves is to be expected (particularly near doorways, windows, and such), but having a lot of them, and to have them extend in strange directions, is often unnecessary. It will also make the game work harder (and often make vvis take a lot longer).

Even without small detail, the areas that vbsp creates may not be obvious or ideal.

There are various cases where hallways, windows, cabinets, corners, and such will lead to splits that don't really reduce the the amount of in-game work (visibility and its calculation) as much as it could with a little help. Sometimes the difference is small, sometimes it's pretty noticeable.


Seeing

In Hammer:

  • Map → Load Portal File. This will show the portal edges, which tends to be an easy overview of the places where you want to convert things to func_detail brush entities, and sometimes where some hints could be clever.


In-game:

  • You can see the wireframe of all things that are being drawn (without occlusion - it'll look messy), to see to which degree the visibility calculations seem to be useful from the player's current position:
mat_wireframe 1
  • You can see the extent of the current visleaf: (somewhat redundant with loading the portal file in hammer, but sometimes less visually confusing)
mat_leafvis 1



Influencing

As a rule of thumb: If it's smaller than a person and/or unlikely to ever obscure anything (say, pillars, walkways, individual steps of stairs, window details), then you probably want it to be a func_detail so that they don't play in visleaf splitting.

Some of those you wouldn't want to play in visleafing, in some cases because it would really explode the amount of visleafs.


The process of visleaf creation potentially extends the plane of all surfaces, so anything not huge that is irregularly placed is also candidate for being a func_detail. If you decide not to, try to snap them to the same grid interval as something near it, and avoid rotating them, to lessen the amount of implied smallish visleafs.



You can use hint planes (usualy a brush with the tools/toolshint texture one face and tools/toolsskip on all other faces, to force a split in certain directions.

You probably want to look at a bunch of examples (particularly those that don't help) before you do this extensively. Look at [8]

Remember that visportals work in 3D - looking around things, but also over things. When things are vertically open, you want some horizontal blocks too - see e.g. most of [9]

See also:



Controlling visleafing

func_detail

A func_detail is one of a few entities that does nothing much.

They are solid enough (brush entities) and are lit like world geometry, but do not play in visibility calculations, and as such will not cause visleafs to be created - which is most of their point.

Whether and when it is a good idea to convert world solids to func_detail entities depends on the situation.

As a rule of thumb: If it can obscure something large, or helps seal a significant volume, you want it to be world geometry. If it is unlikely to obscure anything worth mentioning (which is easily true when it's smaller than a room or person) or has a shape or position that means it is unlikely to block anything's view (in a portal sort of way) in the most likely player positions, then it's probably not worth it to let it play in portalling.


You create func_details by tying solid brushes to a func_detail entity, which seems to be the what tie-to-entity (Ctrl-T) does by default.

It does not matter much whether you create one func_detail for many brushes or make entities for each(verify) (Does it matter in (pre-)lighting?(verify))


Behaviour, notes and downsides (see primarily the valve wiki notes. Some of the things you should know if you don't read those):

  • func_detail brush entities act solid and cast shadows, so look and act like world brushes.
  • they do not seal a level, nor rooms from each other, which can sometimes matter a lot in how visleafs are created.
  • since they do not directly play in cutting up a level, they also don't interact ideally with the lighting of brushes around them, which means that light can bleed through what seems solid to you. Apparently, the larger(verify) the func_detail and the larger the light contrast directly around it, the larger the chance is that it'll look somewhat wrong. You can often fix that in different ways (more on that in a moment) though note that you can sometimes prevent such bother.


See also:

nodraw texture
This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

If a player cannot see a face (without cheating with noclip), you can apply the nodraw texture to it so that that face basically won't exist after compilation (won't be member of any visleaves).

This can include things like outside walls at the edge of the level, the top of high roofs, and such.


You may want to consider observers, as they can go everywhere. They generally won't mind if some unused part of the map renders a little oddly, though.



areaportals
This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)


See also:

Area portals (not the same as portals)

  • can be opened/closed while the engine is running, which allows you to create areas that can be disabled until you get there (visibility through the portal is controlled by whether that portal is considered open or closed, which can be flipped e.g. by triggers)
  • can be useful even when always open, as they tel the engine to look through it and


The latter use is relatively costly, so you should probably never have more than a handful of areaportals visible at the same time, unless perhaps each of them is doing noticable work lessening the amount of things to draw


A common use is a door between major parts of a single player level - once you go through it and the door gets closed, it is easy to consider the last portion of the level as irrelevant to drawing, until the door/portal is opened again, if ever.

In various cases you want something physical to accompany an areaportal, as a closed areaportal blocks everything behind it (so generally shows the skybox instead of any geometry).

This is not always necessary - you could can for example control visibility in outside levels somewhat manually - you can block out the level and have each area control what you know won't be visible from a player on the ground of each, behind a tower, or such. This is microoptimization, though, so do it at the last possible time.



Left 4 dead

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

http://developer.valvesoftware.com/wiki/L4D_Level_Design/Your_First_L4D_Level

http://developer.valvesoftware.com/wiki/Category:Left_4_Dead



Note that you can create a custom campaign Add-on thing to have it work via the menu. See:


Level design

Suggested lighting style:

  • Most things fairly dark, use lights in more important areas as people are drawn there
  • Place lights low make for nice shadow effects


Obscuring places is good, as the director likes to use them to spawn infected.


Note that while you can leave spawning to the director, you can also point something like a trigger brush or timer to an info_zombie_spawn (SpawnZombie input)


Level style

You are likely to design a level for coop play, versus play, or survival mode; different types of design are handy for each. See e.g.



Note: you can use [http://developer.valvesoftware.com/wiki/Info_gamemode info_gamemode to trigger things depending on whether the level was started in coop, versus, or survival mode.


Survival Survival acts similarly to a finale/crescendo/panic:

  • You need a BATTLEGROUND
  • You can add a BATTLESTATION


To test a level in another game mode, choose one of:

mp_gamemode coop
mp_gamemode versus
mp_gamemode survival

...before a map/changelevel command.



Making levels playable

At the very leasy you need:

  • starting positions (or you'll be created at (0,0,0))
  • a director (or no zombies will spawn)
  • a rescue room
  • a nav mesh (edit in-game)

The rescue room and nav mesh are useful when you want a level to be playable as a mission. Just a director just gives you the occasional zombie.


On starting positions:

(which one for L4D? info_player_start? info_player_deathmatch?

The cordon area does often not include the original starting point (the info_player_start or the info_player_deathmatch entity) of the map, and running a map without compiling a starting point will place the player at the world origin (0,0,0) ingame by default.



Weapons, ammo, health

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

Look for weapon_* entities


L4D:


http://developer.valvesoftware.com/wiki/Prop_health_cabinet

When a weapon_ammo_spawn entity shows up with an error model in the game, you have not set a world model for it (there are several that you can use, and there is no default).


Counterstrike:

http://www.twhl.co.za/tutorial.php?id=87

Materials, entities, etc.


Zombie spawning

Zombie spawning is handled dynamically, by the director.

Zombies can generally always spawn outside the line of sight.

When you clear areas, zombies do not spawn there. You can make an area non-clearable with a nav point.


You can create spawn areas outside the player boundaries


Panic events: a rush triggered by car alarms, etc.

Crescendo events: rushes that are part of a level design

Finale event


Textures

You will likely see the purple-black-blocked error texture sometimes. This means you used a texture not part of L4D (or, in general, part of the game you're trying to play the level on), but one of the other games.

You can get local playability by copying in the textures, but to release the level you'll want to add them to your BSP, for example using pakrat (how is explained in the tuts, but comes down to load-scan-do-save. Note that it seems to throw a NullPointerException if the map is not placed in the Steam directory structure -- I'm not entirely sure what the condition for this is yet).

I'm not sure how Valve handles this. They could decide that any Valve texture is fair game, any SDK texture is, or that textures from games you do not own should not be used.



Error messages

Hammer

Out of memory loading solid

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

Unless the map is insanely huge and your computer is very limited on memory, this probably means that values in the VMF file (which is plain text) got corrupted.

Examples of problems include values like .#QNAN or .#INF appearing where real values should, for example as coordinate values in the solid that the line number points inside. Sometimes it's just a single solid or a few of them, which you may be able to safely delete from the text file, or even fix the values for. (In my case, a single hint block disappeared magically in the editor after a rotation, and became such a problem case. YMMV on how much goes bad at once)

It may be safer yet to go back to a previous version, and note that the .vmx be a good version of the vmf - you can try renaming to .vmf and see if that works. It seems that chances are that it's the exact same file, though.

Incremental backups are a good thing, though note that you can save an per-session in-memory mistake to each successive file if you save all of them from the same session. In this case, you may have to go back more versions than you wish, and you may have to resort to editing.

See also:

Entity (entity name ) has unused keyvalue "keyname"

Unused keyvalue errors seems to usually mean valve being a little lazy leaving old key names around, and this rarely points to an actual error.

It may mean the VMF is old (or perhaps for a different game?).


It seems to show up regularly for func_breakable_surf, specifically for L4D (beta SDK specific, perhaps?), in which case the diagnosis looks a lot like the what-texture-to-choose/no-HDR problem. A quick fix here is using func_breakable (window breaks as a whole) instead of func_breakable_surf (window breaks in small pieces) -- which is the solution I'm going to use for now until I figure out the details.


Compilation

LoadPortals: couldn't read ...

Most likely, you missed the ***leaked*** above it (though this may not be the only reason).

A common cause for leaking, besides walls not closing, is entities placed outside the level.

Find Visible Detail Sides...Bad detail brush side

Probably a carve or edit too much on some brush.

See if Alt-P shows this problem (it probably won't be able to fix it, thoug) If Alt-P shows nothing, you may wish to see if you can localize the problem(s) through cordonning((verify) whether that works).

Game

OUT OF MEMORY (memstd.cpp)

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

(case depends on value reported, e.g. 32KB, ~4GB )


See also

Unsorted


Half life 2 notes

Commands

Enable admin console via options. Many of the below require sv_cheats 1.

Gameplay / build helpers:

  • god: never take damage
  • buddha: never die
  • infinite_aux_power
  • notarget: you are not regarded as an enemy
  • noclip: fly though everything
  • map name: load other map
  • give name: give item, ammo, weapon. by name


Physics vars:

  • sv_maxvelocity number: maximum velocity of anything
  • sv_bounce number: bounce factor
  • air_density number
  • sv_stopspeed number
  • sv_gravity number

Inspection:

  • vcollide_wireframe 1: Wireframe all physics-engine objects
  • showtriggers_toggle: show game triggers
  • mat_normalmaps 1: Show normalmap instead of regular texture.
  • mat_normals 1: Draw normals


Garry's Mod

Wiki: http://gmwiki.garry.tv/index.php/Main_Page

Physics gun and freezing

  • Primary: Moves, holds, and unfreezes
  • Secondary: Freeze


  • Primary + E: Rotate
  • Primary + Scroll: Move towards/away


  • R: Unfreeze everything

Freezing temporarily stops something from interacting with physics. In combination with unfreezing it's useful to pose and weld before making something physical again.

Abstract tools

  • Duplicator: Copy (secondary) and paste (primary)


  • Remover: Removes objectw
  • Clean up: Removes all objects of a type

Playing and building with physics

  • Ropes tie things together, meaning they will drag each other. (Shoot what are to be both ends)
  • Elastics are flexible ropes. Think bungie cord.


  • A Pulley is an object-pulley-pulley system attached with a rope. The pulleys are created against objects, not attached to them, and are not movable once created.
  • Balloons are bouyant in air, and attach to objects with ropes


  • A weld is an almost entirely inflexible, but breakable (unless set to be unbreakable). It is a way of attaching objects; shoot attachment points on two objects.
  • A nail is similar to a weld, nailing two things together with a single shot.


  • A Ballsocket makes one thing orbit another.
  • An Axis is basically a type of hinge. It cannot do heavy objects; if it doesn't work, try two ballsockets instead.


Ropes, elastics, welds and nails can be given a force at which they break. Balloons can be shot.


  • Magnetize makes an object attract anything loose (not just metal)
  • PhysProp sets the material and physics behaviour of an object, or ragdoll. (Apparently something must be touched with the physgun for this to work)

Ragdolls

  • Statue freezes a ragdoll
  • Face poser and eye poser are just that.

Scripting