Open AsherGlick opened 2 years ago
The API for this interface should be pretty similar to what is possible over a theoretical CLI interface.
We want to have these four functions
read_taco(file)
write_taco(file, root_category)
read_waypoint_file(file)
write_waypoint_file(file, root category, mapid)
So if we were to make a single interface that could be called via ipc or the cli it could look like this:
struct TacoOutput{
string file; // A .zip, .taco file or a folder
? root_category; // Some variable denoting the category
}
struct WaypointOutput {
string file; // A ?.waypoint? or a folder
? root_category: // Some variable denoting the category
int32 mapid_filter; // A way to filter out data not in a map
}
void run(
vector<string> xml_inputs
vector<TacoOutput> xml_outputs,
vector<string> waypoint_inputs
vector<WaypointOutput> waypoint_outputs
) {
for (xml_input in xml_inputs) {
read_taco(xml_input);
}
for (waypoint_input in waypoint_inputs) {
load_waypoint(waypoint_input);
}
for (xml_output in xml_outputs) {
write_taco(xml_output.file, xml_output.root_category);
}
for (waypoint_output in waypoint_outputs) {
write_waypoint(waypoint_output.file, waypoint_output.root_category, waypoint_output.mapid_filter);
}
}
The type of the marker category identifier will be determined after the protobuf schema as it exists today is finalized, because it is changing how marker categories are stored.
Eventually the XML parser needs to have hooks that are callable from inside gdscript. The best way for this to happen is to migrate the C++ Standalone XML parser to instead be compiled as a gdnative library.