Core Concepts Keys

The Core of KLEP: Keys, Locks, and Executables

Welcome to the deep end. This is where KLEP (Key-Lock Executable Process) shows its true power. If you’re looking to understand how KLEP works under the hood, buckle up—this is the real stuff.

---

🧠 The Process: A Self-Sustaining Cycle

At its core, KLEP is all about the flow of keys, the unlocking of locks, and the firing of executables. This process creates a self-sustaining cycle:

1. Keys unlock locks.
2. Unlocked locks allow executables to fire.
3. Executables can release new keys upon completion.
4. The new keys then unlock more locks, and the cycle continues.

This cycle is what makes KLEP dynamic—the output of one action becomes the input for the next, allowing for complex, adaptive behaviors.

---

🔑 What Are Keys?

In KLEP, keys function much like neurotransmitters in the synaptic gap of a biological neuron. They are both data carriers and signaling elements.

• Transmitter Analogy: A key is the neurotransmitter. It carries information and seeks a lock (receptor) to bind to.
• Receptor Analogy: A lock is the receptor. If the key finds a matching lock, the signal is received, and the executable fires.

🛠️ What Can Keys Carry?

A key can hold almost any type of data, including:

• Primitive types: bool, int, float, string.
• Complex objects: Transform, Vector3, even other KLEP neurons.
• Custom data: Full scripts, lists of transforms, custom objects, etc.

💡 Example Use Case:

Imagine a neuron detects an enemy behind a friendly agent.

• The neuron generates a key that holds a reference to the friendly's neuron.
• This key is then pushed into the friendly's neuron, which can check for a team ID key.
• The friendly agent can then react accordingly, such as by turning around or issuing a warning key.

---

🚦 How Do Keys Work in Practice?

🔋 Patience and Persistence: How KLEP Handles Keys

When a key (transmitter) is pushed into the system, it waits for a matching lock (receptor). If no lock is present, KLEP has two possible outcomes:

---

1. Immortal Keys:

• Immortal keys are persistent by design, meaning they remain in the neuron until explicitly removed by an executable.
• Unlike a sensor that constantly generates a key or a router set to repeat, immortal keys do not re-generate or reset each frame.
• Instead, they act as stable state information, like a team ID key that an AI agent always needs to know its allegiance.
• They only disappear when an executable explicitly cleans them up, ensuring vital information isn't lost unless intentionally cleared.

---

2. Dissipating Keys:

• If a key is not persistent, it is cleaned up at the start of the next update cycle.
• This mirrors how unused neurotransmitters are reabsorbed or degraded in the synaptic gap.
• If the key's source is still producing it, it will regenerate in the next frame, ensuring the system does not break but instead waits gracefully.

---

⚖️ Key Lifecycle Example:

• A sensor generates an "Enemy_KEY" if it senses an enemy within a threshold.
• When no enemies are present, the any prior frames emitted key dissipates.
• When an enemy enters the range, a matching lock (e.g., EnemyDetectedLock) unlocks, allowing the agent's behaviors to fire.
• This could be a check on the teamID_KEY of a other mob's neuron to verify if friend of foe.
• If the enemy disappears, the agent returns to a waiting state, showing built-in patience without needing manual intervention or excessive fail state management.

---

💡 When to Use Immortal Keys:

• Persistent States: When an agent needs to remember an instruction (e.g., stay in cover until explicitly told to move).
• Configuration or Mode Keys: Such as "IsInCombatMode_KEY", which might only clear when the agent exits combat.

---

🔍 PropertyManager: Extending Key Functionality

Keys interact with the PropertyManager—a script used by KLEPKey to manage dynamic properties.

1. PropertyManager allows keys to carry complex data and dynamically add or modify properties.
2. It enables data transfer not only between executables but also across neurons, creating a network of knowledge and actions.

⚙️ Current State and Future Plans:

The PropertyManager is powerful but cumbersome. I’m exploring ways to simplify it while retaining its flexibility. If you're reading this in the future, some of the key behaviors might have changed, but the core concepts will remain.

---

🔍 Attraction Values: The Key to Decision Making

Every key in KLEP has an attraction value, which is combined with the attraction value of the lock.

• Attraction Value of Key + Attraction Value of Lock = Priority Score
• When deciding between actions, the agent evaluates these scores to determine if Option A is better than Option B.

This gives KLEP agents a simple yet effective mechanism for dynamic decision-making, allowing them to evaluate their options and choose the most attractive path forward.

---

🚀 Why This Matters:

This key-lock-executable process isn't just theoretical fluff—it's practical, automated, and scalable. By adding a key, you can trigger entire chains of behavior, letting KLEP agents navigate problem spaces with minimal manual setup.

If you're ready to go deeper, check out the PropertyManager section for a detailed breakdown of how data is managed within keys and how to maximize KLEP's flexibility.