The versatility of KLEP allows me to drive the character using keyboard keys as keys, or drive the enemy AI with keys released from sensor executables, or drive the narrator with keys accumulated by the users actions, so on. KLEP rules bro. Keys carry information, locks validate from that information which allow executables to fire. The image of code below shows that keys also use a dynamic property system that lets you load them up with whatever you want, a hash of vectors, a list of transforms, coroutines, ints, bools, so on. All of these can be used to transfer info from neuron to neuron or act as conditions to unlock locks. https://files.catbox.moe/jy8ji1.png The above gif example is a sensor that release WKEY/AKEY/SKEY/DKEY upon keyboard interaction, this unlocks a lock looking for those keys, which then allows the movement exe to fire, which then looks at what key is in the system and applies movement based on that. So its checks never get hit until conditions arise for at least one of its checks to do something. Functionally, that exe doesnt exist until its needed. I could refine it by pushing a vec2 with the w/a/s/d keys and having it just add those vectors and apply that as movement. that would be better optimization i think.
https://files.catbox.moe/jy8ji1.png
The above gif example is a sensor that release WKEY/AKEY/SKEY/DKEY upon keyboard interaction, this unlocks a lock looking for those keys, which then allows the movement exe to fire, which then looks at what key is in the system and applies movement based on that. So its checks never get hit until conditions arise for at least one of its checks to do something. Functionally, that exe doesnt exist until its needed. I could refine it by pushing a vec2 with the w/a/s/d keys and having it just add those vectors and apply that as movement. that would be better optimization i think.