Priority for "other app" data file support?

[IBBoard]

I've just become aware of comments that we're slow/not putting the effort in/making things difficult with regards to "the other app" and its data files. Until now then I've been focusing on getting a base set of functionality available (creating armies, adding points, saving and exporting armies, but no validation or complexity - just an electronic version of doing on paper). As such then it didn't seem to make sense to focus on other data file formats.

Now that we're at v0.1 and starting towards v0.2 then we have the bare minimum. We can start bringing in other data files if we want. We've got bits of information that we should be able to work from, and extracting data from XML shouldn't be too difficult (although the mess of assorted files that they have may be more difficult to fully comprehend).

The question is, what is the priority of the gamers? Would you rather we tried to import .ab files from "the other app" or would you rather I focused on v0.2 with validation rules etc?

One thing I did think was that, due to our architecture, we should be able to use Tsudico's app as a converter - i.e. load in the .ab file and save it out as a .race file. It'd be a nifty feature and it wouldn't require any extra work on Tsudicos part (other than allowing it to open any file and handling the errors if people load a .doc) but because we'd load it into our internal Race object then it could be edited as one and save as our own file format.

[snowblizz]

Since I started to write native datafiles my "need" for other app support is a sinking priority.

The issue I see is that unless we know how to handle stuff natively, we can't really handle anything external?
Eg if we don't have contained units, how can we take them from the other apps datafile.

[IBBoard]

I guess it is a user base thing. You're doing a good job with the native data files, but people are relying on what you have the time for, and anything from other game systems needs someone else to manage it. Supporting other data file formats (which I already do about 90% of for the really old Rollcall files, I think) grabs us lots of data, which increases the potential user base because they don't have to wait or write it themselves.

The plan wouldn't be to do complete support straight off. I'd expect to add support for something in native files and the API, then get other data loaders to support it, then add a few more features to the API, then update non-native loading again. That'd mean we'd support v0.1-style minimal data loading with a first release, but it'd be better than nothing.

The good news is that even if I focus on v0.2, someone else can work on support for other data file formats. We don't have a proper plugin architecture yet, but we do have a way of adding loader factories within the API (so you can do it in code, but not as plugins that can be dynamically added and removed). That means if someone writes the support then we just need to add the project as a dependency to the main app and specifically add the loader, the same as in the GTK version.