Various bugs when compiling with Unreal Engine, not sure if they exist for everyone else.

[Deleted user]

I'm integrating docopt into Unreal Engine 4 as a standalone plugin. I'm doing this for a game I'm working on that is heavily command-line based as it takes place in a fake Unix-like operating system.

For the most part, the library works fine as a UE4 plugin. I've created a public Blueprint API so I can use it in-game, and I can do basic parsing.

However there are various bugs I've found with it.

1. [options] clause does not work. Using [options] in a usage pattern, then defining my options in a below Options: section like in the python demo video results in Unexpected argument errors when using the options.

For example, passing in a usage pattern like this:

Usage: help [options]
       help [options] search <filter>

Options:
   -p <page>   Specifies which page of help to display. Default is 1.
   -s <size>   Defines the amount of elements per help page. Default is 15.

If I parse help with that doc, it works fine. help search foo fails with "Unexpected argument: search, foo", help -s 10 search foo fails as well, so does help -s 10. Same with -p 2 in either scenario. Basically if I try to use any option, it'll fail. And if I try to basically do anything with that search pattern as well, it fails.

If I replace any instance of [options] with [-s <size>] [-p <page>], no argument errors. So, my workaround for this is I build an internal and "friendly" usage string, the friendly one is displayed to the user and the internal one has [options] replaced and is passed into docopt. Works fine, fully automated.

2. Docopt doesn't properly parse integer values.

When I provide -s 10 -p 2 in the example above as my input command, after working around the above bug, docopt parses the <size> and <page> positionals as strings and not integers. Which isn't good, because it also sets the internal kind value to Kind::String, so, I have literally no way to differentiate between actual integers and values like foo, this is a string, 3.1415, etc, without a bit of Unreal C++ code or Blueprint code in the frontend which will bog things down or look messy.

3. The search command in the above example usage pattern is always parsed as false even when the user wants to search.

If I run help, search is false. Cool. But if I run help search foo, search is still false. Docopt IS registering it as a boolean internally, because I'm looking at the values before they get marshaled into Blueprint, and the value kind is boolean and the value is false.

Something that does work

My game also has a man command that allows you to see the friendly usage documentation of a specified command. man's own usage is as follows:

Usage: man <command>

Running man help results in me seeing the game's manual entry for the help command, which is perfect. That tells me that docopt is parsing string positionals just fine.

I'm wondering if these issues are specific to Unreal Engine or if other people are having these issues? I'm thinking that the integer-parsing issue may just be that integer-parsing is NYI, not sure. I did see someone say that docopt doesn't parse negative numbers correctly but that seems like a simple regex-matching bug when parsing options.

The [options] bug was an easy fix in my API, no biggie. But the other bugs are severe issues for me.

[Deleted user]

Update: Add another bug to the list. This might be a general parser bug actually, and not just a UE4 compiler issue.

Take the example usage pattern below:

Usage: help [options]

Options:
   -s <size>   Defines the amount of items per page.
   -p <page>   Specify the page of help you want to read.

Notice how -s and -p both take a required positional argument? Well, docopt's parser doesn't notice that. Because this is what it sees.

Usage: help [-s -p] <size> <page>

This is evident by the fact that doing help -p 3 results in <size> being 3 (and not <page>). This is also evident by the fact that doing help -p 3 -s 50 results in an unexpected argument error (despite that command being syntactically correct based on my usage pattern), and doing simply help -p 50 3 results in the page being 3. help 50 3 yields the same result.

I did not notice this issue until I started writing a workaround for my integer parsing bug above, and noticed that:

a. the fix worked fine, I was getting ints where I needed them.
b. it was still not setting <page> to 3 when doing help -p 3.
c. it was instead setting <size> to 3 because that was the positional that came first, regardless of the optionals.