I want to clarify that by “currently” I mean the info logs will be removed from release builds. They actually shouldn’t be there outside of debug builds and are a bug. The game is intended to be played with the only feedback being data sent over the port from your own hive-- code

Currently the only feedback will be in the form of info logs printed to stdout and sending data back over the port via the x command

Just a quick guess, make sure before any hive-- code you have 0, eg 0q2>x. This specifies the worker to run the code on. Currently, only 1 worker with id 0 is spawned at startup; the plan is to make it so you can build more workers.

Also I will have to mess with that panicking issue, but my suspicion would be that the hivemm code is malformed. In design-notes/hivemm-design there’s some examples

This is a documentation issue, AKA “I need to explain how shit works better” which is an ongoing process. Dbglua is for connecting to the debug socket for inspecting the game state directly, the code for this is in the debug.rs file. Clientlua is an example lua client that connects to the actual gameplay socket. My apologies, proper documentation is on the todo list. Glad you took interest in it tho!!!

Also Hive-- is extremely simple. It’s meant to be a abstracted over, but is very straightforward to learn. Currently the language is documented in the form of design notes under design-notes/hivemm-design.txt. It isnt meant to be user facing but does hold all the information required to use hive--

The plan is to have very extensive documentation.

The game has no ui, it runs as a background process that you talk to over IPC. You send Hive-- code to a worker and any value that code exits with is returned to you over the socket. You can only see the data your workers can gather from the surrounding environment. The debug build currently prints the position of worker 0 to the terminal for development purposes.