#195 closed defect (released)
Setting max equipment without min may not function correctly
Reported by: | ibboard | Owned by: | ibboard |
---|---|---|---|
Priority: | major | Milestone: | WarFoundry 0.1 |
Component: | WarFoundry-API | Version: | |
Keywords: | min max constraint unitequipment | Cc: | |
Blocked By: | Blocking: |
Description
As alluded to by Snowblizz, we might have problems when a minimum is set but a maximum isn't. The default behaviour should be to set max=min if max < min and min=max if min > max.
Attachments (1)
Change History (14)
Changed 10 years ago by
Attachment: | crash12.txt added |
---|
comment:1 Changed 10 years ago by
Finally got a handle on this. If I do this:
<unitEquipment>
<unitEquipmentItem id="DPMark" maxNum="1" />
</unitEquipment>
I can add an equipment option but with no cost and no amount. So it shows up but does not "exist". I can't then delete or modify it. Edit crashes, remove does nothing. If I have a minNum it will work as the Value is allowed to be 0. I guess the correct way to do this is to set both minNum and maxNum to 1. So in principle it is the logic of the datafile creator which has broken down. ;-)
comment:2 Changed 10 years ago by
Owner: | set to ibboard |
---|---|
released: | → no |
Status: | new → needinfo_new |
Just to check, is the problem that an equipment item can be added for zero of an item? Or is it something earlier on in the actual selection? A count of zero should be handled by the API already as a "remove", so I'm not quite sure how you got to that situation!
Letting minNum default to 0 seems reasonable enough as it just means that the item isn't taken, so the XML should be valid.
comment:3 Changed 10 years ago by
In so far yes the problem is that you can take an item and pick zero of it. However it is not possible to edit or remove this "zero piece" of equipment. So you are stuck with it.
I guess logically if you pick something, you'd need at least 1, however one never knows, it might be useful with zero amount equipment.
However, the issue is (if one chosoes to see it so, it might not necessarily be) that if you define a maxNum, it expects a minNum to be present as well.
comment:4 Changed 10 years ago by
Summary: | Setting min equipment without max may not function correctly → Setting max equipment without min may not function correctly |
---|
The selection issue has been separated out as #201 - taking 0 of an item is the same as not taking it, so we shouldn't allow it. If there's something that you want to take without it costing anything then there are cost multipliers.
I'll keep this ticket as the "if maxNum is set then minNum isn't handled correctly" ticket.
comment:5 Changed 10 years ago by
Status: | needinfo_new → accepted |
---|
Just run a couple of tests and it seems to be behaving as expected. I guess that perhaps we need to alter "as expected" so that as soon as "max" is defined then "min = max" if min isn't set. That'd help shrink the definition and stop you ending up with a default of 0 of an item taken.
comment:6 Changed 10 years ago by
comment:7 Changed 10 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
comment:8 Changed 10 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:9 Changed 10 years ago by
comment:10 Changed 10 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:11 Changed 10 years ago by
comment:13 Changed 10 years ago by
Resolution: | fixed → released |
---|
Mark fix as released under a previous version
debug text