Legacy: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 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?