> For the complete documentation index, see [llms.txt](https://unfinishedstudios1.gitbook.io/fp-motion/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://unfinishedstudios1.gitbook.io/fp-motion/components/events.md).

# Events

> In programming, an **event** is an action that occurs because of the user or another source, such as a [mouse](https://www.computerhope.com/jargon/m/mouse.htm) click. An **event handler** is a [routine](https://www.computerhope.com/jargon/r/routine.htm) that deals with the event, allowing you to write code that executes when the event occurs.

## Description

Events are **actions** that occur based on the player’s input and the state of other events in the game.

They make it easy to **have things happen** at the exact time the player has pressed a button, with the ease of not having to check for a button press, and the conditions associated with it everywhere.

### **Types of events**

In *FP Motion*, there are three types of events, and we use each type for different things; What they all have in common is that they **react to input** and then pass that to other components as requested.

\- **Action.** We use actions for things that have a ‘state’, meaning things that **can be on or off**. For example, the player can aim, or not, making aiming an action. 

\- **Attempt.** Attempts are good for things that don’t have states, a good example would be attempting to open a door, **no states**, but you can succeed or fail.

 \- **Value.** Values are an event that you can use to **store values**.

We then use these three types of events as variables for the different things that the player can perform, and store them inside of the [Player Events](https://app.gitbook.com/s/-M5WGkCkHh2eq9-w2R1V/components/%3E) component, which also holds the logic for when to use them.

### **Persistent Events**

By default, destroyed game-objects don’t receive events. The reason behind that is that it would cause a lot of errors with the [Unity ](https://unity.com/)engine.

Inactive objects don’t receive events either, as usually there is no need for them to do so; However, sometimes they need to receive them, that is what **persistent events** are for.

Persistent events **allow** inactive objects to have their methods stay subscribed and to keep reacting to event changes; You can make any event type persistent by using the persistent variation.

Variations are: *PersistentAction*, *PersistentAttempt* and *PersistentValue*.

## Usage

The best way to use events is to **subscribe** methods to their changes, be that when they start, stop, or toggle.

If there is a need to know the state of an event while in an Update method, a developer can check for the ‘State’ property; keep in mind that this property is only available for *Actions*.

### **Differences in usage**

The usage for *Actions*, *Attempts* and *Values* is similar but not entirely the same; To use the different types of events:

```csharp
var events = PlayerEvents.Instance;

//Actions have a start and a stop.
events.Aim.SubscribeToStart(() => { Debug.Log(“Aim Start!!”); });
events.Aim.SubscribeToStop(() => { Debug.Log(“Aim Stop!!”); });

//Attempts call their subscribers when succeeding.
events.Shoot.Subscribe(() => { Debug.Log(“Tried Shooting!”); });

//Values can be got, set, and subscribed to their changes.
bool state = events.GroundState.Get();
events.GroundState.Set(false);
events.GroundState.SubscribeToChange(OnGrounding_Change);

//Method with the old and new state for the grounding.
private void  OnGrounding_Change(object old, object  nw){
    Debug.Log(“New grounding is “ + nw);
}
```