nyuuzyou/wikis huggingface dataset:
WisePYR

Every object in the game has an origin. A set of angles are also used to determine the objects orientation in the world. These angles are X, Y and Z also known as Roll, Pitch and Yaw.
*Roll
:Is most often a term used to describe rotation but as you know it has a wide use and is a term in Aeronautics to describe an aircraft rotating on its X axis.
*Pitch
:Is a term derived from the force of pitching an object, such as the way you would pitch hay. It has been used for a very long time to describe the way a ship at sea rocks Fore and Aft along the Y axis. Most often it is used for the same effect on aircraft.
*Yaw
:Is a deviation or turning from side to side. Used in yachting and aeronautics it is an angle that can be used to calculate a coarse deviation along the Z axis.
Take a look at the Pitch, Yaw and Roll keyvalue for a entity. Each of the 0’s can change from 0 to 360 degrees, in most cases 180 or less. Since the first angle is for the Pitch we can point the light_environment straight down by changing those numbers to 90 0 0. Straight up would be -90 0 0. Most of the questions I get about Pitch Yaw and Roll have to do with the movement of doors and buttons. To help illustrate how these angles work in your map I’ve created a sample project with 10 entities.
These are the angles for each door and the direction in which they move.
1) -90 0 0, Up
1a) -90 0 0, Up
2) 90 0 0, Down
2a) 90 0 0, Down
3) 0 180 0, Left
3a) 0 180 0, Left
4) 0 0 0, Right
4a) 0 0 0, Right
5) 0 90 90, Left
6) 0 -90 -90, Right
The 10 doors in the sample project are all set to open and close every 3 seconds. If you run the project and watch the doors you will see that doors 1 and 1a move exactly alike as do 2 and 2a, however doors 3 and 3a plus doors 4 and 4a do not move exactly alike even though they are exact copies of each other. This is because I rotated each of the backside doors, 1a, 2a, 3a and 4a. Since doors 1 and 2 are moving up and down rotating them did not affect the copies 1a and 2a. However since the copies of 3 and 4 have changed we need to adjust the Pitch Yaw and Roll to make them move properly. The doors 5 and 6 are copies of 3 and 4 but with the correct movement. As you can see to make door 5 move properly we had to change 0 180 0 to 0 90 90.
==See also==
*Example VMF
*Example VMF backup
*Pitch Yaw Roll
WisePhysbox2

==Introduction==
This is a variation of the first physbox tutorial that was requested in the forums.
The problem is all my pieces just fall down. They don't explode or "go anywhere". I don't really want them to break, just want to send them flying far.
==Fix==
#Let's use my short dock, left-side, for this example.
#Give each of the 5 boards the same name and place an under each one, lets call these boards "PlanksShort1" and the env_physexplosions all "PlankExplosion1".
#You can already see that we've got potential; all we need is crafty timing and a few changes to the board properties. We could make this better by using unique names for the boards and explosions.
#For each of these 5 boards change Strength to 0 and flag Motion Disabled and Don't take physics damage.
#We need something to trigger our events so let's turn one of the vertical posts into a and when it gets broken we'll trigger our boards. Flag it for Motion Disabled and give it Strength of 10, setting the Prop type and other properties as we did in the first example.
#We can now create the effect wanted once we add the events to the , to make it even better we could use multiple logic_relays, more of a boom, boom, boom effect with each boom having sub-events but that would require unique names for our boards and explosions.
#For the one vertical post we are allowing damage on let's create an output:
	OnBreak	LeftRelay	Trigger		0.00	No
:8. The one logic_relay that just got triggered by the output above has three outputs:
	OnTrigger	HorizontalSupports	EnableMotion		0.00	No
	OnTrigger	PlanksShort1 	EnableMotion		0.20	No
	OnTrigger	PlankExplosion1 	Explode 		0.30	No
You could alter this in a million ways but with the settings I've used here it was impressive as I built the test map.
==See also==
*Example VMF
*Example VMF backup
*WisePhysbox
WisePounder

https://web.archive.org/web/20060227023205im_/http://www.akilling.org:80/akg/assets/wisePounder_01.jpg
Events in this project:
#Zombie tries to break glass to get to Alyx.
#Glass breaks, Zombie attacks, Alyx shoots Zombie.
https://web.archive.org/web/20060227023212im_/http://www.akilling.org:80/akg/assets/wisePounder_02.jpg
https://web.archive.org/web/20060227023220im_/http://www.akilling.org:80/akg/assets/wisePounder_03.jpg
The Zombie isn’t really trying to get to Alyx, it just looks that way. When the map spawns I’m using entities and an . It’s actually the invisible npc_bullseye the Zombie hates.
There are three ai_relationship entities in this project.
#Alyx likes the Zombie, until the glass breaks, then hates the Zombie.
#Zombie hates the npc_bullseye.
#Zombie likes the Player.
They all start Active.
To get the Zombie to pound on the glass I used a .
*Name: seq_pounder
*Target NPC: zombie_pounder
*Action Animation: WallPound
*Move to Position: Run
*Flags: Repeatable, Override AI
Because the WallPound animation is short I’ve used a to replay the animation.
*Name: zombie_timer
*Start Disabled: Yes
*Use random time: No
*Refire interval: 1
	OnTimer	glass_counter	Add 	1 	0.00	No
	OnTimer	seq_pounder 	BeginSequence	 	0.50	No
Notice the logic_timer adds a value to a . These are really simple to use if you give them a chance.
*Name: glass_counter
*Initial value: 0
*Min value: 0
*Max value: 3
	OnHitMax	bigwindow	Break		0.50	Yes
Experiment with the timing of the sequence and the Max value for the math_counter to alter the effect.
When the map loads the Zombie is spawned and the logic_timer is then activated 3 seconds later. This is done with a .
	OnTrigger	glass_pounder_spawn	Spawn 	 	0.00	Yes
	OnTrigger	zombie_timer 	Enable	 	3.00	Yes
The Zombie is spawned by way of an .
*Name: glass_pounder_spawn
*Start disabled: Yes
*Number of NPCs: 1
*Freq: 1
*Max live: 1
*Name of template NPC: zombie_pounder
*Radius: 256
	OnSpawnNPC	seq_pounder	BeginSequence		1.50	Yes
As you can see, from this npc_template_maker the scripted_sequence is first activated.
These are the properties for Alyx:
*Name: alyx01
*Weapon: Alyx Gun
*Flags: Gag, Fall to ground, Think outside PVS, Don’t drop weapons
Zombie:
*Name: zombie_pounder
*Flags: Gag, Fall to ground, Template NPC
As you can see from the image below there are a lot of entities used in this project.
https://web.archive.org/web/20060227023151im_/http://www.akilling.org:80/akg/assets/wisePounder_04.jpg
It helps if you keep them tidy like the image above, as you add more and more NPC’s and sequences you don’t want to go crazy trying to figure out what you’ve done. The glass in this project is . Please refer to the project file below for properties and settings I didn't list on this page.
==See also==
*Example VMF
*Example VMF backup
WisePrecip

==Introduction==
Last night (09 March 2005) Valve released an update for HL2 that contained the textures which will now allow us to create Rain and Snow effects. (Apparently there have been textures for CS:S, and of course other custom textures.) There will no doubt be a lot of questions about the effects you can create. From what I’ve been able to determine you do not have a lot of control over the Rain and Snow but it is still a nice effect none the less. In the download for this tutorial I’ve included two vmf files, one for rain and one for snow. If you experiment with these you will find that both of these textures perform a little differently.
One thing you need to be careful of, for appearance reasons only, is rain or snow over water. Rain and snow will bleed right through your water (or other objects), which might look odd. You can however alter the volume of the precipitation to overcome the effect of these textures bleeding through. Interestingly the method to keep them at the surface of the water seems to work better with rain.
The official description for func_precipitation is: "A brush entity that creates rain and snow inside its volume." This volume is what you will need to experiment with in your maps to achieve the effect you desire.
==Creation==
The first thing you need to do is create a brush over the section where you want precipitation. Create this brush with the tools/toolsnodraw texture. Now press and tie this brush to entity func_precipitation. Click Apply.
The properties for func_precipitation are:
*Name: The name that other entities refer to this entity by. You will assign a name if you want to create inputs from other entities. For example to kill (remove) the precipitation.
*Parent: The name of this entity's parent in the movement hierarchy. Entities with parents move with their parent.
*Density (0-100%): This is the visibility of your precipitation. Values from 1-10 seem to work best, 5 is the default and higher numbers will appear jagged. You probably don’t need to change this, but experiment.
*Color (R G B): The default color, 100 100 100, seems to work best with the default textures.
*Precipitation Type: Either Rain or Snow.
==See also==
*Example VMF
*Example VMF backup
WiseProps

In this tutorial we will cover:
#How to control interaction with a physical prop.
#Keep the prop from being damaged.
#Allow the prop to be easily damaged.
#Make it hard to damage the prop.
#Explode the damaged prop.
#Respawn the damaged prop.
In the shot below the crates are all the same model: models/props_lab/dogobject_wood_crate001a_damagedmax.mdl.
Two of the crates are a different color. This is done by changing their Skin. You should check HL2 models for additional skins. Some of the other models you can do this with are Trains and the Shipping containers.
In this example from left to right the props are:
1 
2-6 
7 
The properties and type for the first crate allow us to let the player interact with it but not damage it. This crate can be knocked around and tossed and it will shoot gibs when shot at. The second crate is easy to destroy but can’t be moved. Create 3 will explode when damaged and the explosion will hurt. The next three crates are identical but are, hardest to easy, to destroy. For the 7th crate this type allows us to respawn the crate, in this example it will reappear in 10 seconds. 
First crate:
*Health: 0
*Skin: 1
Crate 2:
*Health Level to Override Motion: 10
*Min Damage to Hurt: 20
*Flags: Motion Disabled, Not affected by Rotor Wash, Prevent Pickup, Prevent Motion enable on player bump
Third crate:
*Explosion Damage: 100
*Explosion Radius: 50
For Crates 4-6 one property changes: Min Damage to Hurt
*4: 100
*5: 75
*6: 20
Crate 7 is our prop_physics_respawnable:
*Skin: 1
*Respawn Time: 10
Download the example for this tutorial and play with the properties for these crates.
==See also==
*Example VMF
*Example VMF backup
WiseSaloonDoors

==Introduction==
#Prop doors
#func_doors
#Toggleable doors
#Brush and entity based doors of many types like .
The principles illustrated in this project are:
#Hinges for brush based doors.
#Creating doors that swing freely and return the starting position.
#Doors that can be shot from their hinges.
The doors in this project are . func_physbox is a brush based entity that simulates Source engine physics. They are not the ideal candidate for all your brush based doors. They are however the best solution for swinging doors like these. We need these doors to swing open when pushed by the player. We don’t want them to appear to be stuck at any time. We want them to return to a resting point but not instantly. Most of your doors will have their own hinge. These func_physbox doors require that we create a constraint system. is the constraining entity we will use for these doors. We are also going to use a . phys_spring is another entity that simulates Source engine physics. It does a very good job of creating a stretching effect. For these doors it will act like a rubber band that connects them. This is what will cause the doors to return to a resting position.
==Creation==
Add a phys_hinge to the center of each door's hinged edge and make your adjustments.
Notice in the image above the phys_hinge was placed evenly over the meeting area of the door and wall. Also notice that the phys_hinge was adjusted in the side 2D viewport to create a larger hinged area. The white target illustrated in the side 2D viewport is also the blue ball in the 3D viewport. In this project the short wall sections were converted to so they could be named and then used as the phys_hinge’s Entity 1 property. This isn’t always necessary but when needed func_brush is perfect for the job.
Placing the phys_spring is similar. I’ve placed it in the center of Door2 and have adjusted the length of the spring with the Hammer Helpers until the white target was in the center of Door1.
I've also added outputs to the doors so when OnDamaged fires, they will Break the hinges. I've also flagged the doors to Only Break on Trigger, so they won't break until told to.
The only properties you will need to adjust besides the constraint points for the spring and hinges are the Damping and Spring Constant properties for the phys_spring.
These are the properties I used for this phys_spring.
*Name: spring01
*Entity 1: door02
*Entity 2: door01
*Spring Length: 0
*Spring Constant: 900
*Damping Constant: 7.0
*Relative Damping Constant: 0.9
*Break on Length: 0
*Flags: Force only on Stretch
==See also==
*Example VMF
*Example VMF backup
WiseSeq

The first thing we need is an NPC and for this example we are going to use my favorite: . There’s only one used in this so let’s just name it: zombie. We will need to name the entities in this tutorial so they can reference each other.
Pull up the properties for our npc_zombie and click on the “Model” tab at the top. Cycle down through the Sequence list. You can test the different animations here. For our example we are going to start the Zombie out sitting down. We will use a trigger to wake our Zombie. The Zombie will then stand up and attack us.
One flag is set for our Zombie: Template NPC. I have also created one Output for our Zombie in case it gets damaged before it is triggered.
	OnDamaged	zombieSeq	BeginSequence		0.00	No
“zombieSeq” is the name of our . This is where we will add the sequences for our Zombie to stand up and to initially use a sitting position. When we took at look at the Sequence list above we would have picked the ones that we plan on using here.
*Name: zombieSeq
*Target NPC: zombie
*Pre Action Idle Animation: slump_a
*Action Animation: slumprise_a
*Search Radius: 512
*Move to Position: Instantaneous
*Flags: No Interruptions, Override AI, Priority Script
Our next entity is one .
*Name: zombieTemplate
*Start Disabled: No
*Num. of NPCs: 1
*Max Live NPCs: 1
*Name of template NPC: zombie
*Radius: 256
*Dest. Criterion Visible: Don’t care
*Dest. Criterion Distance: Don’t care
One Output is needed for our npc_template_maker:
	OnSpawnNPC	zombieSeq	MoveToPosition		0.00	No
To put all this in motion we use one .
	OnTrigger	zombieSounds	PlaySound 	 	0.00	No
	OnTrigger	zombieSeq 	BeginSequence	 	0.00	No
"zombieSounds" is an that I’ve used to play the sound of a girl screaming when the Zombie wakes. It is not needed but things like this are easy to do and make your scripted NPC’s all the better.
*Name: zombieSounds
*Sound Name: ambient/creatures/town_child_scream1.wav
*Volume: 10
*SourceEntityName: zombie
==See also==
*Example VMF
*Example VMF backup
WiseShapedLight

In WiseVol and WiseGarageDoor01, I’ve created several methods for beams of light. In this project I’ve created the appearance of a shaped beam of light from an open window. 
In the image to the right you can see the subtle beam of light coming from the open window. Notice each end of the beam appear to be well within reason, or believable. The frame around the open window is well lit. The beam has a soft edge but is well defined. At the end is a bloom of light cast onto the brick wall. The shaped beam is created with a normal brush and the Clipping tool. Once the brush is shaped the way you want press and convert it to then click Apply.
Typically you should never use any of the model\ materials on your brushwork. Creating illusionary volumes of shaped light is an exception to that rule. The material I’ve used on this shaped brush is: models/effects/vol_light001. With the Face Edit dialog () I’ve applied this material to each face of this brush.
The FX amount for the func_illusionary has been changed from 255 to 150. Zero would be invisible and 255 is opaque. Experiment with this number for the effect you desire. One other change you need to make to the func_illusionary is to Disable Shadows and Receiving Shadows. We simply don’t want shadows on or from our shaped light. Reduce the size of your grid and be as precise as you can when you create these shaped brushes for your light. Just as important as the shaped brush and its properties are the light entities that will be shining on and through it.
To create lighting effects like this you simply can not use a normal light entity, at least not by itself.
The light on the wall, and the one shining through the shaped brush, is created with a combination of a and . For both of these use the Point At feature in the properties for their Pitch. Adjust the brightness, length and width until you have the effect desired. Make sure you check the flag No Dynamic Light for your point_spotlight. Allowing this entity to cast dynamic light can really impact in-game performance.
Inside the room with the window open I’ve placed two identical light entities to brighten up the room and to cast light onto the window frame. This is a good method to experiment with, create your other light entities first and then create normal light entities to supplement them. 
==See also==
*Example VMF
*Example VMF backup
WiseSkin

Many of the models in the Source SDK contain more than one skin. 
https://web.archive.org/web/20060225185631im_/http://www.akilling.org:80/akg/assets/wiseSkins01.jpg
If you aren’t familiar with skins think of them as clothing. A skin for a door for example can change the entire appearance and color of the door. You change the skin of a model in Hammer in the properties. Select the model and press or double-click on it in the 3D view port.
https://web.archive.org/web/20060225185637im_/http://www.akilling.org:80/akg/assets/wiseSkins02.jpg
Here’s an example of a rock with multiple skins: models\props_wasteland\rockgranite01a.mdl. Changing the default “0” to “1” or “2” would result in the three rocks shown below.
https://web.archive.org/web/20060225185643im_/http://www.akilling.org:80/akg/assets/wiseSkins03.jpg
https://web.archive.org/web/20060225185649im_/http://www.akilling.org:80/akg/assets/wiseSkins04.jpg
https://web.archive.org/web/20060225185656im_/http://www.akilling.org:80/akg/assets/wiseSkins05.jpg
Not all models have multiple skins. A lot do though.
WiseSmokeStack

This is rather simple and it creates a nice visual effect. There are lots of methods you can use to create the chimney and there are multiple models in the Source SDK that can be used, for this one I used models/props_rooftop/roof_vent004.mdl.
The entity class is prop_static.
*Collisions: Not Solid
*Disable Shadows: Yes (Decide if shadows are desired and if anything will be bumping into it.)
Next I’ve created and positioned a env_smokestack, shown in red below.
There are lots of settings for your smoke, it will be best to experiment. The settings for this example are:
*Initial State: On
*Spread at the base: 10
*Spread Speed: 15
*Speed: 30
*Particle start size: 10
*Particle end size: 30
*Emission rate: 20
*Length of smoke trail: 180
*Wind X/Y Angle: 10
*Wind Speed: 17
*Particle material: particle/SmokeStack.vmt
*Twist: 5
*Base Color (R G B): 129 129 129
*Translucency: 170
WiseSubdivide

How the subdivide tool works is most obvious when it’s used. You must start with at least two displacement faces selected. How many faces are selected is only limited by your system as the subdivide operation can become very taxing. In this project I’ve started with the map we created in WiseDisplacement01.
The shape we will create to show off the subdivide tool is a round cylinder.
#Create a cube 64x64x64 and texture it on all faces. For this example I’m going to use the material shadertest\gooinglass.
#With the face edit displacement tool select every face on the cube, hold as you left click on each face.
#Create a displacement to the power of 4.
#Click the Subdivide button.
There you have it, a perfect cylinder in just a few seconds. The subdivide tool can be used this same way to create rounded corners, pipes, etc. It is also used to round off areas of your displacement cliffs, tunnels, etc.
==See also==
*Example VMF
*Example VMF backup
*WiseColumns
WiseTrainLight

(Porter's note: I have to say, there's a lot of other methods to get these effects that usually look nicer, are easier to tune, and don't drive up compile times. Try using an info_lighting, or $selfillum, VertexLitGeneric, or UnlitGeneric in your vmt, maybe encase your object in toolsblocklight and tinker around with Minimum Light Level and render modes, and that whole group of similarly-named keyvalues.)
When using func_tracktrain and any other entities that move or rotate in your maps there are methods you can use to actually burn light onto them. As you will see in some of the images below entities can even appear to be self-illuminating.
Entities like func_tracktrain can be spawned far away from your map. The room you spawn them in can contain its own lighting.
When your func_tracktrain starts out on its first path_track, as specified in its properties, the lighting it spawned with will be burned onto the entity. The set of rotating brushes I created illustrate how important it can be to spawn object like this with the proper lighting. One of these rotating brushes has an odd looking shadow that rotates with it. The other was spawned in the lighting room. As you can see this can be controlled as well, by controlling the lighting and shadows around rotating brushwork. Notice that the prop bucket and the wooden cube were spawned in the same light room with the func_tracktrain.
==See also==
*Example VMF
*Example VMF backup
WiseUseableValveWorks

A valve that can raise and lower water.
First we'll create outputs for a func_water_analog. This is the Source entity used for water that can move.
Next make a func_door_rotating and give these outputs:
When we open the func_door_rotating, which will also turn the wheel, our func_door_rotating will Open, or rise in this case. And when we close the func_door_rotating our water will lower. You can experiment with the settings for each of these functions, some of which are speed and sounds.
There are two materials that can be used with func_water_analog: nature/water_movingplane and nature/water_dx70. I've created a sample project with 17 func_water_analog bodies of water, each with its own material. The bodies of water in the sample, (vmf and bps are included), raise and lower. Some other materials will look fine of the surface but if you get in the water, crouch down and try to look out you won't be able to with the others, only the two listed here appear to function properly.
Remember, all faces of the water brush are textured with nodraw except the top face.
==See also==
*Example VMF
*Example VMF backup