Frequently asked questions

How does UnitCrunch calculate results?

UnitCrunch performs a single simulation by proceeding through the steps of an attack sequence just as you would on the tabletop. The difference is that UnitCrunch can't roll real dice and so has to randomly generate numbers to represent dice rolls.

The results of each step are recorded along with the outcomes of the sequence. The entire simulation is then performed again, as if for the first time, for as many times as you specify. Once all of the simulations have been performed and recorded, the results are counted, analysed and displayed.

A simulation like this, that has variables that can change randomly is often referred to as a "stochastic simulation". By repeating this simulation many times over and recording the results every time, we can use the "Monte Carlo" method to estimate the most frequent value of any of the random variables involved. This is what enables UnitCrunch to estimate the most frequent result for a variety of different aspects of an attack sequence.

Can I import data from another app/website into UnitCrunch?

Currently, you can't import data from anywhere other than a file exported from UnitCrunch.

Creating such a feature is technically possible but UC's internal data schemas are still under heavy development so any such feature would only work for a few days/weeks before it needed updating again (which would become very tiresome). I`d certainly consider attempting such a thing once UC`s schemas are more stable.

Is UnitCrunch "open source" software?

UnitCrunch is not currently open source software.

If you'd like to contribute to the project there are currently 2 main options:

  1. Report bugs, raise feature requests and join the discussion on the GitHub issue tracker.
  2. Join the UnitCrunch Patreon.

Why are there 3 different types of modifier available (global modifiers, profile abilities & weapon abilities)?

In UnitCrunch, these are referred to as modifier "scopes". While very similar, each scope serves a slightly different purpose and is applied in a slightly different way. Note that different scopes have a slightly different list of conditions & effects available to them.

Global modifiers

  • Scoped to the entire simulation irrespective of what profiles are currently selected.
  • Global modifiers persist when you change the currently active attacker/defender profile.
  • Good for simulating effects that are "external" from the currently active profiles. E.g. Stratagems, auras, army rules, detachment rules etc.

Profile abilities

  • Scoped to a specific profile and so can only be active when that profile is selected.
  • Must include a "Profile role" condition so that UC knows whether to apply the effect when the profile is selected to be an attacker or defender.
  • Saved with the profile itself and so is always recalled whenever that profile is selected.
  • Good for simulating effects that are bound in some way to the profile but not to any specific weapon they may have. E.g. Datasheet abilities, stratagems that apply to specific units for easy recall.

Weapon abilities

  • Scoped to a specific weapon on a profile and so can only be active when that weapon is selected.
  • Saved with the profile itself and so is always recalled whenever that profile is selected.
  • Good for simulating effects that are bound in some way to a specific weapon. E.g. Weapon abilities or "USR"s, stratagems that apply to specific weapons for easy recall.
  • Some modifier features can only be applied to weapon abilities as UC needs to know which weapon they should be applied to (on a multi-weapon profile). E.g. Re-roll limit (single re-rolls).

How are multi-weapon units handled and how do I interpret the results?

Attacker units with multiple weapons fire them in the order that they are listed (currently, this is the order that you added the weapons to the profile).

UnitCrunch does cater for the following scenarios commonly found on the tabletop:

  • When more weapon damage is used to slay a model than is required, the remainder is not carried over to the next model in the unit (the remaining damage is wasted).
  • If a weapon wounds a model without slaying it, the next weapon to fire in that simulation will potentially receive the benefit (i.e. the next model targeted will not be starting on full wounds).

How does UnitCrunch handle re-rolling damage?

Programming optimal damage re-rolls is really hard. UnitCrunch has made a few assumptions & simplifications in order to offer damage re-rolls:

  • The result that you set as the trigger for a re-roll (using either a single value or a range) is the result of the applied dice notation. E.g. If your weapon does D3+3 damage and you only want to re-roll minimum damage, you need to target a result of 4 (a D3 roll of 1 + 3). Using the same weapon as a further example, if you wanted to re-roll all but the maximum damage you would set a range of 4–5.
  • Re-rolls applied as global modifiers or profile abilities are applied to every weapon a unit has selected, in the order that the weapons are listed. If you want re-rolls to only be activated for specific weapons, apply them as weapon abilities to just those weapons instead.
  • Re-rolls that can only be applied once to a single roll will be used as soon as their criteria is met (e.g. as soon as a result of 1–2 is rolled or whatever you've specified).
  • If a unit has access to both a "single-use" re-roll (as described above) as well as a "multi-use" re-roll (e.g. re-roll all results of 1), UnitCrunch will always try to avoid wasting the "single-use" re-roll on a roll where an available "multi-use" re-roll can be applied.
  • Considerations such as how many wounds the target has left or "whether it's worth re-rolling this weapon's damage against that dreadnought given it's -1 damage de-buff" are beyond UnitCrunch's reasonable capabilities and are best left to the tabletop.

Fishing for results or "Why would I want to re-roll a successful roll?"

UnitCrunch notifies you when you've configured a modifier that could potentially re-roll a successful roll. It only notifies you, it doesn't stop you.

These sorts or re-rolls can be useful when modelling an in-game strategy known as "fishing". This is normally when an effect would be triggered on a specific roll (e.g. a mortal wound on an unmodified roll of 6) and an available re-roll makes it worth trying for those 6s despite the risk of turning some previously successful rolls into failures.

How do I suggest a feature / report a bug?

Suggestions & bug reports are very welcome.

For questions, feature requests & bug reports please visit the UnitCrunch subreddit.

Please check the existing posts first to see if your issue / feature request / question has already been raised.

Does UnitCrunch cap hit/wound modifiers at +/- 1 as per 10th Edition rules?

Yes it does. It has done since version 0.3.0. It also prevents saving throws from being improved by more than 1.

Will you make a UnitCrunch mobile app?

I have no plans to make a mobile app, I don't think we need one. While I agree that there is a shortage of good quality MathHammer mobile apps, especially 10th Edition MathHammer apps, my opinion is that everything we need can be done via a website so long as it works well on mobile.

UnitCrunch has a way to go before it works as well on mobile as it does on desktop but even now it's more than usable. My plan is to continue to refine the experience on mobile as much as I can.

What is "MathHammer"?

There's a whole page for this one: What is MathHammer?

What's all this about "discrete" & "cumulative" probability?

When you start digging into mathematical probability you'll soon bump into terms like "discrete probability distribution" and "cumulative probability distribution". MathHammer tools, apps and websites will also sometimes use these terms and sometimes they'll just assume you know what they mean!

Now I'm a web developer, not a mathematician, so here's my attempt at explaining what you need to know in layman's terms:

When you use UnitCrunch the "discrete probability distribution" is represented by the blue bar graph. Each bar shows the percentage of times that an individual result occurred over all of the simulations performed. All of the percentages represented by the bar graph should add up to 100%. It's "discrete" because only integer values are considered (all of the expected dice results will be integers).

The "cumulative probability distribution" is the pinky-purple line graph. It displays the percentage chance of a result occurring but also adds all of the chances of a "better" result occurring (hence why it's "cumulative").

That should be enough to get by on UnitCrunch and in MathHammer more generally. If you're after further detail I suggest checking out something like the Wikipedia entry for "Probability distribution".

I can't add any more profiles

Currently, you can add a maximum of 200 profiles per browser. Local storage limits vary from browser to browser, imposing a maximum number of profiles helps stay below the limits and keeps things running smoothly.

I can't add any more weapons to my profile/unit

Currently, you can add a maximum of 15 weapons to a unit. If you have an example use case that reasonably requires more than 15 weapons per unit I'd love to hear about it in the UnitCrunch subreddit.

How can [I/we/the community] add to the demo profiles?

TLDR: The demo profiles that UnitCrunch provides "out of the box" are for demo purposes only - that's why they're called demo profiles!

I've had multiple requests from users asking how they can add to the demo profiles. This seems based on the opinion that it would be convenient for users to find the units that they're interested in ready to go within UnitCrunch. While I agree that this would be very convenient, I also think it's impractical as the sheer number of profiles that would need to be created is huuuuuge (bearing in mind all of the possible different model counts, wargear variations etc). Not only would this take a long time to populate but it would be a nightmare to maintain & verify. Also, delivering this volume of data in a user friendly and performant way would be no small feat.

This is why UnitCrunch takes the approach that it does: provide the user with the tools to create the units that they want and have that data be saved in the browser so that it's easy to make it exclusive to that user.

Between the codices that you own and other digital resources such as New Recruit, Wahapedia and various blogs/forums it should be fairly easy to get hold of the required datasheet information.

Why is "Damage not ignored" lower than expected?

When simulating an attack sequence, most steps are not capped: there is no limit to attacks, hits, wounds, unsaved wounds or calculated damage. This changes when you get to calculating models slain (you cannot slay more models than there are in the defending unit) and damage not ignored (you cannot ignore more damage than has been dealt and you cannot ignore damage if your defending unit is slain).

That last point is important: "you cannot ignore damage if your defending unit is slain". To reflect this, UnitCrunch stops attempting to ignore damage via a "Feel no pain" ability if the defender's models have all been slain (because UnitCrunch is effectively slow-rolling everything - just really fast). This often results in a lower average result for "Damage not ignored" than you might expect if you were to simply apply a FNP to the "Damage dealt" result (by multiplying damage dealt by the FNP expressed as a fraction). Performing the latter, more simplistic calculation would include "overkill" - FNP rolls are still being applied to points of dealt damage, despite the defender already being slain.