Type Members

1.  case class Account(id: Int, name: String, gm: Boolean = false) extends Product with Serializable
2.  class AmmoBox extends Equipment
3.  class BoomerDeployable extends ExplosiveDeployable
4.  class BoomerTrigger extends SimpleItem with RemoteUnit
5.  trait CommonNtuContainer extends NtuContainer
6.  class ConstructionItem extends Equipment with FireModeSwitch[ConstructionFireMode]

   A type of Equipment that can be wielded and applied to the game world to produce other game objects.
   
   Functionally, ConstructionItem objects resemble Tool objects that have fire mode state and alternate "ammunition." Very much unlike Tool object counterparts, however, the alternate "ammunition" is also a type of fire mode state maintained in a two-dimensional grid of related states.

   A type of Equipment that can be wielded and applied to the game world to produce other game objects.
   
   Functionally, ConstructionItem objects resemble Tool objects that have fire mode state and alternate "ammunition." Very much unlike Tool object counterparts, however, the alternate "ammunition" is also a type of fire mode state maintained in a two-dimensional grid of related states. These states represent output products called deployables or, in the common vernacular, CE. Also unlike Tool objects, whose ammunition is always available even when drawing the weapon is not permitted, the different states are not all available if just the equipment itself is available. Parameters along with these CE states indicate whether the current output product is something the player is permitted to utilize.

7.  class ExplosiveDeployable extends ComplexDeployable with JammableUnit
8.  class ExplosiveDeployableControl extends Actor with Damageable
9.  class ExplosiveDeployableDefinition extends ComplexDeployableDefinition
10.  class Kit extends Equipment

    A one-time-use recovery item that can be applied by the player while held within their inventory.

11.  class LocalLockerItem extends PlanetSideServerObject

    A LocalLockerItem is a server-side object designed to populate a fake unshared space within a shared space.

    A LocalLockerItem is a server-side object designed to populate a fake unshared space within a shared space. It is a placeholder intended to block out the existence of locker objects that may or may not exist. All clients reserve the same internal range of user-generated GUID's from 40150 to 40449, inclusive. All clients recognize this same range independent of each other as "equipment in their own locker." The GUID's in this locker-space can be reflected onto the zone GUID. The item of that GUID may exist to the client. The item of that GUID does not formally exist to the server, but it can be searched.

    See also

    Zone.MakeReservedObjects

12.  class LocalProjectile extends PlanetSideServerObject

    A LocalProjectile is a server-side object designed to populate a fake shared space.

    A LocalProjectile is a server-side object designed to populate a fake shared space. It is a placeholder intended to block out the existence of projectiles communicated from clients. All clients reserve the same internal range of user-generated GUID's from 40100 to 40124, inclusive. All clients recognize this same range independent of each other as "their own featureless projectiles."

    See also

    Zone.MakeReservedObjects
Projectile.BaseUID
Projectile.RangeUID

13.  trait NtuContainer extends TransferContainer
14.  trait NtuContainerDefinition extends AnyRef
15.  trait NtuStorageBehavior extends Actor
16.  class OffhandEquipmentSlot extends EquipmentSlot

    A size-checked unit of storage (or mounting) for Equipment.

    A size-checked unit of storage (or mounting) for Equipment. Unlike conventional EquipmentSlot space, this size of allowable Equipment is fixed.

17.  trait OwnableByPlayer extends AnyRef
18.  abstract class PlanetSideGameObject extends IdentifiableEntity with WorldEntity

    A basic class that indicates an entity that exists somewhere in the world and has a globally unique identifier.

19.  class Player extends PlanetSideServerObject with InteractsWithZoneEnvironment with FactionAffinity with Vitality with ResistanceProfile with Container with JammableUnit with ZoneAware with AuraContainer
20.  class SensorDeployable extends ComplexDeployable with Hackable with JammableUnit
21.  class SensorDeployableControl extends Actor with JammableBehavior with DamageableEntity with RepairableEntity
22.  class SensorDeployableDefinition extends ComplexDeployableDefinition
23.  case class Session(id: Long = 0, zone: Zone = Zone.Nowhere, account: Account = null, player: Player = null, avatar: Avatar = null, zoningType: zones.Zoning.Method.Value = Zoning.Method.None, deadState: packet.game.DeadState.Value = DeadState.Alive, speed: Float = 1.0f, flying: Boolean = false) extends Product with Serializable
24.  class ShieldGeneratorControl extends Actor with JammableBehavior with DamageableEntity with RepairableEntity
25.  class ShieldGeneratorDefinition extends ComplexDeployableDefinition
26.  class ShieldGeneratorDeployable extends ComplexDeployable with Hackable with JammableUnit
27.  class SimpleItem extends Equipment
28.  trait SpawnPoint extends AnyRef
29.  trait SpawnPointDefinition extends AnyRef
30.  class Telepad extends ConstructionItem with TelepadLike
31.  class TelepadDeployable extends SimpleDeployable with TelepadLike
32.  class Tool extends Equipment with FireModeSwitch[FireModeDefinition] with JammableUnit

    A type of Equipment that can be wielded and loaded with certain other game elements.
    
    "Tool" is a very mechanical name while this class is intended for various weapons and support items.

    A type of Equipment that can be wielded and loaded with certain other game elements.
    
    "Tool" is a very mechanical name while this class is intended for various weapons and support items. The primary trait of a Tool is that it has something that counts as an "ammunition," depleted as the Tool is used, replaceable as long as one has an appropriate type of AmmoBox object. (The former is always called "consuming;" the latter, "reloading.") Some weapons Chainblade have ammunition but do not consume it.

33.  class TrapDeployable extends ComplexDeployable
34.  class TrapDeployableControl extends Actor with DamageableEntity with RepairableEntity
35.  class TrapDeployableDefinition extends ComplexDeployableDefinition
36.  class TurretControl extends Actor with Check with JammableMountedWeapons with MountableBehavior with DamageableWeaponTurret with RepairableWeaponTurret

    control actors

37.  class TurretDeployable extends ComplexDeployable with WeaponTurret with JammableUnit with Hackable
38.  class TurretDeployableDefinition extends ComplexDeployableDefinition with TurretDefinition
39.  class Vehicle extends AmenityOwner with MountableWeapons with InteractsWithZoneEnvironment with Hackable with FactionAffinity with Deployment with Vitality with OwnableByPlayer with StandardResistanceProfile with JammableUnit with CommonNtuContainer with Container with AuraContainer

    The server-side support object that represents a vehicle.
    
    All infantry seating, all mounted weapons, and the trunk space are considered part of the same index hierarchy.

    The server-side support object that represents a vehicle.
    
    All infantry seating, all mounted weapons, and the trunk space are considered part of the same index hierarchy. Generally, all seating is declared first - the driver and passengers and and gunners. Following that are the mounted weapons and other utilities. Trunk space starts being indexed afterwards. To keep it simple, infantry seating, mounted weapons, and utilities are stored separately herein. The Map of Utility objects is given using the same inventory index positions. Positive indices and zero are considered "represented" and must be assigned a globally unique identifier and must be present in the containing vehicle's ObjectCreateMessage packet. The index is the mount position, reflecting the position in the zero-index inventory. Negative indices are expected to be excluded from this conversion. The value of the negative index does not have a specific meaning.
    
    The importance of a vehicle's owner can not be overlooked. The owner is someone who can control who can sit in the vehicle's seats either through broad categorization or discriminating selection ("kicking") and who has access to and can allow access to the vehicle's trunk capacity. The driver is the only player that can access a vehicle's saved loadouts through a repair/rearm silo and can procure equipment from the said silo. The owner of a vehicle and the driver of a vehicle as mostly interchangeable terms for this reason and it can be summarized that the player who has access to the driver mount meets the qualifications for the "owner" so long as that player is the last person to have sat in that mount. All previous ownership information is replaced just as soon as someone else sits in the driver's mount. Ownership is also transferred as players die and respawn (from and to the same client) and when they leave a continent without taking the vehicle they currently own with them. (They also lose ownership when they leave the game, of course.)
    
    All seats have vehicle-level properties on top of their own internal properties. A mount has a glyph projected onto the ground when the vehicle is not moving that is used to mark where the mount can be accessed, as well as broadcasting the current access condition of the mount. As indicated previously, seats are composed into categories and the categories used to control access. The "driver" group has already been mentioned and is usually composed of a single mount, the "first" one. The driver mount is typically locked to the person who can sit in it - the owner - unless manually unlocked. Any mount besides the "driver" that has a weapon controlled from the mount is called a "gunner" seats. Any other mount besides the "driver" mount and "gunner" seats is called a "passenger" mount. All of these seats are typically unlocked normally. The "trunk" also counts as an access group even though it is not directly attached to a mount and starts as "locked." The categories all have their own glyphs, sharing a red cross glyph as a "can not access" state, and may also use their lack of visibility to express state. In terms of individual access, each mount can have its current occupant ejected, save for the driver's mount.

    See also

    Vehicle.EquipmentUtilities