PhysicsVolume

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 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
class<DamageType> DamageType
class<Actor> EntryActor
sound EntrySound
class<Actor> ExitActor
sound ExitSound
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
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...

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.

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

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?

Category Class (UT2003)
Category Class (UT2004)

Category Class Tree