Breaking stats - some ideas on a re-work

[IBBoard]

That's just a labelling thing. I would try to avoid changing the XML, but I can easily call it "options" on the UI. Once we get the tabbed/grouped "equipment" UI then we could even keep the non-equipment options in their own categories.

[IBBoard]

The start of the stat line breaking is now (finally) in source control. We've got multiple "unit member types" that a unit can reference, or it can have one overridden stat line (as it has now), or it can have both (so the member types are there for future plugins that use them, but the stat line only shows the overridden one).

Now I just need to tweak it all to handle multiple stat lines.

[IBBoard]

I've been taking a break from programming (I was getting a bit worn by work and then evening coding sessions) but I'm back at it again now.

The main thing I've got to work out is how best to display the stats in both the unit displays and in the output. Everything is fine if all of the stat lines use the same format, but while that's the most common situation I've also got to take account of when it isn't. At the moment I don't know how best to handle it other than to render my own "table" with a canvas and manually drawn lines. Does anyone have any ideas on what they think would be usable for them for the UI?

[edit] I think I can work with the main UI stuff in some shape or form. The more awkward one is probably the HTML output. Normally, units with different format stat lines get put in separate tables (a bit like GW's standard 40K rosters). The problem with that comes when one unit has different format stat lines. We don't want to repeat the whole unit twice, because that'd make it look like it was taken twice. My initial idea is to put all of the stats that match the first stat line format in the main table (with some special handling of the name so that it doesn't look like a distinct unit) with the other stat lines in the appropriate table with a "-" for the price. Any better suggestions based on how people write their own rosters would be appreciated

[snowblizz]

Trying to come up with something intelligent, so in lieu of that...

looked at the "Other" one. Nothing fancy there. Main unit's name is bold. Extra statslines and attached units are listed below, name just in regular font. Vehicle stats are just one long cell with text. ie Front:10 Side:10 Rear:10 e.g.

With regards to the cost I'd like to point out that in some cases it'd be useful to have it listed. Depends a bit, but e.g. monstrous mounts and attached transports are separate for the purpose of victory points. If any system will be using them still of course... 40k dropped that and who knows if 8th edition will too.

[IBBoard]

I was working towards multiple tables on the forms, and something similar to what you suggest in the HTML output. The Windows interface was fighting back a bit and nothing was being overly clear in documentation about how I was supposed to achieve what I wanted, but that seems fairly standard in my experience.

As for the HTML, I was considering having the "Name" column as the unit name and then adding another column before the stats that was the "stat type", which would be blank if there was only one unit type. Using row spans would be another way, or tables within tables so that you're not tied to the same columns, but it all gets a bit messy. I guess it might not be avoidable, though, since the situation we're trying to handle is intrinsically messy.

[snowblizz]

I now realised you talked about the GUI as well. I'll have to check if there's any changes in the svn and if I like 'em.

[IBBoard]

The GUI in SVN is only part complete - it should work, but I've not tested it with multiple stat lines (the code should accommodate it, but I don't know what it'll actually do) and there are some tweaks I want to do to improve the layout. Still, suggestions are appreciated.

[snowblizz]

Haaa! Got it to load, and the unitmember and types stuff works. Holy cow. We are getting there.

Of course if I wasn't forgetful idiot I might have remembered that you talked about sequence being important. Took me a while to figure that one out...

Edit:
Ok first issue. I can only pick either override stats OR membertypes but not have but not take a listed statset and then ADD a membertype to show, or can I?
I guess for a cavalry unit I'll have to make membertypes for both rider and mount then?

Also, usefulness is limited somewhat in that taking a membertype it will have to have a name. Spearmen are "Spearmen" and Lothern Seaguard are "Lothern Seaguard", archers are "Achers". Same stats, different display name. Damnation.

Edit2:
Maybe I need to readjust my thinking and consider the unit as a "container". Though it reduces utility somewhat (for me at least). There IS a certain poetry in it, the armybook after all lists it as "Unit of Many Guy_S_" and then the separate profiles as "Unitmember".

The way I'm writing the files I've included e.g. the armour save on the statline, which a certain other program does. For easy reference. So the 3 units mentioned will have different AS sats. So if we do not have the ability to "calculate" stats (you have something with the armourtypesequipment I've never understood) it might not be such a big deal.

I may need to adjust.

[IBBoard]

Holy cow. We are getting there.

Of course we're getting there. Not overly quickly, but eventually.

Ok first issue. I can only pick either override stats OR membertypes but not have but not take a listed statset and then ADD a membertype to show, or can I?

That's correct. The idea was that you could do "simple" classic format files using the old format or use the member types for re-use.

I guess for a cavalry unit I'll have to make membertypes for both rider and mount then?

That was the idea, since the mount type will generally be re-usable amongst different units.

Also, usefulness is limited somewhat in that taking a membertype it will have to have a name. Spearmen are "Spearmen" and Lothern Seaguard are "Lothern Seaguard", archers are "Achers". Same stats, different display name.

My thinking there was similar to what you describe in edit 2 (and, as you say, what the codex does with things like "Tactical Squad" as the unit name and "Space Marine" for the stat line).

I might need to alter the display slightly so that the unit type remains somewhere in case you rename the unit, but the idea was to have a "High Elf" statline that is reused by Spearmen, archers, etc. The default unit name then uses the unit type name, but if you rename the unit then I guess the unit type is lost at the moment.

If you have a unit type that has almost identical models but slightly different stat lines then you can reference the unit type for future "model requirement plugin" usage and use the old <stats> block to provide the actual stats.

The way I'm writing the files I've included e.g. the armour save on the statline, which a certain other program does.

Good point, I had forgotten about armour save and how we were handling it. We need to investigate other systems for that, as I'm not sure what works best. Warhammer 40K needs "X+", Warhammer needs a calculable "X+" (because of shields and mounts, unless it changed since I last played), and other systems might use other means. I'm almost inclined to keep it separate from the stats in the data but bundle it in (as I do with the names) when you make a request in the API.

Armour type has always been about an exclusion format until now - "heavy armour" items replace "light armour" items but can be taken along with "shield" items, but "heavy armour and shield" items can't be taken with "shield" items because they already incorporate a shield.

They seemed like sensible design decisions at the time, but if there are flaws then I can re-work it. It needs to be sane and sensible and easy to use, but at the same time we do need to make sure that we don't add 50% complexity to the API and calculations for a 1% usability gain.

[snowblizz]

Armour type has always been about an exclusion format until now - "heavy armour" items replace "light armour" items but can be taken along with "shield" items, but "heavy armour and shield" items can't be taken with "shield" items because they already incorporate a shield.

They seemed like sensible design decisions at the time, but if there are flaws then I can re-work it. It needs to be sane and sensible and easy to use, but at the same time we do need to make sure that we don't add 50% complexity to the API and calculations for a 1% usability gain.

Does it work? I haven't even tried to do it. Simply because I don't know how to phrase it.

I've been doing that exclusion with magic items already actually, with exclusivity groups. Also as heavy armour replaces light armour as an option I've made them also with exclusivity groups.

Armour is still as it was in WHFB, I noticed when ripping you-know-what's datafiles that there are weird "unit with other armour" entries. There's a "captain", a "captain in artificer armour" etc. Not the most innovative idea, but there might be a reason for it. So there is some limited "upgrading" of armour in 40k as well. While on the subject the modified profile "in use" is to make say "S 4/6" for a unit with great weapons. 40k actually uses a "standard notation" for increased toughness as T 4(5) in the codices. Off the top of my head maybe we could have somekind of "regular expression" based approach. I'm thinking if e.g. one could define that this stat has a value + a suffix of "+" and then it would just save the value ion the datafile and display/output the generated stat.

[snowblizz]

Am starting to like this very much so far. It even helped with the "unit is also character mount". Reduced the number of extra units I needed already.
Of course so far we are talking about doubling the work but in the future...

Now I'm only waiting for the containedUnits with baited breath. Mush programmer, mush!

[IBBoard]

Does it work? I haven't even tried to do it. Simply because I don't know how to phrase it.

I don't think so - I don't remember putting anything in for it yet. We might be able to drop it and just keep MutEx groups, but things like "magic" armour can't reliably have the same MutEx, but needs to be exclusive of standard armour.

Off the top of my head maybe we could have somekind of "regular expression" based approach. I'm thinking if e.g. one could define that this stat has a value + a suffix of "+" and then it would just save the value ion the datafile and display/output the generated stat.

I'd be more inclined to go for special "stats modifier" values that are separate from stats. Special conventions would work in some cases, but then a) I'd need to handle odd cases like stats that just have "+X" as part of a full stats line (because some game system is bound to do it) and b) you'd have to write an almost completely empty stat line for your equipment. If you were thinking of proper addition rather than just "4+2" then you've also got the problem of flexibility - we allow anything, so you could end up with "A+2", which can't be calculated (at least not in base 10).

As for the great weapons, from a purely game-centric PoV then I'd almost be inclined to not list the increase from the weapon. I never did in my conventional lists because the weapons could potentially be ignored for some rounds (e.g. fighting Goblins you might prefer to hit first rather than having the overkill of the extra strength). Given the flexibility of the string values then you can put whatever you want, though.

I'm glad you like the system after working with it for a bit

[snowblizz]

As for the great weapons, from a purely game-centric PoV then I'd almost be inclined to not list the increase from the weapon. I never did in my conventional lists because the weapons could potentially be ignored for some rounds (e.g. fighting Goblins you might prefer to hit first rather than having the overkill of the extra strength). Given the flexibility of the string values then you can put whatever you want, though.

Ah well, I'm kind of used to having both base and modified stat showing. But take High Elf Swordmasters, there's no reason ever to not use the great weapon, they are effectively S5, but some times you'll need to know the base value for e.g. a strength test.
Similarly a magic weapon will force you to use the augmented S, however you'd still need to check the base if it was nullified or taking S tests.

Obviously you could know your own stats, and mostly I do, but I like to have all the information available to me. The less I'll have to check in an army/rulebook the better, those books suck at laying out information. That's the reason I want to list armoursaves as a stat. I don't want to be doing maths during the game if it can be avoided. Not everyone feels this way, TWF has thread where this is the complaint of some people, that the other program uses too confusing an output.


I'm brainstorming a bit how to use the multi-stats and stuff...
A Space Marine tactical squad is sergeant + 4-9 marines. 2 statlines, however the sergeant needs to be able to swap equipment. So I add him as a contained unit for the tactical squad with the 2 stat lines. How would I best incorporate so the number of models in a squad is 5-10 for when it matters. The equipment need a requirement in some cases for "if 10 models" I would assume <contained> units can be counted for unitsizes. Of course then again some should not. The Tactical squad needs a <contained> transport option that should not count towards the squad size. Interestingly the tactical squad encompasses much of the multistat/contained unit examples.

[IBBoard]

Swordmasters are bit of an exception, though, because they're one of the few units I know of that doesn't suffer the penalty I completely understand that some people might like to put weapon stats in as well, but it is never something I've thought about doing.

I'll definitely need to think about the armour saves. I'm inclined to treat them separately from main stats so that we can do the addition more easily, but the common approach is the hard part.

With something integral like a Sergeant in a Tactical squad, my first thought would be to include his stat line and have a "base cost" for the unit that includes his extra. The Sergeant's weapons would then be 0-1 limited, because he can't be removed, and would have to be duplicates with different names.

The other way would be to make the Sergeant a contained unit (a champion, once we define that relationship) and implement "if the unit numbers 10" as "if the unit numbers 9" because the required Sergeant makes it up to 10. Eventually we'll get requirement rules that would let you say "Tactical units MUST take a Sergeant".

[snowblizz]

Swordmasters are bit of an exception, though, because they're one of the few units I know of that doesn't suffer the penalty I completely understand that some people might like to put weapon stats in as well, but it is never something I've thought about doing.

Actually no. The whole High Elf army in fact is affected by this. ASF all the way. Dark Elf Black Guard when (and most do) they take the ASF banner are S3 but in effect 4 with halberds.
Chaos Knights are S4 base, 5 with standard "enscrolled weapons", but 4/6 if you are crazy enough to pay for lances on them. However S4 is what you need to know when they are hit by Black Horror.
A Chaos Lord of Nurgle on a bike has toughness 4(6), without bike 4(5) same as a lord on biek but not marked Nurgle.

Not super common but there are plenty of reasons to be able to show "multi-stats".

I'll definitely need to think about the armour saves. I'm inclined to treat them separately from main stats so that we can do the addition more easily, but the common approach is the hard part.

With something integral like a Sergeant in a Tactical squad, my first thought would be to include his stat line and have a "base cost" for the unit that includes his extra. The Sergeant's weapons would then be 0-1 limited, because he can't be removed, and would have to be duplicates with different names.

The other way would be to make the Sergeant a contained unit (a champion, once we define that relationship) and implement "if the unit numbers 10" as "if the unit numbers 9" because the required Sergeant makes it up to 10. Eventually we'll get requirement rules that would let you say "Tactical units MUST take a Sergeant".

For clarity I think I prefer the contained ie champion approach. also means I can separate the equipment out as normal marines have a "swap bolter for x" option while he has a "swap bolter and/or pistol" for x or z or y or..."
Since the contained unit wouldn't count for the unit size (whatever will we do with that) at least for now, making the unit 5-10 and as you say make a basepoint cost, which is how it works anyway seems the best approach. Then just hope the player includes his free sergeant .

Of course I'm still hoping to define "default" equipment that's not required. But that's another matter. I guess "pre-selected" would be a better word. Compulsory contained units would possibly also be useful.