Opened 8 years ago

Closed 7 years ago

#356 closed defect (fixed)

issue with the percentageLimits in datafiles

Reported by: Henri Owned by: ibboard
Priority: minor Milestone:
Component: WarFoundry-API Version: WarFoundry 0.1
Keywords: Cc:
Blocked By: Blocking:


Basically I found a way for the user to crash the program when percentageLimits are used.

Attached datafiles are used. Pick a unit of Reavers from Fast Attack. Basic unit of 3 models. A 1 Blaster, then go and pick a Heat lance. It won't allow you to pick one, however, you can add 0.7% percentages of one, and the percentage is also the default so it could be done by mistake. Program crashes when clicking OK.
Interestingly it won't happen if you pick them the other way around (Heat lance, then Blaster). Also do it "right" once and you can then subsequently do it the "wrong" way with the same or other units. Until you start a new army and do it "wrong" for the first time.
Obviously this could be an "author induced error" as the for the other "pair" of options which combines aboluteLimit with percentageLimit this won't happen.

Attachments (2)

wh40k - Warhammer 40k 5th edition 0.3b.system (519 bytes) - added by Henri 8 years ago.
wh40k - Dark Eldar v0.1.race (5.2 KB) - added by Henri 8 years ago.

Download all attachments as: .zip

Change History (14)

Changed 8 years ago by Henri

comment:1 Changed 8 years ago by ibboard

Owner: set to ibboard
Status: newaccepted

Sorry for the delay - the email notification must not have been working.

I just checked in the GTK UI and was read to throw it back as "need more info", because it behaved. Trying in the WinForms UI does cause an exception, though. I'll investigate the cause and why there is a difference.

comment:2 Changed 8 years ago by ibboard

Or maybe not. That's going to be a pain - I recreated it the first time in the WinForms version, but the stack trace just kept on going. Now I keep restarting the WinForms app and can't recreate it. Still, it has happened once, so there is definitely something in the limits not playing nicely together.

comment:3 Changed 8 years ago by ibboard

The relevant snippet of the ongoing log from the first run was a repeat of the following:

  at IBBoard.WarFoundry.API.Objects.Unit.GetSelectionTotal (System.Collections.Generic.List`1<IBBoard.WarFoundry.API.Objects.AbstractUnitEquipmentItemSelection>) <0x0004c>
  at IBBoard.WarFoundry.API.Objects.Unit.GetEquipmentAmountInSlotExcludingItem (IBBoard.WarFoundry.API.Objects.UnitEquipmentItem) <0x0008f>
  at IBBoard.WarFoundry.API.Util.UnitEquipmentUtil.GetEquipmentCountLimit (IBBoard.WarFoundry.API.Objects.Unit,int,IBBoard.WarFoundry.API.Objects.UnitEquipmentItem) <0x000bf>
  at IBBoard.WarFoundry.API.Util.UnitEquipmentUtil.GetMaxEquipmentCount (IBBoard.WarFoundry.API.Objects.Unit,IBBoard.WarFoundry.API.Objects.UnitEquipmentItem) <0x00057>
  at IBBoard.WarFoundry.API.Objects.UnitEquipmentRatioSelection.CalculateNumberTaken (IBBoard.WarFoundry.API.Objects.Unit,IBBoard.WarFoundry.API.Objects.UnitEquipmentItem,double) <0x00067>
  at IBBoard.WarFoundry.API.Objects.UnitEquipmentRatioSelection.get_NumberTaken () <0x00027>

Presumably it leads to a stack overflow exception.

comment:4 Changed 8 years ago by ibboard

Status: acceptedneedinfo

I'll try to create a test case for this that causes the error, but it looks like the data might not be helping. The Reavers have a slot with a 34% limit, rounding down, where as each individual weapon has a limit of 33%, defaulting to rounding up. That explains the 0.7% (1 in 3 = 33.3%,which is 0.7% lower than the slot limit).

Do the weapons need the limits if the slots they are in already have limits?

comment:5 Changed 8 years ago by ibboard

Status: needinfoaccepted

For future reference, it does recreate in both. The instructions to recreate it are ever so slightly wrong:

Don't add one Blaster. Increase the number of blasters to 1 to make the %age read "33", but then stick with adding a percentage instead of a fixed number. Adding 1 doesn't cause a problem because the maths on the limit is easier as only the 0.7% is involved.

comment:6 Changed 8 years ago by IBBoard <dev@…>

In [7179c585d31d9160dafcb011705226cb235c953f/IBBoard.WarFoundry.API]:

Re #356: Stack overflow with some equipment limits

  • Add RawNumberTaken to be used in some locations to avoid indirect recursion
  • Use new RawNumberTaken within Unit equipment counting method

Overflow fixed, but results not correct

comment:7 Changed 8 years ago by IBBoard <dev@…>

In [7e95b880f9ccc19f1d9893632ca469db5d37f7b5/IBBoard.WarFoundry.API]:

Re #356: Stack overflow with certain equipment limits

  • Set sensible default equipment cost multiplier

comment:8 Changed 8 years ago by IBBoard <dev@…>

In [ce40484ad921e21aec9dfc102fe2b2359ad1a248/IBBoard.WarFoundry.API.Tests]:

Re #356: Exception caused by unit limits

  • Add test that triggers the stack overflow, based on example data file

comment:9 Changed 8 years ago by IBBoard <dev@…>

In [49b359624ea59f047aeb69ec1b1a78a02f6fc9c8/IBBoard.WarFoundry.API.Tests]:

Re #356: Stack overflow with some equipment limits

  • Add more values to data to test amount counting from various directions

Note: The end of this code highlights a larger bug/design flaw

comment:10 Changed 8 years ago by IBBoard <dev@…>

In [cd2aeab2357f7b46f999b96fe730d00b9bae1ce8/IBBoard.WarFoundry.API.Tests]:

Re #356: Add factory for UnitRequiresNoMoreThanNOfUnitTypeRequirement

  • Rename factory
  • Update unit tests from basic copy/paste/find&replace

comment:11 Changed 8 years ago by IBBoard <dev@…>

In [93c373701016191a9de35b352868ffd132e23a3e/IBBoard.WarFoundry.API]:

Re #356: Add factory for UnitRequiresNoMoreThanNOfUnitTypeRequirement

  • Fill in body of methods, based on existing factory
  • Rename factory to match requirement

comment:12 Changed 7 years ago by ibboard

Resolution: fixed
Status: acceptedclosed

Seems to be fixed by comment:9. No overflow and results appear correct. Not sure what the larger flaw was, but it will be ticketed when it is found.

Note: See TracTickets for help on using tickets.