I search for solutions in this order: Past Code, Unreal Source, Wiki, BUF, groups.yahoo, google, screaming at monitor. – RegularX


From Unreal Wiki, The Unreal Engine Documentation Site
Jump to: navigation, search

An Actor's PhysicsType is set in the Movement -> Physics property. Use the SetPhysics() method to change.

(new in UT2003)
Automatically applies the gravity of the current zone. Pawn-set acceleration in the Z direction is ignored.
The Pawn or Actor can move independantly from gravity. Velocity on the Z axis is ignored (only in UT?).
This is is a fun Physics type. When you set an actors physics to PHYS_Hovering, it, er, hovers a few UU off the ground. If you do this to an xPawn, for example, it will act kind of like a hovercraft. Friction is reduced (so you slide around, and slide down ramps), and if you go at speed up an incline you can do some massive jumps. Good fun. (new in UT2003)
Used in conjunction with bInterpolating in Actor. Seems to also use the PhysRate and PhysAlpha parameters (which I cannot find in UT2003.) I recommend against its use. Seems to be a leftover from the pre-Matinee days.
Signals an Actor is to be affected by the Karma engine. (new in UT2003)
This is used for dead pawns. See Karma Ragdoll. (new in UT2003)
Applies to an Actor when they are climbing a Ladder (UT). (new in UT2003)
Used for Movers!
No native physics code is applied.
Uses velocities on all 3 axes but DOES NOT use the current Zone's ZoneGravity and ZoneFluidFriction members to adjust velocity. This means that actors with a velocity are not affected by gravity or friction. Actors with this physics setting do not have any freedom of movement. Acceleration is also processed (please check this!).
(removed in UT2003)
(new in UT2003)
Only rotation changes. Location doesn't change. If bRotateToDesired is false, then the Actor rotates according to RotationRate. If bRotateToDesired is true, then the Actor rotates to the rotation specified by DesiredRotation at the speed specified by RotationRate.
Similar to PHYS_Walking except it applies to an Actor against any surface, not just a "ground" surface. An Actor in PHYS_Spider will move against a horizontal OR vertical surface just like in PHYS_Walking. When the end of the surface is reached the Pawn will be set to PHYS_Falling. PHYS_Spider only works on one plane, it will not allow a Pawn to move across perpendicular walls.
Similar to PHYS_Flying, but also take the zone's FluidFriction into account. (also Pawn (UT) related)
Used to set an Actor to follow its Owner. An Actor set this way has no physics of its own, (*including collision) and simply follow their Owner around. NOTE: There are two settings in the Actor class which can specify the actions of a PHYS_Trailer. First is Actor.bTrailerPrePivot, which, when set to True, causes the Actor in PHYS_Trailer to be positioned away from its Owner by the vector value set in Actor.PrePivot. If not set or left at 0, the Actor in PHYS_Trailer will have the same location as its Owner. Secondly, there is Actor.bTrailerSameRotation, which causes the Actor in PHYS_Trailer to have the same Rotation as its Owner no matter where it is.
Native physics code for Pawn classes only. Applies all the things that make a pawn move around on the ground. Must have a Base set, without a Base to walk on, this turns to PHYS_Falling.


RoninLord: The physics variables PHYS_RootMotion, PHYS_KarmaRagDoll, PHYS_Hovering and PHYS_CinMotion are not used in any of the Unreal Tournamnet 2003 source files and so probably only have significance to the engine.

Eldhrin: I would expect that we may see these in future games on the new Unreal engine builds, such as Unreal II. Although Deus Ex 2's going to be completely different probably... different physics engine.

DJPaul: Yes. It will be interesting to compare the relative merits of both Karma and Havok physics engine. Also, it will be fun to see how the Wiki evolves to handle information for both Physics.

SocratesJohnson: In my experience PHYS_Flying does not ignore Z velocity. My Freefall mutator uses it exclusively and I have no problems in the Z direction. It does apply a strange 'drag' on the velocity in all direcitons, though. Perhaps this was a change for UT2003? I've added a few notes to the physics types above from my own fiddling, please correct me if I'm wrong.

Foxpaw: I think it's a bit unfair to say that Karma Ragdolls are used only for dead pawns.. that's all epic uses them for but they have other possibilities.

Quad PHYS_Walking, PHYS_Flying and I'm sure others all restrict the maximum velocity to the appropriate *Speed variable's setting. However, PHYS_Falling does not.

Durandal Where are these stored? Is it possible to create new PHYS_ types, or alter variables of existing ones? I'm thinking things like changing the friction value of Hovering, that sort of thing; I'm working on a mut that needs a way of setting players to zero-friction, and Physics types seemed the best way, especially using Hovering as a start point, except I can't find any way of altering them.

Wormbo: Physics types are values of the enum EPhysics. UnrealScript doesn't provide ways to change enums after they have been declared, so the only way to add physics types would be an engine license. Mods cannot create their own physics types.

smattbac: "Native physics code for Pawn (UT) class only." Does that only apply to the original UT, since ONSMineProjectile seems to use PHYS_Walking?

SuperApe: Good catch. That's a mistake. It should read, "... for Pawn classes only.", and not be explicitly associated with any engine version. All Pawns use PHYS_Walking.

smattbac: What I meant was that if the "PHYS_Walking is only for Pawns" was only true in Unreal Engine 1, but not in 2.x, since ONSMineProjectile is a subclass of Projectile.

SuperApe: I suppose that it was originally meant for Pawns, but has become useful for other things since UT.

Saishy: Quad, I think Airspeed does limit PHYS_Flying speed. Also, sadly to know we can't create new PHYS_ types, but how do we modify existing ones?

Related Topics[edit]