Automapper and the Command Line ( Tiled CLI )

Questions
1

I spent some time looking into this, but I wanted to know if there was a way to use Tiled’s Auto-mapping feature via the command line. The idea is that one might be able to patch process many files, or include tiled as part of a work pipeline.

I did see the following
Options:
-h --help : Display this help
-v --version : Display the version
–quit : Only check validity of arguments
–disable-opengl : Disable hardware accelerated rendering
–export-map : Export the specified tmx file to target
–export-formats : Print a list of supported export formats

So I see you have some export functionality, which is nice. If this is unavailable, or not possible, that’s ok, I am even willing to look at the code and try to add this, if you think there’s a good way to approach it.

I did see there’s a way to run shell commands in Tiled here:
http://doc.mapeditor.org/en/stable/manual/using-commands/

maybe this is the direction to go?

Thank you so much for Tiled, its an incredible tool.

2

That would indeed be really useful, but unfortunately at the moment the Automapping functionality is only available from the UI.

You’re welcome to look into adding this functionality! I think it would not even be that complicated. It depends how many options you’d like to add like whether it should save back to the same file or write to a different one, and whether you can specify a specific rules.txt file or rely on the autodetected location, etc.

I guess I would start by having it write back to the same file and use the standard rules.txt file location, then you could implement it as an option like “tiled --automap map.tmx”. If desired we can add other options later.

That just allows you to run shell commands, but you first need a shell command that you can run. Once the above command-line option is implemented, then it could of course be triggered using a custom command if desired.

Thanks! And thank you for your offer to help improve it! I can try to help if you run into any problems and of course I will review your changes.

3

Thank you for your thoughtful reply. I’l like to take a look and see what it might take. Since I am very new to the source code, just to get a good starting velocity, let me talk through what it might look like, and maybe you could share thoughts of your own.

So I agree, the first thing is to not add too many switches, lets assume you simply do the equivalent of having opened a file and hitting ‘A’. and save the map to an output file. This means you’d have already authored all the rules and you’re operating on the whole map region.

So to handle the command line side of things:

Ok so first I guess you’d register a new command in the ComandLineHandler, here:

I did notice there seems to be a few more commands here than I saw in the initial help menu.

then you’d add one of the handlers, in this sort of format:

maybe like …?

void CommandLineHandler::setRunAutomapper()
{
    runAutomapper = true;
}

then it seems you do ‘the work’ in the lines around 349 - 452

so something like

if(runAutomapper) {

//pseudocode here

/// I figure this might be mostly similar to the export-map, but in the middle you'd also
// do the additional action of Running the Automapper inside there.

// 1.check filesToOpen length
 
// 2. load plugins ?

// 3. load the source file, like `QScopedPointer<Map> map(readMap(sourceFile, nullptr));`

// 4. Run the automapper, on that file
 
// 5. write the out file (which is either over the old file or a new file if you specify a --output-file="whatever")

// 6. provide CLI feedback to the user if you succeeded, how many rules ran..if something broke
}

Ok this is what I see on the Automapper side:

I’m still not 100% clear how to actually 'run the Automapper. I do see there is the automapper itself here:

and its Wrapper here:

and the automapping Manager:

It looks like the Manager is an interface for the the Wrapper and also reads the main rules file. You interact with that (The manager). The wrapper then is what handles undo/redo stuff, and runs the actual Automapper per file (is this right ?)

Like, I see you actually load the rules in here

And you call the automap function for the manager here:

So I am guessing the CLI would clue in the AutomappingManager who then calls the Wrapper to run the whole set of rules.

The thing Is i’m not 100% sure how you actually do that part. do you import the automapperwrapper.h into the main.cpp, and then do something there? I’m not super great at .cpp so this might just be a language hurdle for me.

I’ve been doing my best to read the source code, which seems well commented. If I am way off here, let me know, I sincerely appreciate you replying.

4

You’re doing very well! And I have to apologize, since the command-line handling in main.cpp is still rather messy. In particular, there is no good support for handling arguments to command-line options. This is why the “filesToOpen” is mis-used for this by the export options.

Regarding applying the automapping, of course you do not have to worry about undo, so it could well be that you do not need to use the wrapper. However, the most straight-forward option would be to just use the AutomappingManager, something like this:

MapDocument mapDocument(map);
AutomappingManager automappingManager;
automappingManager.setMapDocument(&mapDocument);
automappingManager.autoMap();

And indeed you’d just include the relevant header files in the main.cpp to be able to use those classes (in case the above works, only automappingmanager.h needs to be included).

5

I just wanted you to know I saw this reply, and I’ll try to implement this when I can. I won’t be free to attempt it until at least late next week.

I think with your advice I feel emboldened to try now.

I will talk to you here, or via a github pull request (I will reference here) if I need more guidance.

Again, thank you.

1 Like