Table of Contents
This document assumes that the majority of vehicles will be directly controllable by the player. This requires reversing the direction of vehicle updates, and diverting user inputs toward the vehicle.
The controlledBy
property sets from whom updates
to the vehicle's position will come from.
Setting the vehicle's controller to the player gives responsibility for the vehicle's movement to the player's client.
# Give control of the Ripper to the client. At this point the # client Ripper will get a .physics member. self.controlledBy = avatar.base
cell/Ripper.py
In the example above, controlledBy
is set to the
player's client, thus giving it the ability to dictate the position of the
vehicle. Setting controlledBy
back to
None returns control to the vehicle's cell.
In order to allow the vehicle to respond to user inputs, you can make the vehicle become the player.
To do this, you will need to implement a specialisation of the
vehicle's client entity (in the same file) with the name
Player
. For example, a client entity type of
<entity
name>
Avatar
would require a corresponding
PlayerAvatar
.
Setting the player:
BigWorld.player( <entity_to_become_player>
)
Changing the player as above will trigger the become player and become non-player events in the appropriate entities. You can use these callbacks to configure and later cleanup the user input handling mechanisms.
class PlayerRipper( Ripper ): def onBecomePlayer( self ): self.setupKeyBindings() self.filter = BigWorld.PlayerAvatarFilter() FantasyDemo.cameraType( keys.FLEXI_CAM ) ... def onBecomeNonPlayer( self ): self.pilotAvatar = None self.filter = BigWorld.DumbFilter() self.keyBindings = []
client/Ripper.py
Note
Be careful when changing from a player vehicle to a non-player
vehicle from within a player vehicle's member function. Changing the
player back to the Avatar
will cause the type of
the vehicle to change immediately.