Exploits

From Valve Developer Community
(Redirected from Portal Glitch Prevention)
Jump to: navigation, search

Stub

This article or section is a stub. You can help by adding to it.

Source has been around for over a decade. Half-Life was in a previous millennium. No doubt, games that have existed that long usually have a long list of known bugs, glitches, and tricks by now, and any speedrun video will show you that people know how to use them (but, most speedrunners use older versions of the games, 'cause many bugs have been patched by Valve). If you're the by-the-book kind of modder/mapper, take a look at some unfixed things a smart (or foolish) player can do to break your maps, escape/become trapped, or skip gameplay. Any mapper might be interested in reading this, as some exploits can open new areas to view a map from, which could mean more visual work for you.

Idea: Perhaps instead of limiting players, consider using this information to hide an easter egg or something like that.

General

  • By mashing the jump and use buttons, physics objects can be used to climb walls, or even to fly in midair.

Demonstration Portal 2 fixes this issue by implementing a long delay between the times that +use inputs are accepted, and making objects non-solid when held by the player.

  • Water cancels fall damage.

If you can't alter code, a possible solution is to use trigger_hurts. Appropriate damage amounts depends on the height of the fall and the depth of the water. Unless the height of the fall would kill the player instantly, use an OnHurt output to disable the trigger after hurting the player once, and also add necessary logic to disable the trigger if the water is approachable by a safer route, and to enable it again when the player reaches a dangerous height. As you can imagine, this can quickly become an unfavorable solution when multiple height levels or bodies of water are involved.

Versions of Source with VScript could possibly control the damage of the trigger based directly on player Z speed.

For coders, open gamemovement.cpp and look for this where CheckFalling() is defined:

if ( player->GetWaterLevel() > 0 )
{
	// They landed in water.
}

Delete it entirely, and also remove the else statement below it (not the code inside it, just the else{}).

Half-Life 2

Vehicles

It is difficult, but a vehicle can clear even this height, on d2_coast_04.
  • When punted the right way with the Gravity Gun, the Buggy and Airboat may send a player flying very high up, sometimes over the maximum distance an antlion can jump, and in very rare cases, enough to launch from the sea level in Lost Coast to the lift near the top of the map.

This can be a major issue when your level design is vertical, and could also allow the player to jump or shoot over some obstacles. Falling from heights like this can do major fall damage, but see above about water. Damage can also be alleviated by entering the vehicle before hitting the ground, or landing the right way on a slope. Possible fixes are simply designing your maps to accompany for this, or making vehicles less jumpy, possibly by increasing their mass in scripts\vehicles\. (This can also affect acceleration and jumping abilities, so don't increase it too much.)

An example of this, on d1_canals_08. This allows the user to skip the entire raiding of the outpost. Note that the height of the rails is enough to keep the player from making it over, but the spot with no rail is close enough to be entered through.
  • The airboat's shape makes it a very quick and useful ramp.

The best fix for this is simply to design your map to accompany that height (about 200 units, including jumping and crouching). You can also use player clips, but be careful as it might diminish realism.

Not so good!
  • The airboat is rather light. It is very easy to push out of reach with the gravity gun.

With the vehicle out of reach, a player would have to load from a previous save, or possibly start over an entire chapter. Increase the airboat's mass in scripts\vehicles\. You can also use clip brushes, but be careful as it might diminish realism. An extra smart player could also punt the airboat and then press the USE key to enter it before it leaves their reach, which can give them a huge advantage.

Antlions can't do a thing here! An acid antlion, however...
  • Standing on a large vehicle outsmarts some NPCs, especially ones that cannot use bullets or other projectiles.

NPCs do not consider vehicles to be ground that can be stood on, meaning the player is out of their reach.

Blank image.pngTodo: Solutions? There's probably a reason vehicles and NPCs don't like to touch.
A perfect place to do an enter clip on d1_canals_08. If this trigger never fires, the large canal door never closes, so the player can then drive straight through the map.
  • When a player enters a vehicle, they aren't actually sliding into the vehicle how it appears. They are teleported from where they were before entering into the driver's seat/final camera destination. This allows a poorly-placed trigger to skipped, also known as Enter Clipping.

Unless your trigger needs to be a very specific size, just make the trigger larger, or have it detect vehicles too. Only change code if you find it to be absolutely necessary.

Weapons

  • The force of explosions created by weapons can boost players. (Like rocket jumping in Team Fortress 2)

The force from explosions is mostly horizontal, not vertical. Also, explosions that are forceful enough to propel the player significantly are also pretty damaging to them, so repeated uses aren't very doable. Design your maps to account for the possible distances. You can also use player clips, but be careful as it might diminish realism.

  • Players can stand on physics objects, punt them downwards with the gravity gun, and be propelled upward.

This is probably preventable by having moving objects ignore the gravity gun when a player is standing on them. If you cannot alter code in your situation, careful level design is the next best bet.

Not every prop is as equally exploitable. Here are props known to boost particularly well:


  • props_c17\furniturecouch001a
  • props_c17\furnitureshelf001a
  • props_c17\furniturewashingmachine001a
  • props_c17\trappropeller_blade
  • props_c17\tv_monitor01
  • props_interiors\radiator01a
  • props_junk\pushcart01a
  • props_lab\citizenradio
  • props_lab\filecabinet02
  • props_wasteland\prison_bedframe001a
  • props_wasteland\prison_bedframe001b
  • props_vehicles\tire001a_tractor
An antlion can be used to travel from the roof of the red building to the white wood board across the road.
  • QPhysics NPCs that can be moved via the gravity gun can be used to clear medium to large gaps if the player stands on one, and jumps at the same time as they punt the NPC.

This only concerns headcrabs and antlions. This can probably be fixed similar to the last issue, by having NPCs ignore the gravity gun when a player is standing on them. If you cannot alter code in your situation, careful level design is the next best bet. A better solution might be to simply make the player not take inertia from NPCs they stand on.

Blank image.pngTodo: How do you do that? Also which method really is best?
On d3_c17_12b, a Strider fires a cannon shot that is vital to the player's progression. Killing the strider before it fires this shot would leave the player trapped. Valve knew this, and made it so that the support beam breaks whenever the strider dies, just in case.
  • NPCs such as striders, helicopters, and gunships can be hurt by more than just rockets. A player killing one of these in an unintended time and place can have unwanted consequences depending on the situation.

This isn't really a bug, in fact Valve intended this. Any of these can be used to hurt large enemies:

  • Frag grenades (which can be aided by the gravity gun)
  • SMG grenades
  • Any Combine energy ball (also aimable with the gravity gun)
  • Physics damage
    Confirm:Seen in Transmissions: Element 120 on striders. Check to make sure that was genuine damage, not scripted.

Problems with this aren't usually encountered in Half-Life 2 because Valve accounted for it as best as possible, but imagine how this could have affected gameplay on d3_c17_12b and d3_c17_13, where progression relies heavily on strider NPCs dying and using scripted cannon shots. If Valve did not consider the possibility of a player killing a strider before reaching the place they want the player to go, the player could potentially be trapped.

The best method of avoiding issues with this is to ensure the player doesn't have those mechanics as an option (probably through scarcity), or simply plan for the possibility.

Water

  • Some coast maps have a sweet spot in the water where antlions can't go without drowning, but leeches are still farther out in the water.

This is an issue seen multiple times in Highway 17 and Sandtraps. This makes it easy for a player to travel without a vehicle, and take virtually no damage. To prevent this, keep all water shallower than 32 units, (the maximum water level an antlion can move in) and extend your trigger_waterydeath to anywhere deeper than that.

This solution isn't 100% effective. Antlions usually won't go directly at the player, and they don't change trajectory for moving or ducking targets. 32 units is also unusually shallow water for leeches to swim in.


This is an issue in Half-Life 2: Lost Coast. In this map, the trigger is placed slightly below the surface. If the player jumps and crouches at the surface of the water, they can continuously jump in and out of the trigger before they get hurt, enabling the player to access areas of the map they shouldn't be in.

This is not an issue in any Half-Life 2 maps, as the triggers in those maps actually go a long way above the surface, too.

Portal Series

Portals

Portal 1 bump.png
  • When a portal is shot somewhere currently containing a different portal, the first portal is usually placed to the side of that other one. This can happen even through barriers, such as glass.

Put a func_portal_bumper on the barrier to prevent portal bumping. Also try using func_noportal_volume and sv_portal_placement_never_bump 1.


  • In Portal 1, portal shots take time to travel. In that amount of time, the player can cross through a portal before the shot lands on another wall.


Demonstration Portal 2 fixes this problem by making portals be placed instantly when the gun fires. Portal 2 has a similar issue, but it requires more precise timing, and the camera's orientation has to change when crossing the portal.

Gel

See also: Gel Mobility

  • When a player collides with a cube, it can cause them to be nudged upward. When repulsion gel is added to the equation, it lets the player reach any height, due to repulsion gel not simulating a terminal velocity.

There's not much of a way to stop this, except for making cubes nonsolid. Better puzzle design would be recommended, however. There is no way to simply set a maximum bouncing height.


  • When a player crouches on propulsion gel, moves forward, and uncrouches, they will instantly accelerate to the maximum gel speed.

Situations where this is a problem are rare. Try one of these:

  • The console command sv_speed_paint_max. Affects maximum gel speed, even when done the intended way, however. Requires restart to take effect.
  • Redesign your map so that the speed isn't an issue.


  • When a player throws a cube while running on propulsion gel, the cube's velocity is magnified greatly, including upward.

This just means that they can throw a cube really high. Careful level design is the answer to this, if it ever is a problem.

Excursion Funnels

  • Due to some crouch status issue, an excursion funnel can be used to trick the game into giving the player a noclip-like state.
Blank image.pngTodo: There's no known prevention for this.

This bugged state can be preserved across map loads. See this page for more information.

See also