Important concepts

Object and actor creation
Objects are created with the New keyword. Actors are created with the Spawn method. link

When a Trigger is touched by a valid object, usually a Player or some other type of Pawn, it causes a certain event to be initiated. However, if a Trigger is listening for an event and detects it, then it is turned on or off according to its state and whether it was on or off to begin with. link

In replication, the NetMode property of the Level indicates what type of network game or standalone game is being played.
(Level.NetMode == NM_ListenServer) – listen servers (with a local player)
(Level.NetMode == NM_DedicatedServer) – dedicated servers (no local player)
(Level.NetMode == NM_Client) – clients
(Level.NetMode == NM_Client && bNetOwner) – owner clients (special case of client where the local player is the Owner of the actor in question)
(Level.NetMode == NM_Standalone) – standalone games

Role link
Role is a concept in replication. Actors have two properties to define their role on server and client in network games: Role and RemoteRole. Role always tells us about the actor’s local role while RemoteRole tells about the actor’s role on the other side of the network. When an actor is replicated to a client, its Role and RemoteRole properties are swapped there.
ROLE_None: In RemoteRole This means that none of the actor’s attributes or functions will be replicated at all. Examples for this kind of actors are the GameInfo, Mutators and GameRules as well as some explosion effects and decals in UT.
ROLE_DumbProxy: The actor is replicated, but most (if not all) of its logic stays on the server. Theoretically the actor may execute simulated functions and simulated state code, but this is rarely used. Usually clientside behavior is purely a result of replicating variables.
ROLE_SimulatedProxy: The actor is replicated and may execute simulated functions and simulated state code on the remote side. Often this kind of actor simulates its behavior based on initially replicated properties without (much) further “help” from the server.
ROLE_AutonomousProxy: (e.g. the redeemer): The client has autonomous control over the actor replicated to it. The actor is not restricted to simulated functions and can execute non-simulated functions and state code as well. For other clients these actors appear as regular simulated proxies.
ROLE_Authority: All functions can be executed. This must appear in Role on the machine the actor was spawned on, and must appear in either Role or RemoteRole (but not both) for every actor. In standalone games all Actors have Role == ROLE_Authority. In net play nearly all Actors have this Role on the server.

A concept in UnrealScript that allows actors to execute different code in different circumstances. For example, a Bot can be ‘Fleeing’, ‘Attacking’, etc. In UnrealScript, each actor in the world is always in one and only one state. Pawns have several states such as “Dying”, “Attacking”, and “Wandering”. In UnrealScript, you can write functions and code which exist in a particular state. These functions are only called when the actor is in that state. States provide a simple way to write state-specific functions, so that you can handle the same function in different ways, depending on what the actor is doing. The InitialState property of an Actor sets the state the actor will be in when the game begins. link

State modifiers
auto: The state should be the initial state of the object. This can be overridden by the InitialState variable in Actors.
simulated: State code can be simulated like functions. See Simulated Function.

This type of file is used to tell the compiler what flags to set to the current package.