WIP Command-line reform

[CelticMinstrel]

This makes use of the Clara command-line library included with Catch to do proper parsing of command-line arguments.

This fixes an issue where the scenario editor complains about a missing file when launched from Xcode, because Xcode passes an unrecognized argument which is interpreted as a filename. The Clara parser seems to ignore unrecognized arguments, so using it makes this work. It does unfortunately require using flag syntax instead of subcommand style for the replay system.

If this looks mostly okay, it might be better to update to the Lyra library instead, which is similar in substance but is still being maintained. Unlike Clara, Lyra has support for subcommands, so we wouldn't need to change the existing command-line syntax. I don't know if it ignores unrecognized arguments like Lyra does.

Alternatively, we could consider using Boost.ProgramOptions for command-line parser. This is a much bulkier library, however.

[CelticMinstrel]

@NQNStudios Thoughts?

[NQNStudios]

My command-line arg code is kind of a mess. It can definitely be improved with a good library on the back-end. If Clara is a part of Catch, that seems like a great option.

Flags are probably better than subcommands, because when you mis-type a subcommand currently, boe tries to open it as a file, which is never correct. Starting the subcommands with a - might help disambiguate that problem

[NQNStudios]

Be careful for how the apple events snatch up command-line arguments which will then also be processed by our own arg processing. That tripped me up at least once

[CelticMinstrel]

If Clara is a part of Catch, that seems like a great option.

It is part of Catch, but it is archived and no longer maintained. I would assume Catch v3 is no longer using it, but as we require C++11 support we can't upgrade past v2 anyway. Clara is also not very flexible, but it might be "good enough" for our needs.

Be careful for how the apple events snatch up command-line arguments which will then also be processed by our own arg processing. That tripped me up at least once

…what?

[NQNStudios]

I mentioned the apple events weirdness here:

• On Mac, when passing command-line arguments, the apple events function is still called, and it tries to load "replay" and "replayFile.xml" both as exg files, throwing an error message. I fixed that

and addressed it with this change:

0511172

For some reason the apple event that's set up to handle when a file gets dragged onto the app icon, also handles direct command line argument. So when I launched with "replay file.xml" it was trying to load a party called "replay"

[CelticMinstrel]

You're saying that MacOS sends an open file event to the application when it finds a command line argument? That doesn't even make sense… I don't get it…

[NQNStudios]

It seemed pretty outrageous to me too, but I just patched around it and moved on. 😢

[CelticMinstrel]

Okay, so I've rebased this to squash all the random fixup commits, but I'd still like to figure out how to make the replay speed thing work before I merge this. Any ideas, @NQNStudios ?

[NQNStudios]

I checked this branch out, built, and made a quick recording. Parts of the replay are visually messed up, like when the splash screen ends I see the startup button that gets clicked drawn on top of it, but the menu doesn't get a chance to draw itself in full first. (That's been the case all along--I didn't really mind it myself). But when my party gets into a scenario and I'm replaying with --replay-speed 1, it does indeed seem like they move around at a rate of 1 turn per second as expected.

So I'm thinking that what you've done does work, but certain things the replay system replays, happen outside of replay_next_action() in handle_events(). For example, dialog.cpp is handling replay actions within its event loop, and that has its own framerate limiter that doesn't pick up the CLI arg.

If we do change animations to not have their own event loops, then this way of specifying replay FPS is gonna mess those up and make them last forever.

[CelticMinstrel]

then this way of specifying replay FPS is gonna mess those up and make them last forever.

Do you have a better way of specifying replay FPS?

[NQNStudios]

Still thinking about this. The cleanest way I've come up with so far, would be to put an fps_limiter in replay.cpp and have pop_next_action() end its frame before returning. While this would seem to be an unexpected side-effect for a function called pop_next_action(), it would ensure that every event loop that replays anything, stops first to let the user see what happened in the last frame. While still leaving the main FPS system alone.

[CelticMinstrel]

Okay, I'll try that.

[NQNStudios]

The start menu still probably won't draw with this, because the issue there I'm guessing is that the splash screen ends in the same frame the button action gets picked up, so sleeping in pop_next_action() would just draw the splash screen longer.