Ok, Ivan the programmer is back and you can find his comments to your wonderful feedback below!
Have you looked in to making a bundle, like a "flatpak" (I think it is called?) that contains all the needed library versions? Most of the libs are likely (L)GPL licensed, so there should be no licensing issues. It would avoid other issues, such as my plans to upgrade to Debian 11 in the next 6 months or less.
Now this is not a high priority issue, I didn't dive deep into this question.
But I guess it can be done after release (would be an interesting challenge for me).
BTW, maybe it will be more efficient to do some work about compatibility with Valve Proton... We'll see once we have time to look into this thing.
The tutorial needs some work to make some things more clear/obvious. It is not always clear what to do next. Even with the highlighting, it is always easy to notice that something has been highlighted -- perhaps you could make it flash and make a red arrow point to it the first time it is highlighted. (I.E., use movement -- visually impaired people like me more easily notice movement than color changes.)
We'll try and add some moving animation to highlighted elements in the tutorials (it won't be complicated for all objects except for Craftomates; maybe will make some specific animation for them)
One of the first storage bins a player will unfreeze contains some kind of "eat" modules. But I cannot figure out how to make use of them. Even I give one to a CraftoMate, they simply hold it in their hands without doing anything with it. The only way I have been able to obtain the "eat" command is by working to give the command center the requested resources to get (upgrade points) to spend on both the "low battery" and "eat" upgrades. This is _very_ tedious to do as until I get those upgrades, it is hard to keep the CraftoMates powered-up to keep the bonfires burning.
Which leads to this problem: When a CraftoMate is holding two items, I cannot feed it anything to recharge it! This happens when i is holding two stones to create a spark, or a spark and a coal to create a fire. The only way I can get it to drop everything is to completely delete it's current program. Then I can feed it. But then I have to reprogram it. I suggest some way to allow it to eat without needing to do this, such as a drop area on the command bar for feeding.
That Storage unit with 'eat' commands is from the previous version, I forgot to remove it. It'll be fixed soon!
Regarding problems with feeding by hand, you can press the 'reset' button and make a Craftomate drop whatever they're holding, without having to delete the entire program (you'll find it between start/pause and copy buttons).
But I agree that we need to have more precise control. I guess in one of next versions 'reset' button will be changed into three (maybe more) buttons (i.e. 'drop from left/right hand' and 'switch to first step'), with a dedicated manual for using them.
The code editor... well, it sucks. It is hard to work with. I end up with lines going everywhere making the display cluttered and hard to read/follow. You might add some kind of option to "snap to grid" and/or choose direct connections instead of the curvy ones. I also suggest adding "labels" and a "go to" instruction (or a "jump", for those "anti-goto" people out here), which would only show connections if hovering over them. Looping instructions would also be helpful.
Hmm, a 'go to' instruction, which would only show connections when hovering over them is a great idea, we were discussing how we can fix this problem of too many lines just a few days ago. What you're suggesting might be a great solution, so thanks for that!
As for the grid or different lines style... That's not on our table right now, as we're rather early in development, but we'll consider something like that in the future.
Subroutines would also be helpful. More so with the "low_battery" event -- which could also use a "resume" instruction to resume where it left off, instead of needing to drop everything and jump back to the start.
Subroutines are currently in the works, we're planning to really get to them at some point during the summer
'Resume' instruction should be useful, but I can't figure out how it would work and look.
I.e. In C or C++ when you resume coroutine, or return from function, execution context is switched, and thanks to this (context saving and context switching) we are able to continue execution from the same step as we stop. But this concept is too cumbersome, for our game, at least… So at this stage I don't have a solution for this. Maybe it becomes more clear once we're finished with subroutines.
You might also consider export (save) and import (load) programs, which could then be edited by any text editor. (Format could be very simple, such as DOS batch (*.BAT) files, or TCL scripts ( http://www.tcl.tk ) -- which could embed a TCL interpreter.)
Yep, this is already planned, but not for the near future.
On occasion, I encounter glitches which cause items to appear on screen that cannot be interacted with (or removed from screen!).
Will be fixed:)
Logical constructs, such as "if/else", or finding, for example, which bonfire has the lowest level of fire.
'If/else' is also to be introduced soon. I'd really like the players to make a finding instrument by combining commands and experimenting, rather than having a built-in function for that :)
P.S. That copy bug will be fixed, too, thx for reporting!