Most important features for v0.2?

[IBBoard]

What do people think the most important features are for v0.2? I know I've got to get v0.1 out the door first, but it'd be good to know where we're going, and we had a similar thread for 0.1.

The Dev site has a v0.2 list and a all future versions list, so please shout if you think any priorities are wrong, or add tickets and discussion threads if you think there is anything that should be in v0.2 that isn't even identified yet.

[Frostlee]

i looked at both v0.2 and the full list, but i didn't find any ticket about better, custom or new file format export. i think it's something warfoundry should have, maybe not in version 0.2.

[IBBoard]

If there are any other file formats you think we should do (perhaps PDF or something - I'm sure there are libraries for it) then feel free to add the tickets. Once we get plugin support then it should be possible to make it extensible so that anyone can add new output formats, but a) users probably aren't as interested in plugin support as other features and b) that needs people who are interested in writing plugins

[Frostlee]

well, i suppose that, after you have build a roster, you want to print it so a nice printable output (whatever html or pdf) is something you really need.
and if plugins could be written in others language (maybe java? ) i could try to get this one. while you will hit 0.1, i'll gather some ideas about it and then i'll post them.

[IBBoard]

MonoDevelop supports Java through IKVM.Net, but I've not looked into how that works (if at all) in terms of combined apps. You'd certainly be able to write in C#/VB.Net/F#/lots of other languages. AFAIK then once it is compiled then all of the languages are interchangeable, you just can't have them all in the same project.

I use Java for my day work and C# for my evening hobbies, though, and they're not all that different. C# from a Java Developer's Perspective is a good little guide on the differences. It doesn't cover the really new stuff like Lambda Functions and LINQ, but we're currently targetting .Net 2.0, so they're not available anyway.

[snowblizz]

Oddly enough I never seemed to have replied here. I'd push for the requirements handling and the contained units so I can get things handled in lists.

Of course, don't know how much "space" for stuff there is. Looking at bunch of the 0.2 tickets and it covers most of it. If only I'd remember all the stuff that's been bothering me. We need some kind of system to log requests or something. Any ideas on that?

[IBBoard]

I'm sure I can whip up something that lets people logs requests for what they want, or records things that aren't working. I might call it a "bug tracking system" or something

We might need to shift some things out of v0.3, hence the "priorities". Getting v0.2 out quicker than v0.1 would be good, but I also want to make sure that it is useful.

[Sinner6]

My opinion would be to put some sort of versioning into the internal data format.
That would allow a person to work on plugins and file formats with incomplete data or in smaller bite size chunks.

Also I a big fan of plugins.

P.S. The papercut tag doesn't seem to work anymore.

[IBBoard]

Versioning into the data or the data format? I'm trying to keep the data format (i.e. the schemas) flexible. We could put a comment in to version the individual files, but I specifically don't want to have "http://warfoundry.co.uk/schema-name/0.1" and "http://warfoundry.co.uk/schema-name/0.2". I'd much rather have ""http://warfoundry.co.uk/schema-name" and make the schemas backwards/forwards compatible as much as possible until we really need to change.

I'm not sure how that would affect people writing plugins, though. The schemas we have are just one possible version of the data. Plugins that load data will generally be doing so for their own file format (Army Builder, Rollcall, or some custom binary format that is smaller than XML but needs an editor). Plugins that work with units and armies should be using the API and shouldn't be accessing the data files directly anyway.

I'll investigate the tags. It might have got lost in the migration to Trac 0.12.

[IBBoard]

Okay, time to give this thread a kick again.

Features in the v0.2 ticket list are:

• Unit requirements (so we can say "requires 2 of X to take 1 of Y")
• Rules sets (ways of modifying unit requirements, e.g. amounts per category)
• Unit Tags (for searching)
• Optional abilities
• Grouped equipment (in data and in the UI, as per one of Frostlee's UI suggestions)
• Extensible races
• Unit experience
• Equipment with stats lines
• Default points values per games system (Snowblizz is already working on this)
• Formations
• Custom equipment

On top of that then we've had the following suggested:

• New export formats
• Better handling of mixed units
• Better handling of contained units
• Version info in data so you can tell which version of a file you've loaded (not sure whether to do this per-XML file or per zip - latter would seem better as it doesn't confuse game data with WarFoundry data)

Based on that then I'd suggest the following priorities:

• Unit requirements (so we can say "requires 2 of X to take 1 of Y")
• Better handling of contained units
• Better handling of mixed units
• Grouped equipment
• Equipment with stats lines
• Default points values per games system

And the following as "things we'll include if someone gets a chance":

• New export formats
• Version info in data so you can tell which version of a file you've loaded

Things like rule sets and formations depend on getting requirements and containership working properly. Unit experience and custom equipment (e.g. Dwarf runes made into one composite item) are niche items that most people won't need/use, as are optional abilities. Unit tags and extensible races (i.e. a Blood Angels race that takes Space Marines as a base and adds/removes as necessary, rather than duplicating) are both nice to have, but not really necessary at this point in time.

Do people agree, disagree, have opinions?

[Tsudico]

I have a comment regarding the version information. If all the racex and systemx zipped files have ReadMe.txt in them, why can't the version information be pulled from there? Either display the readme as it stands, or allow for special tags like:

@authors snowblizz
@version 0.4

Beyond that I think the priorities for 0.2 look like a good set. I'm most concerned with requirements and contained units myself.

[IBBoard]

I think a separate file (versioning the Zip rather than the individual data) is the best way. That way then we can keep the game data separate from the data file data, and you can version a set of files in one zip (once we add support for that!)

It'll probably be a v0.3 feature, though. For now then we can make a ReadMe.txt and just have it there for manual viewing.

[IBBoard]

Thread kicking time again. I'm tidying up the tickets now and allocating them to the 0.2 milestone or 1.0. We'll decide what is pulled out of 1.0 and into 0.3 when we get to it. I've done a little bit of pruning as well, as I think we had too many feature requests in that were a couple of dependencies deep (i.e. a feature request that depended on a feature request that depended on a feature request, all of which were tagged for v0.2 and didn't seem that small).

The question is, do people agree and want a smaller set of tickets/requirements for v0.2 and a quicker release, or a larger set and more functionality when it is released?

[snowblizz]

I'm not sure if I have an opinion. Since I moved to the "bleeding edge of testing" I'm not so reliant on releases. Which tend to be after me anyway in functionality

I guess the question is would it mean nothing between releases, or would we see betas?
As such I support whichever version gives us updates more often. Since "regulars" need 'em to be able to use all the whacky new stuff I tend to put into the datafiles. Well, that I will put in once I get going with it. This development has sorta sidetracked me.

And I can get back to "fixing" older datafiles faster as well.

[IBBoard]

There would still be betas, and I might consider alpha versions as well, but they wouldn't be until later in the process. People could run "bleeding edge" as you do, but I don't suppose many people bother