Mindustry Logic Jam and Mindcode issues

[cardillan]

Skye organizes a logic jam - details can be found on the Mindustry Discrod server (https://discord.gg/YkMMPMYABE). The goal is to start with a single poly and zero resources, and produce a mega. If you're also taking part in the jam using Mindcode, we can discuss the experience here.

I'm taking part in this (using Mindcode, of course), which means I'm a bit busy now. This is also an opportunity for me to use Mindcode on a larger project, which is extremely useful (and sometimes actually pretty frustrating), as I'm running into issues which did not occur in simpler code fragments I'm using when developing Mindcode itself. As a result, I've run into several issues. This also gives me ideas about what Mindcode needs. I hope I'll be able to share this experience and use it for further advancement of Mindcode.

I've quickly patched some of the issues I've found. Since it would be unfair to others taking part in the jam (it appears there are some other Mindcode users there too), I'll publish these as a 3.8.0 pre-release, hopefully today (the code is not ready for a full release yet). It will be available as a command-line compiler, although I might be able to run it as a separate web app too.

[cardillan]

To recapitulate my experience with the jam: my jam project was the largest I've ever written in Mindcode, and it was a great experience. I've actually gained more trust in the compiler in the process: most of the time I've suspected the compiler was buggy, it turned out as a problem with my Mindcode. The actual problems I've encountered appeared early on and were mostly fixed in the 3.8.0 beta 1 release.

The remote calls/remote variables support got a good test run. Splitting a large code base between more processors is relatively easy and natural, although some limitations on how remote modules may be used and organized need to be lifted.

I'll continue to expand my jam project and use it as a flagship Mindcode project.

The ideas and suggestions resulting from the jam are here.

Mindustry ideas

I'll try to suggest these officially, or create PRs for them.

• Copy variable value to clipboard in LVar screen.
  • This has been largely resolved by adding a button to copy all variables to the clipboard by the Mlog Assertions mod.
• It is problematic to mine an exact amount of ore. Having to drop the exceeding amount to air slows the logic down. Possible solutions:
  • drop to air without cooldown,
  • mine until the unit holds a specific amount of ore (when 0 is specified, use indefinite mining as it is today; 0 would become the default for old code).
• Deconstruct blocks. Without it a more complex logic for gradually improving a base is not possible.
• Locate extensions:
  • Ability to locate any building (if locating any enemy building is undesirable for any reason, may be limited to friendly buildings only)
  • Ability to locate liquids on the map
  • Ability to locate thermal spots
• Sensor extensions
  • Ability to sense the amount of material needed to build a block/construct a unit (e.g., sensor amount @graphite-press @coal, or sensor amount @mono @silicon)
  • Ability to sense build progress (needed to be able to detect the build has stopped, perhaps due to insufficient materials) - there's a PR for that already.
• Add an argument to draw print to not flush the print buffer. Could be used to output the same text to the display and message, or to draw the same text twice on the display to get a "bold" font. Appearance in UI: keep buffer: true/false (a variable, not a keyword!).

Mindcode ideas

• Compile-time evaluated function encode(). Takes a number of numeric arguments. The first argument is an offset (say, 35, or 128). All other arguments get evaluated, added to the offset, and converted to a UTF-16 character (resulting values will be validated to be in a range of valid UTF-16 characters). Final values get concatenated to a string, which will be a compile-time constant result of the expression. Example: const CFG = encode(35, @battery.@id, @copper.@id, 5, @lead.@id, 20);
• A debug compiler option activating a debug mode. In debug mode, no variables (global or local) are removed by the optimizer and may be inspected in the Vars screen.
• A debug code block: debug /* some code */ end;. The content of the block gets only compiled in the debug mode.
• An error() function
  • Takes any number of parameters
  • Assigns the given parameters to compiler-defined variables ERROR_1, ERROR_2, ... ERROR_N (two digits if necessary) and stops the processor.
  • Specific compiler option for disabling / ignoring the error() function calls
  • When using the Mlog Assertions mod, uses a special error instruction to display up to nine values, concatenated, as the processor error state.
• Allow multiple module instantiations.
  • Allow a remote module to be called from two different processors: it's the programmer's responsibility to coordinate the calls.
• Local arrays.
  • There's no reason local arrays couldn't be declared and used inside a function. They can't be passed to the caller or otherwise escape the function, of course.
• Allow writing the code output to a file in an emulator.
  • Implemented via a function/special instruction open file, associating a file with a specific message object.
  • Everything printflushed to that message object will be written to the file.
• Project file.
  • Defines compiler targets
    • Compile Mindcode
    • Compile and run Mindcode (since this may produce another file, this supports automatically generated sources)
    • Compile Schemacode
    • (Unit tests)
  • Compiler directives, applied to all subsequent targets
• Incremental build. When building a schematic, the compiled code is written to a corresponding .mlog file. When the file is not older than the source file or any of its dependencies, the compiled code is read from the .mlog file and not recompiled.
• Schematic
  • Define an output file name in a schematic definition file.
  • Use symbolic names for processors in schema definition file and Mindustry source files. Let Mindcode/Schemacode resolve the symbolic name to an automatically generated processor file. Requires deeper Schemacode-Mindcode integration.

Small fixes/improvements

• Remove unused warning for remote variables.
• Improve sort-variables sorting of compiler-defined variables.
• Allow accessing remote functions/variables as methods/properties even on linked processors.

Larger tasks to be prioritized

• Namespaces.
• Unit tests
  • per module,
  • on schemes with remote processors (will need schematic emulation, or special non-remote compilation).
• Data types