Programming, Work

134th day

Doing a lot of programming again today. Cleaning up the .dll that will be running the machines logic and ironing out other ideas. In addition to my native plugin, there is an executable(codeexec) that wraps the programmed machines.


The codeexec is created as a separate process by the game plugin. Within it, you can execute any LUA, ASM code you like. And there can be many such running processes. The only way for codeexec to communicate with the main game is through stdout/stderr that is redirected to my plugin. The plugin will filter the stdout/stderr for any messages, and forward them back into a target codeexec process or game, if there are any such messages within it. Otherwise it will just get placed in an output or error buffer for the game to print at its pace.

A bad script will not stall any part of the game.

CodeExec are safe to crash and die in case of errors. There is no global LUA state. Each statement and file run within the game will be launched within its own process. Every worker thread of those processes will have its own LUA state as well.The worker threads are safe to create communication pathways between multiple threads using inproc zmq sockets. But there is no socket connection back into the game. If the stdout/stderr becomes too rich for the game to process, it will kill the guilty codeexec process.

This is the layout I have for the programmed machines that will be running within the game. Each machine will run on YOUR machine. No VM. All JIT compiled and native with the safety gloves off.


Such fun I am having!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s