Legacy:PhysicsVolume - Unreal Wiki

# Legacy:PhysicsVolume

### From Unreal Wiki, The Unreal Engine Documentation Site

UT2003 :: Actor >> Brush >> Volume >> PhysicsVolume (Package: Engine)

A PhysicsVolume is a bounding volume which affects actor physics. Each Actor is affected at any time by one PhysicsVolume.

## Properties

### Events Group (Inherited From Actor)

name Event
  This event will be triggered when a player enters the volume and untriggered when the player leaves the volume or dies in it.
name Tag
  If an event matching this tag name is triggered and a `DamagePerSec` value (see below) is specified, the value of the `bPainCausing` property is toggled.
  Note: You will have to use a VolumeTrigger intercept trigger events and delegate them to Volumes because most volumes are static actors and thus not affected by regular trigger events.

### PhysicsVolume Group

bool bBounceVelocity
bool bDamagesVehicles
  Vehicles entering this volume will take damage
bool bDestructive
bool bMoveProjectiles
bool bNeutralZone
  Players can't take damage in this volume.
bool bNoInventory
  Don't use this, it will not have the desired effect! (It will destroy Inventory actors in the volume, but since UT200x uses Pickups for things players can pick up, this is pretty much useless.)
bool bPainCausing
  This volume damages actors in it.
bool bWaterVolume
  This volume contains water. Water volumes will allow players and other actors to swim in them.
float DamagePerSec
  If `bPainCausing` is `true`, this is the amount of damage that players will take each second that they are in the volume.
class<DamageType> DamageType
  If `bPainCausing` is `true`, this is the type of damage that will be applied. The only reason to set this class is it changes the "player died" message, i.e. setting this property to "fell" gives the message "Player fell too far" etc.
class<Actor> EntryActor
  This actor is spawned at the volume's pivot point when players enter this volume.
sound EntrySound
  This sound is played when a player enters this volume.
class<Actor> ExitActor
  This actor is spawned at the volume's pivot point when players leave this volume.
sound ExitSound
  This sound is played when a player leaves this volume.
float FluidFriction
vector Gravity
  I was told that gravity is applied only each second frame and so this value is at least twice as high as the "real" gravity. This matches the ingame experience and the fact that if viewing this as m/s² it'd be ~20m/s² using Unreal Unit. This property is replicated to clients.
float GroundFriction
  This determines how slippery the floor (or other surfaces) is. 8 is default. A good setting for slippery ice is .5. Setting the `GroundFriction` to a value higher than 8 yields interesting effects; for example, pressing the forward key can cause players to move backwards.
int Priority
  determines which one of several overlapping PhysicsVolumes gets to apply its physics properties (Gravity, GroundFriction, ZoneVelocity and so on) on players and other actors in the overlapping area. The higher the Priority number, the higher the Priority (and I think every PhysVolume that you add, even if priority 0, is higher priority than the DefaultPhysicsVolume)
  Note: There is a bug in the implementation of this priority scheme in xPawn: If the player is contained within overlapping volumes and one of the volumes has `bWaterVolume` set to True, splashing sounds are likely to be played regardless of which volume has priority. See xPawn Priority Bug for more details.

float TerminalVelocity
  The maximum speed actors are allowed to have in this volume. This has no effect on actors with `bIgnoreTerminalVelocity` set to `True`.
vector ViewFlash
vector ViewFog
vector ZoneVelocity
  Does something completely ridiculous, velocity related. Unless you make your volume a water volume, all this does is seemingly randomly throw the player arond, which probably not how it was intended.

MythOpus: umm... actually, it most likely was intended for white water rafting then :)

Red: it doesn't seem random to me. It adds to your velocity in a given direction.

which is probabally good for white water rafting, (or certain convoy assault levels) and maybe conveyor belts...

IceCreamYou: Actually, ZoneVelocity adds the number specified in the x/y/z array to the player's velocity each second until the total velocity reaches the `TerminalVelocity`. The y-axis is messed up though: you have to set it to the opposite direction you want (i.e. what should be positive values have to be negative for it to work, and vice versa).

### Karma Group

float KBuoyancy
float KExtraAngularDamping
float KExtraLinearDamping

### VolumeFog Group

See Distance Fog.

bool bDistanceFog
  There is distance fog in this physicsvolume.
color DistanceFogColor
  The distance fog's color.
float DistanceFogStart
  The distance at which the fog starts.
float DistanceFogEnd
  The distance at which the fog reaches its maximum density.

Note: DistanceFog does not cover surfaces with FakeBackDrop applied. The most important consequence of this is in outdoor maps: if anything sticks up above the horizon line, it will be fog-colored but the surroundings won't. This is why fogrings (cylindrical static meshes in the skybox set to the same color as the fog) are necessary: they create the illusion that the fog actually does cover everything.

### Hidden

PhysicsVolume NextPhysicsVolume
  Next item in the linked list of PhysicsVolumes.
Info PainTimer
  Since volumes are static, this actor is needed as timer for applying damage to actors inside the volume.

## Functions

CausePainTo( Actor Other )
  Hurts/damages the actor.
PlayEntrySplash( Actor Other )
PlayExitSplash( Actor Other )
TimerPop( VolumeTimer T )

### Inherited From Actor

PostBeginPlay()
  In versions prior to 2186 PostBeginPlay sets up a VolumeTimer on the server if bPainCausing was true. Now it only calls the superclass implementation.
Trigger( Actor Other, Pawn EventInstigator )
  Triggering toggles the bPainCausing property if the DamagePerSec value isn't 0.
Touch( Actor Other)
  Does various things when actors touch the volume:
  Inventory subclasses are given a LifeSpan of 1.5 when bNoInventory=True and the Inventory doesn't have an Owner.
  Actors with PHYS_Projectile or Effects with PHYS_None get some Velocity added if bMoveProjectiles is True.
  Actors that can't exist in a pain volume are destroyed if this is a pain volume, other actors are damage.
  If this is a water volume (bWaterVolume=True) the PlayEntrySplash function is called.
Untouch( Actor Other)
  Calls the PlayExitSplash function if this is a water volume and the actor exiting the volume can cause splashes.

## Events

ActorEnteredVolume( Actor Other )
  Called when an actor entered the volume.
ActorLeavingVolume( Actor Other )
  Called when an actor leaves the volume.
PawnEnteredVolume( Pawn Other )
  Called when a Pawn entered the volume. This triggers the volume's Event with the pawn as the instigator.
PawnLeavingVolume( Pawn Other )
  Called when a Pawn leaves the volume. This untriggers the volume's Event with the pawn as the instigator.
PhysicsChangedFor( Actor Other )
  Called when an actor in this PhysicsVolume changes its physics mode.

## Known Subclasses

    PhysicsVolume
      +- DefaultPhysicsVolume
      +- LadderVolume
      +- LavaVolume
      +- PressureVolume
      +- WaterVolume
      +- xFallingVolume

## Related Topics

- VolumeTrigger – Able to trigger Volumes, used here to toggle Pain.

## Discussion

Off-Kilter: I don't know about the note on bNoInventory. LavaVolume has this set to true by default, IIRC. Also, for bWaterVolume I've used this to get people to float around and be somewhat buoyant in lava. Is this the correct way?

Wormbo: bNoInventory seems to be a leftover from older engine versions where Inventory (UT) was the base class for all pickups as well. However, in UT2003 Inventory only is the base class for items in a player's inventory. The Pickups of those items aren't subclasses of Inventory anymore.
In UT bNoInventory=True for a ZoneInfo (UT) meant "destroy all items that somehow enter this zone." The code for this was copied over to UT2003 without the neccessary modifications, so it still destroys Inventory class actors, but not any Pickups. It is highly unlikely that any Inventory actors will enter a LavaVolume. The only exception is when the origin of the map is in such a volume. In that case it might cause problems with inventory items spawned of players because those are invisible and usually spawn at the origin. If they spawn inside a bNoInventory volume they might get destroyed immediately and the player doesn't get what he just picked up somewhere else on the map.

Dr.AwkwArD: for Priority, is priority given to the lowest or highest number? Also, is the volume with priority supposed to have *all* of its physics settings obeyed? As you can probably guess, I'm having some trouble with this–seeing squirly behaviour from the intersection of a WaterVolume and a standard PhysVolume...

Dr.AwkwArD: Okay, I've figured out that the higher the number, the higher the priority–and I think every PhysVolume that you add, even if priority 0, is higher priority than the DefPhysVolume. I'll add this info to the var's definition above. I'm still seeing peculiarities with overlapping PhysVolumes, though. For instance, if Volume0 (lowest priority) is set to bPainCausing=true and Volume1 (higher priority) is set to bPainCausing=false (and Volume1 is inside of Volume0), if you stand within Volume1 you still take damage from Volume0. So far, the only way that I've been able to counter the damage caused by Volume0 is to set Volume1 to bNeutralZone=true, which means that *no* damage can be taken within its boundries. So now if I stand in Volume1 I no longer take damage from Volume0–or anything, for that matter, since I'm in a neutral zone. This is obviously not the effect that I'm looking for. Any thoughts or experience with this?

EntropicLqd: I must confess I've almost always tried to ensure that my volumes do not overlap. If you have voluume 1 inside of volume 0 then what you could do is create the shap you want for volume 0, substract the shape you want for volume 1 from it and then intersect (or de-intersect depending) to grab the shape of volume 0 minus the shape of volume 1. You can then add your two volumes and they won't overlap.

Dr.AwkwArD: Well, I'm actually moving Volume1 in and out of Volume0 – it's dynamic – so I'm kinda stuck. In a static situation, you're completely correct, though.

Jezinator: Ive got a rather interesting problem with water volumes i can't figure out. Im using a vertical water volume, so that the players are walking into the volume rather than dropping in. This is fine and works well, but is there some way of rotating the splashes so that they are also vertical? This would make it so unbelievably cool looking if its possible! I cant seem to find the actor it uses to create the splash though.

MythOpus: So You Are Going To Custom Code It Then? Don't Think It's Possible With Stock Water Volumes...

SuperApe: Although there is a `BACKUP_Gravity` hidden property all set up to toggle gravity when triggered (by a VolumeTrigger), the code just isn't there in the Trigger function. Modifying above link notation.

Anonymous: It seems like the FluidFriction value has no effect unless bWaterVolume is true. Is there a way to force the effects of FluidFriction without the delayed damage caused by a WaterVolume?

JeffMOD: Is there any way to attach a Physics Volume to a Mover? (eg. A Mover with a custom Ran over message, that does'nt need a wall to kill) PLEASE! HELP!

Categories: Legacy Class (UT2003) | Legacy Class (UT2004) | Legacy Class Tree

##### Views

- Legacy
- Discussion
- Current revision

##### Search