Warfoundry and exporting army

[Frostlee]

well, having some little spare time i've managed to download VS C# 2010, most of the WarFoundry code (thanks svn!) and i've started digging into it.
one of the stuff nobody has yet start working on i suppose it's the exporting of army.
(if i'm wrong at least nobody wrote anything aobut it in the forum)
so i've opened this topic to gather some ideas about it.

in my opinion it could be a plugin because that way it could be easyer to extend but it should be a very core plugin because it's something it's supposed that an army creator should have.
so far the ony code that do exports (the WarFoundryHtmlExport) seems to be quite separated from the rest of the API, so we could keep it there and move to a plugin when it will be possible.

for the futore i can see 3 main points:

• new file formats, well PDF should be an obviuos idea, but also a plain text ad a BBCode could be useful.
• better looks: basic html is quite ugly but a nice css could really improve it.
• custom looks: allowing some customisation even for the non-programmer guys (i mean not manual editing of the html file), and maybe allowing custom looks (choose from a set of css maybe?). this could be achieved in two ways: creating lots of different exporters plugin or allowing options to be set for the exporter. i'm not sure on whichever is better.
  
  
  

so, what do you think?

[IBBoard]

Thanks for taking a look at things - it'll be great if you can help out

VS2008 caused me problems because it wanted to convert all of my 2005 project formats. MonoDevelop, on the other hand, handles its own format and 2005 through 2010 without changing anything. We've migrated to 2008 format in the end, but it is a PITA if Microsoft screw up backward compatibility of projects as soon as you use a newer editor.

The design of the exporter was intentionally that it was possible to make plugins. The HTML exporter could be a separate project, but it seemed overkill. Ditto for the XML loading. What we might end up with is one project of "core exporters" that adds a few exporters. The only thing that really holds us back is the fact that I've not got the plugin code written yet Strangely, people seem to want features rather than the potential for plugins We could, however, do what the GTK UI does and make separate projects that are hard-coded in (e.g. Rollcall support) and then replace the hard-coding with plugability when we support it.

Looking through your list:

• New file formats - I totally agree. PDF is one of the more obvious file formats that I expected to include at some point, and there is a .Net library somewhere for creating them. Plain text may be useful in some situations (I assume you're thinking of posting to forums?). Beyond that then I'm a little short on ideas other than XML that can be styled with an XSLT (rather than our current XML output, which is focused on storing data instead of being presentable).
• Better looks - we could either update the basic HTML or make a new "customisable HTML" that imports a user's own CSS file and possibly header/footer. The basic HTML was really just a proof of concept that we can dump it out to something usable in a game. Given the range of potential games then I didn't want to put anything specific in the styling, and anything generic wouldn't be what someone wanted, so I went bare minimum. Feel free to make suggestions and new code. It might be good to try and refactor the existing exporter to extract any common functionality as well.
• Custom looks - I agree. Template packs would be nice, so someone could make a "Warhammer" one and a "Warmachine" one and a "Starship Troopers" one etc, then people install and use them. I'd probably limit the number of exporters unless they're doing obviously different things (e.g. the current tabular format vs "roster card" format). Getting something like phpBB's templating system would be great for personalisation of templates, but I think that would have to be a "much later" idea

If you need any help with anything then just shout. I'm sure Snowblizz and others can come up with some ideas on how they'd like their output formatter

[snowblizz]

I'd say for the gamer the overriding concern is a list that is clear and provides enough information without being too OTT. I know that's a sticking point with "that other one", ironically it is possible for the user to decide how much should show up on the roster, just that few exercise that option.

So I don't see the need to make it "look good" as an overriding concern. Though I know some people like to make nice looking ones.

I know we talked about custom output before, and some systems would need a specialised roster output.

[IBBoard]

True, the information is the most important part. The idea with my "basic" HTML was that it included the minimum useful information that I ever put on a list and that people would then remember or look up things like rule details or equipment strengths. If you know HTML or CSS or otherwise want to embed the HTML in your website then the basic HTML should be easy to edit and restyle as well.

[Frostlee]

well, it is already two week old, but in the while i start doing some coding.
since i whish something easy to start dealing with i've almost done a hardcode now, pluginize later, basic HTML exporter which outputs a "roster card" format.
easy to guess, i called it WarFoundryRosterHtmlExporter and its .cs file is inside API/Exporters folder of my SVN copy. it still needs some debugging, but soon(tm) should be ready. then it will need some testing before adding to the main branch.
after that maybe i'll move on trying to handle pdf or just plain text output, whatever we thinks more important.

edit: just a quick question. if i build only the API project and then substitute the dll will it work or i have to rebuild all?

[IBBoard]

Thanks for writing what will probably become part of one of our first plugins, Frostlee. Much appreciated

Even if it isn't finished then committing is a good idea (this applies to Snowblizz as well ). If it is a big/on-going change then feel free to create your own branch to commit in to. Once you're done then you can either merge the branch back into trunk or I can do it, depending on how familiar you are with Subversion.

As for builds, I've just dropped in rebuilt versions of the SharpZipLib before now and it didn't complain, so I think it should work. Doing a complete build of everything always makes sure, though