Help
Requirements (as early as 2.90b):
- Robot programs must be immutable. I believe this is the case at the moment, but I may be incorrect. Zapped and restored labels must operate entirely off of the label zapped flag and not change the program itself in any way.
- Zapped status must be split from the label cache. They will use the same indexing, but exist in separate places in memory.
- A struct for programs separate from robots must exist. This will store bytecode, source code, the label cache, and a default zapped status array. Robots will contain their own duplicate zapped status array created from the original.
- All program loading/modification functions need to be relocated from robot.c, legacy_robot.c, counter.c, and robo_ed.c to a new file program.c.
Changes to the world format (as early as 2.91):
- Programs will be stored in two files for each program: pXXXX for name, bytecode, the label cache, and the default zapped status, and pXXXXs for source code.
- Programs must be loaded before any robot is loaded. This may require file IDs being reassigned, i.e. 100x programs, 2000 global robot, 400x boards, 8000 robots, 9000 scrolls, A000 sensors. Since these are purely internal now, it doesn't really matter.
- Robots will no longer contain bytecode or source code. They will, however, each contain a zapped status array for their labels. They will also contain a program number field.
- The world will require new fields for the number of programs present and a one-to-one programs-to-robots toggle. This will default to 1 for all imported worlds and during non-editor play, and to 0 for new worlds.
Changes to runtime and editor (2.95):
- Export downver and the downver util: expand shared programs into one-to-one mode.
- Merge duplicate programs during gameplay (but not testing). This includes any robots imported from MZMs and external files. The specifics of detecting program duplicates TBA.
- Clean up unused programs during gameplay and testing. This will happen only to unnamed programs loaded ONLY during runtime (from MZMs, external files, or strings) when no robots are currently using them. Any unique programs generated through these methods at runtime are considered unnamed and will be inaccessible from the PROGRAM command. Cleanup checks will probably need to happen at the end of any cycle during which a robot using an unnamed program changes its program.
- Internally track the number of robots assigned to each program in the editor and during runtime.
- UI: a list interface to modify, add, duplicate, and delete programs. The list will stay name sorted within the editor.
- UI: a control to optimize out unused programs.
- UI: a control to merge all duplicate programs.
- UI: ability to select between one-to-one mode and shared mode. Switching to shared mode from one-to-one mode does nothing; switching from shared mode to one-to-one mode will duplicate every shared program.
- UI: robot editing: in shared mode, the user must select a program from a list or add a new program for the robot to use. In one-to-one mode, a new program will be created automatically (i.e. MegaZeux will behave the same as in older versions).
- Naming: duplicated programs will share the original program's name, but with some unique identifier afterward.
- Naming: imported programs will share the original robot's name, plus board and/or robot number info.
- PROGRAM "NAME" command. Changes the robot's program to the given program, which it will then begin to execute from the beginning. This will not alter any other attribute of the robot, unlike COPYROBOT, and addresses a program name, not a robot name. This is the only part of this that might have to wait for debytecode, when adding new commands will become much easier.