This class may or may not be in UT2004.
SVehicle stands for Skeletal Vehicle.
- bool bDrawDriverInTP
- Whether to draw the driver when in 3rd person mode.
- bool bDrawMeshInFP
- Whether to draw the vehicle mesh when in 1st person mode.
- class<Actor> DestroyEffectClass
- name DriveAnim
- Animation to play while driving.
- vector DrivePos
- Position (rel to vehicle) to put player while driving.
- rotator DriveRot
- Rotation (rel to vehicle) to put driver while driving.
- array<vector> EntryPositions
- Positions (rel to vehicle) to create triggers for entry.
- array<vector> ExitPositions
- Positions (rel to vehicle) to try putting the player when exiting.
- vector FPCamPos
- Position of camera when driving first person.
- int MaxViewPitch
- Maximum amount you can look up and down
- int MaxViewYaw
- Maximum amount you can look left and right
- float Rise
- between -1 and 1
- float Steering
- between -1 and 1
- float Throttle
- between -1 and 1
- float TPCamDistance
- vector TPCamLookat
- float VehicleMass
- array<SVehicleWheel?> Wheels
- Wheel data
- bool bGetOut
- Pawn Driver
- array<SVehicleTrigger?> EntryTriggers
- SVehicleFactory ParentFactory
- ShadowProjector VehicleShadow
- function TakeDamage(int Damage, Pawn instigatedBy, Vector hitlocation, Vector momentum, class<DamageType> damageType)
Same as in KVehicle, except pc.PawnDied(self) is commented out.
- event EncroachedBy( actor Other )
Same as in KVehicle.
- simulated function FaceRotation( rotator NewRotation, float DeltaTime )
Overides this pawn function because vehicles ignore this call.
- event VehicleStateReceived();
Same as in KVehicle.
- native event UpdateVehicle( float DeltaTime );
Do script car model stuff here - but DONT create/destroy anything
- simulated function PostNetBeginPlay()
A simple, abstract version of the one in Kcar.
Do any general vehicle set-up when it gets spawned.
This function just basically creates triggers for gettting into the vehicle like the bulldog class.
- simulated event SVehicleUpdateParams()
This event serves the same purpose as KVehicleUpdateParams(): to reset any vehicle physics related stats.
Called when a parameter of the overall articulated actor has changed (like PostEditChange)
The script must then call KUpdateConstraintParams or Actor Karma mutators as appropriate.
- simulated function ClientKDriverEnter(PlayerController pc)
Same as before in KVehicle (events called on driver entering/leaving vehicle).
- function KDriverEnter(Pawn p)
- simulated function ClientKDriverLeave(PlayerController pc)
- function bool KDriverLeave(bool bForceLeave)
- simulated function Destroyed()
Same, but also destroys triggers used for getting in and the shadow projector.
- simulated event Tick(float deltaSeconds)
- simulated function PostBeginPlay()
This function is *new* but it just glues a shadow projector on.
- simulated function bool SpecialCalcView(out actor ViewActor, out vector CameraLocation, out rotator CameraRotation )
This has been extended a bit and includes fist person as well as third.
O-GL: Sorry for the lack of info on this page ... help! Is it just me or is SVehicle very similar to KVehicle?
MythOpus: IT is. It just uses a [Sketelal system]?
AlphaOne: What is the difference between a SCopter and a SHelicopter?
Foxpaw: I don't think SVehicle even uses a skeletal system. I think the distinction is that KVehicles use Karma, while SVehicles use proprietary Unreal physics. (PHYS_Falling and such) I think the "skeletal" comes from the fact that non-static meshes (aka vertex meshes) are being called skeletal meshes by everyone now. And that's probrably what this class is designed to use. Or something.
Wormbo: No, SVehicles use Karma and skeletal meshes, that's what the Epic people tell us.
Foxpaw: Oh. So it's just a KVehicle with DT_Mesh? It's already known (at least it's on Karma) that a Karma actor can have any drawtype.. so I'm figured there would have to be some logical reason to make it a different class. Unless Epic doesn't realize that you can have a different drawtype with Karma and hacked it in natively?
O-GL: KVehicle is DT_Mesh. Bulldog is the only one with DT_StaticMesh. What I didn't realize before is that skeletal meshes (aka animations) can have some sort of karma collision. I always used to think only static meshes could have karma collision information attached to them ... apparantly not http://udn.epicgames.com/Content/AnimBrowserReference#Collision is this new? Anyway, I'm sure modellers would prefer the static mesh way where they could create a Karma hull within a program such as 3dsmax and export it with the model. Using primitives in UED sounds ... primitive . Also, if that and the seemingly hackish physics don't turn you away from SVehicles, the word 'native' in every class probably will. I hope its not the same in UT2004.
Foxpaw: Not sure if you noticed on Karma or not, but as I said, any drawtype can use Karma. (not sure if Epic realizes this, maybe that's why they made this class) Even sprites can use Karma. Just set staticmesh to the mesh you want to use for the dynamics, tgeb set DrawType to whatever you want to be displayed. The Static Mesh is always used for dynamics, but does not require DT_StaticMesh to work.
Wormbo: The DrawType only specifies how to display an actor. Karma always uses the StaticMesh for its calculations. I'm sure Epic is fully aware of this, and sice classes allow logical grouping of functionality it makes perfectly sense to create a new class for karma vehicles that use skeletal meshes instead of combining multiple static mesh actors.
O-GL: Any comments on the [UDN link I posted]? Why were they talking about adding karma collision to an animation in the animation browser? It seems that you do not require a .usx with karma collision data anymore, but instead, you can use a .ukx (ie DT_Mesh and mesh=) with no need for static meshes. Wormbo, I think the main issue is that Epic prefer to add items onto bones instead of constraints because its much easier. Like for example vehiclular turrets and characters could just be attached to a bone and manipulated accordingly. And, I guess, the characters and turrents wouldn't rotate realistically because they are oriented according to the rotation of the bone they are attached to (instead of being motorized physically to achieve a certain rotation).
Foxpaw: I did go to that UDN link - it does appear that it is a way to add a more precise collision to a model that would normally have cylinder collision. However, I don't know if that applies all the time, or only when using PHYS_Karma or PHYS_KarmaRagdoll. Well. To that I say.. I don't like it! Skeletal meshes are slow, mmkay?