#217 closed defect (released)
Rounding problem with equipment cost calculations
Reported by: | ibboard | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | WarFoundry 0.1 |
Component: | WarFoundry-API | Version: | Trunk |
Keywords: | rounding equipment cost | Cc: | |
Blocked By: | Blocking: |
Description
The example in #209 of Ork Boyz is now working for the limits but not for the calculated costs. If a unit of 11 takes 10% then that should limit them to 1 but the calculated cost includes 2. This is probably due to a rounding error and should be checked.
Change History (6)
comment:1 Changed 10 years ago by
Status: | new → confirmed |
---|
comment:2 Changed 10 years ago by
comment:3 Changed 10 years ago by
(In r404) Re #217: Rounding problem with equipment cost calculations
- Temporary solution (which I thought I'd already committed yesterday) to make sure that rounding of amount doesn't round outside limit if limit and item rounding directions are different
Re #220: Make percentage and numeric amounts more obvious
- Deprecate some calculation and presentation methods and move them to UnitEquipmentUtils
- Add method to return the number of equipment items taken rather than the amount taken
comment:4 Changed 10 years ago by
Resolution: | → fixed |
---|---|
Status: | confirmed → closed |
Sticking with option (c) for now until someone files a bug about it or suggests something else in our forum thread
comment:6 Changed 10 years ago by
Resolution: | fixed → released |
---|
Mark fix as released under a previous version
Note: See
TracTickets for help on using
tickets.
Problem is caused because ratio selection's "AmountTaken" property uses UnitEquipmentItem.RoundNumberUp (which defaults to "true" and rounds 10% of 11 = 1.1 to 2) but the equipment limit is a percentage limit with a rounding down, which rounds 1.1 to 1 when it shows the equivalent.
This is partially a data definition problem (setting equipment to round up when the max limit rounds down fractions). We need to decide whether to a) ignore this problem/report it as a warning but not an error and leave it as a "data file creator mistake", b) round the limits and the "amount taken" calculation in one direction (which would reduce the flexibility of the limits) or c) ensure the number is always within the limits, no matter what.