Player, 3D object controlling the camera, main enemy of hostile creatures, carries a backpack, may cause fadeout effects on screen and such.
Note that you can operate on player even before level is loaded, before TCastleSceneManager and such are initialized. This allows to create player before level is started (create it from scratch, or by loading from save game), and "carry" the same player instance across various loaded levels.
Dead or Blocked player behaves much like alive and normal player. For example, it still has an associated Camera that can animate by code (e.g. to apply physics to the dead player body, because player was killed when he was flying, or it's corpse lays on some moving object of the level — like elevator). However, Camera input shortcuts will be cleared, to prevent user from directly moving the camera and player.
Note that every player, just like every T3DOrient actually, has an associated and magically synchronized T3DOrient.Camera instance. Ancestor T3DOrient only takes care about synchronizing the view vectors (position, direciton, up) and doesn't care about camera otherwise. We synchronize more in TPlayer class:
Various camera inputs are automatically adjusted based on current player state (Dead, Blocked) and global PlayerInput_Xxx values, like PlayerInput_Forward.
Change InventoryCurrentItem, cycling, and automatically showing the inventory afterwards (if it's not empty). Note that you can also always directly change InventoryCurrentItem property.
procedure Update(const SecondsPassed: Single; var RemoveMe: TRemoveType); override;
Cause a fade-out effect on the screen, tinting the screen to the given Color. The TPlayer class doesn't do the actual drawing of the fade-out effect on the screen, we merely store and animate the FadeOutColor and FadeOutIntensity properties. To draw the effect, use a procedure like GLFadeRectangle inside your 2D controls drawing code, see engine tutorial for example.
procedure Attack; virtual;
procedure LoadFromFile;
Load various player properties from an XML file. Properties not specified in the indicated file will be reset to their default values. This is handy to use in a game to allow to configure player behavior by simply editing an XML file (instead of hacking code).
Overloaded parameterless version reads from file ApplicationData('player.xml').
Note that the indicated file may not exist, and it will not cause errors. Not existing file is equivalent to a file with everything set at default values.
It is Ok to call this multiple times, at any moment. This way you can make some debug command to reload player.xml file, very useful to test various player properties without restarting the game.
Flying. How it interacts with FlyingTimeout: Setting this property to any value removes any timeout set by FlyingTimeout. That is, setting this to True makes player fly indefinitely, and setting this to False makes player stop flying (regardless if flying was initialized by Flying := true or FlyingTimeout).
Set this to something > 0 to start flying for a given number of seconds. The Flying property will also change to True for this time. It will automatically change back to False after given number of seconds (you can also always just manually switch Flying back to False).
Set this only with value > 0.
When this is > 0 it means flying with a timeout (always Flying = True then), otherwise it's = 0 (which means were not flying, or flying indefinitely long, depending on Flying).
Note: while we try to always sensibly update InventoryCurrentItem, to keep the assumptions that
Inventory.Count = 0 => InventoryCurrentItem = -1
Inventory.Count > 0 => InventoryCurrentItem between 0 and Inventory.Count - 1
but you should nowhere depend on these assuptions. That's because I want to allow myself freedom to modify Inventory in various situations, so InventoryCurrentItem can become invalid in many situations.
So every code should check that
If InventoryCurrentItem between 0 and Inventory.Count - 1 then InventoryCurrentItem is selected
Else no item is selected (possibly Inventory.Count = 0, possibly not)
Disables changing the camera by user. It's useful when you want to temporarily force camera to some specific setting (you can even use handy Player.Camera.AnimateTo method to do this easily, see TWalkCamera.AnimateTo).
Controls head bobbing, but only when player is walking. See TWalkCamera.HeadBobbing for exact meaning of this. TPlayer.Camera.HeadBobbing is automatically updated as necessary.