Metadata-driven instruction parsing and validation

[cardillan]

The mimex-logic-statements.txt file will be expanded to include the argument types of each instruction. For BE, the extracted information will look like this:

opcode	argumentTypes
noop
read	var var var
write	var var var
draw	GraphicsType var var var var var var
print	var
printchar	var
format	var
drawflush	var
printflush	var
getlink	var var
control	LAccess var var var var var
radar	RadarTarget RadarTarget RadarTarget RadarSort var var var
sensor	var var var
set	var var
op	LogicOp var var var
select	var ConditionOp var var var var
wait	var
stop
lookup	ContentType var var
packcolor	var var var var var
unpackcolor	var var var var var
end
jump	int ConditionOp var var
ubind	var
ucontrol	LUnitControl var var var var var
uradar
ulocate	LLocate BlockFlag var var var var var var
getblock	TileLayer var var var
setblock	TileLayer var var var var var
spawn	var var var var var var
status	boolean var var var
weathersense	var var
weatherset	var var
spawnwave	var var var
setrule	LogicRule var var var var var
message	MessageType var var
cutscene	CutsceneAction var var var var
effect	var var var var var var
explosion	var var var var var var var var var
setrate	var
fetch	FetchType var var var var
sync	var
clientdata	var var var
getflag	var var
setflag	var var
setprop	var var var
playsound	boolean var var var var var var var
setmarker	LMarkerControl var var var var
makemarker	var var var var var
localeprint	var

(Parameter names will also be gathered, but they aren't that useful.)

var represents a regular mlog variable. int represents a special type used only with jump (index of the target instruction). All other types are enums, with boolean being a special type of enum having just true and false values. The enum names correspond to the Java clas names.

As all these enums are already included in the mimex data, there's almost enough information to allow parsing and validating most mlog instructions just from the metadata (there will be some instructions needing special handling though, like jump or sensor). The following issues remain to be resolved:

1. There isn't a simple mapping from an enum name to its corresponding mimex file.
2. Some enums define elements not used in (some) instructions.

To address the first issue, a file mapping class names to mimex files will be created:

// DO NOT EDIT! Generated by mimex - Mindustry Metadata Extractor
class;file
Block;mimex-blocks.txt
BlockFlag;mimex-block-flags.txt
ConditionOp;mimex-conditions.txt
ContentType;mimex-contents.txt
CutsceneAction;mimex-cutscene-actions.txt
FetchType;mimex-fetch-types.txt
GraphicsType;mimex-graphics-types.txt
Item;mimex-items.txt
LAccess;mimex-laccess.txt
LLocate;mimex-locate.txt
LMarkerControl;mimex-marker-control.txt
LUnitControl;mimex-unit-control.txt
Liquid;mimex-liquids.txt
LogicOp;mimex-operations.txt
LogicRule;mimex-logic-rules.txt
MessageType;mimex-message-types.txt
RadarSort;mimex-radar-sorts.txt
RadarTarget;mimex-radar-targets.txt
StatusEffect;mimex-status-effects.txt
Team;mimex-teams.txt
TileLayer;mimex-layers.txt
Unit;mimex-units.txt
UnitCommand;mimex-commands.txt
Weather;mimex-weathers.txt

To address the second issue, mimex files for enums will be expanded to include a boolean attribute for each instruction opcode that uses the enum. Enum records supported by the given opcode will contain true, the others false. The mimex-tile-layer.txt file, for example, will therefore look like this:

name	getblock	setblock
floor	true	true
ore	true	true
block	true	true
building	true	false

(The setblock attribute is currently named settable.)

[cardillan]

The following attributes have been renamed:

• mimex-block-flags.txt
  • logic --> ulocate
• mimex-contents.txt
  • lookable -> lookup
• mimex-laccess.txt
  • senseable --> sensor
  • controls --> control
  • settable --> setprop
• mimex-layers.txt
  • settable --> setblock