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.

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).

What's the difference between re-rolling "failed" and "possible failed" results?

There are 2 slightly different variations of "re-rolling" out in the wild: "re-roll failed" and the more modern/useful "re-roll". The inclusion/omission of the word "failed" is the distinction and does make a practical difference to what can be re-rolled. To understand why, we need to refer to page 200 of the 9th Edition 40k core rules where it states that "Re-rolls are applied before modifiers (if any)". Under certain circumstances, this rule means that what constitutes a "failed" roll can change depending on whether any modifiers have been applied yet.

Here's an example:

1. An attacking unit with BS 2 and access to "re-roll all failed" vs a defending unit that has a -1 to hit modifier.
2. The attacker rolls to hit and rolls a 2. At this moment in time, the roll is considered successful and no re-roll can be made.
3. Now the -1 to hit modifier is applied. This is applied to the hit roll result which turns the roll of 2 into a 1.
4. The modified roll of 1 fails.

Now consider the same scenario but swap the attacker's re-roll ability from "re-roll all failed" to "re-roll all":

1. An attacking unit with BS 2 and access to "re-roll all" vs a defending unit that has a -1 to hit modifier.
2. The attacker rolls to hit and rolls a 2. At this moment in time, the roll is considered successful but knowing that a -1 to hit modifier is about to be applied the attacker chooses to re-roll - they can do this because their re-roll ability does not stipulate "failed".
3. The attacker re-rolls and this time rolls a 3.
4. Now the -1 to hit modifier is applied. This is applied to the hit roll result which turns the roll of 3 into a 2.
5. The modified roll of 2 is successful.

UnitCrunch caters for each of these variants by offering both "Failed result(s)" and "Possible failure(s)" as options under "Result to re-roll" when configuring a re-roll modifier/ability.

• "Failed result(s)" is designed to model the use of a "re-roll failed" ability. This re-rolls any results that are considered failures (before modifiers are applied).
• "Possible failure(s)" is designed to model the use of a "re-roll" ability. This re-rolls any results that are considered failures and factors in any roll modifiers that are to be applied when determining a failed result.

As new & updated rules are published it seems that "re-roll failed" is slowly being replaced with just "re-roll". UnitCrunch will aim to offer both options until that replacement is complete.

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 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). UnitCrunch cannot decide which weapon or roll it is best to use a re-roll on beyond the modifier's criteria.
• 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 9th Edition rules?

Yes it does. It has done since version 0.3.0.

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 9th 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

Currently, you can add a maximum of 10 weapons to a profile. If you have an example use case that reasonably requires more than 10 weapons per profile 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.

There's also a legitimate concern regarding Games Workshop's intellectual property. Without getting too far into that particular issue right here, let's just say that the less datasheet info UnitCrunch provides out of the box, the better.

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 BattleScribe, Wahapedia and various blogs/forums it should be fairly easy to get hold of the required datasheet information.

How will you finish painting your Ad Mech if you spend your spare time developing this awesome MathHammer app?

Slowly I guess?