Is this TUI, GUI, or source coding with some [other] output?
You're saying it has its own programming language ("Hive-"). Does it onboard you, or how do you learn or use it as someone unfamiliar with it?
Is this TUI, GUI, or source coding with some [other] output?
You're saying it has its own programming language ("Hive-"). Does it onboard you, or how do you learn or use it as someone unfamiliar with it?
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.
This sounds super cool. Crossposted to !automationgames@lemmy.zip to get it in front of more people
Hi Saithe, I've cloned your repo and am trying interact with it but I'm not getting any sort of feedback from it.
Maybe I'm wildly misunderstanding how this works.
I've added args from hivemm-design.txt such as "m0" or "q1" or "x", both passing them directly on line 5 of dbglua and by passing them as args when calling dbglua. In all cases, dbglua returns 'ok' and no changes occur to the game state.
Attempting to pass any arguments by any method using the "--release" flag when running and using clientlua instead of dbglua results in the app panicking in lexer_system.
I'm not the greatest with rust or I'd try to debug myself. I can read it, I can't write it though.
If you'd like I can gather some logs and submit them on your issue tracker @ git.gay
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.
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 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
You're totally right my code was malformed. I looked closer at hivemm-design and realized you had syntax examples toward the bottom. I'm still not quite getting feedback from the game, but it does acknowledge transmissions and doesn't crash now.
Thank you.
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
Welcome to the game development community! This is a place to talk about and post anything related to the field of game development.