Add Same Base Type recipe and related changes (item is identified, item base type, etc.)

[GoogleCodeExporter]

When I play PoE I spend a lot more time using recipes than trading.  Here is a 
patch to add another set of recipes.

The overall goal here is to add the "same base type" recipe.  This has a number 
of variants, but the primary two (in my opion) are that one identified normal, 
magic and rare item of the same base type (e.g., "Crude Bow") sells for one Orb 
of Augmentation; and if those three items are either normal rarity or 
unidentified, they sell for two Orbs of Augmentation.  In order to support 
this, the GearTypeRunner class was expanded to determine an item's base type.  
All known base types were added to the various runners, so all items can be 
definitively identified.  Lists of "generic" types for some runners were added, 
which allow the runners to function the same way they did before for 
determining an item's GearType (that is, only search based on generic words or 
phrases).  Also, the PoE API includes information on whether an item is 
identified or not, but this was not being recorded by the application.  I added 
that to the model.  Normal rarity items are always considered identified, 
apparently.

Change notes:
- Performed remaining tasks to support remaining "quality" to "rarity", such as 
renaming the getQuality method Item to getRarity.  Also, filters that use the 
term quality in this context were renamed (both in the class names and file 
names).
- Similar to the above renaming, the "white" rarity was renamed to "normal".
- Changed "Unknown" to be the default (first) GearType value, so we can more 
reliably make assumptions about an Item if it does or does not have that 
GearType.
- Added support for items having a "BaseType".  This is inferred by the runners 
based on the item's TypeLine, simliar to how the GearType is inferred.  This, 
however, requires knowing the exact name of all base types, and the runners 
have been expanded to include all of them (based on the Path of Exile wiki). 
(Yes, that took a long time to type up... no guarantee there are no spelling 
errors, but I haven't noticed any yet up to about the level 40 items.) If an 
item has a non-unknown GearType, only the runner for that GearType is queried 
to determine an item's base type.  If the GearType is unknown, all runners are 
queried.
- Re-added Map as a GearType.  Maps can have a base type (presumably... I don't 
have a high enough level character), and this is determined by the MapRunner, 
like all other items.  If maps have a GearType that is different from Unknown, 
we can more easily determine their base types (see below).
- Fixed spelling error in runner classes (compatable --> compatible).
- Changed determining an item's GearType into a two step process.  First 
generic types are checked, which, if present in a runner, essentially contain 
the strings that were used previously.  If none of those match, search all of 
the known base types.  This hopefully will minimize the number of string 
comparisons needed to determine an item's GearType.
- Added a Name property to RecipeResult and a GetResultName method to Recipe.  
Some recipes, like the one being added here, can have their outputs (and thus 
name) vary widely based on minor differences, and the items that make up the 
recipes should be mutually exclusive, so they can not easily (or at all) 
handled by using completely separate Recipe classes or by using a string 
determined before the RecipeResult is created.  The RecipeResult Name property 
is essentially a wrapper around the GetResultName method, and the latter, in 
the default case, simply returns the recipe's name.  The SameBaseType recipe 
examines the contents of the RecipeResult to determine what the name should be.
- Added a new recipe, SameBaseTypeRecipe.  This uses a concept of "constraints" 
to look for progressively less strict conditions on the items that would make 
up the recipe.  This allows us to first look for the "best" (most valuable) 
combinations for the recipe, and, when they are not available, look for other 
combinations.  And, by including these in a single Recipe class, a single item 
can not be used in multiple variations of this formula.

I have been using the git-svn tool to develop my changes, so I took advantage 
of the "git diff --stat" feature to provide an overview of all the changes in 
the patch (number of additions and deletions per file).  That is in the 
patch-stats.txt file.  The full diff is in patch.diff.  It was based off of 
revision 133 (I did a bunch of rebasing to make sure the diff cleanly applies 
to the trunk; my sincerest apologies if I introduced but didn't catch a bug in 
that process).

Original issue reported on code.google.com by cmaca...@gmail.com on 18 Nov 2013 at 4:29

Attachments:

• patch.diff
• patch-stats.txt

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Great stuff man! You've been busy, I was just about to rename all the 
getQuality etc methods!

Do you have a name or alias I can use, would like to credit you for these 
contributions!

Original comment by stickymaddness on 18 Nov 2013 at 10:20

• Changed state: Started
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I committed your changes, it's great to have all these new recipes!

However, I removed some of the changes to GearTypeRunner, as I want to keep 
this class as clean and maintainable as possible. As an example, for the helm 
runner it is not necessary to check for exact names, merely adding "Hat" will 
be enough for the result to be found. These types were missing purely because 
when the classes were created, these new base types did not exist.

Original comment by stickymaddness on 18 Nov 2013 at 12:45

• Changed state: Done

[GoogleCodeExporter]

Sure, my name is Charles Macanka.  You can use that. (A user name or alias I 
tend to pick is Thailyn, as in https://github.com/thailyn , but that quickly 
leads back to my name.  And I was a week too slow with PoE, so this is me: 
http://www.pathofexile.com/account/view-profile/Komishne .)

Unfortunately, if we do not figure out exactly what an item's base type is, we 
can get incorrect recommendations from Procurement with this recipe.  For 
example, it can think three different "glove" items are all the base type, 
since they all have that word in their TypeLine, but they do not give Orbs of 
Augmentation when sold (see attached screenshots -- I don't mean to be 
pedantic; I had to double-check the recipe myself).

I understand your concern with not wanting to overburden the GearTypeRunner 
class.  What about having a parallel set of classes -- something like 
BaseTypeRunner -- to determine an item's base type?

Original comment by cmaca...@gmail.com on 19 Nov 2013 at 1:02

Attachments:

• ProcurementSuggestion.png
• RealSellValue.png

[GoogleCodeExporter]

One of the changes I made in this patch was to rename the "White" Rarity to 
"Normal".  I made that since it was the more technically correct name 
(referenced as such in game), but it looks like the term "White" is more 
commonly used in the community.  One of the effects of that change was to 
change the related {RarityGearType} filter, which I did not notice at the time. 
 The attached patch effectively makes "White" an alias for "Normal" in the 
GearVisitor's filters, so people can continue using their current filters, such 
as {WhiteBow}.  I think this is a better solution than not recognizing the old 
rarity name anymore and forcing users to change.

Original comment by cmaca...@gmail.com on 19 Nov 2013 at 11:00

Attachments:

• patch.diff

[GoogleCodeExporter]

Hey man,

Sorry I haven't got back to you on this, I understand the issue now, I couldn't 
understand why you'd gone to the trouble of typing out the exact names!

I'll review this again when I get a chance, I think it might be more 
maintainable if we create an xml file with all of the names.

Original comment by stickymaddness on 26 Nov 2013 at 3:00

[GoogleCodeExporter]

I've committed your changes to GearTypeRunner, now that I properly understand 
the necessity of it! 

I would still like to refactor this to read the types from a GearType.xml file, 
but have committed it as is so that the changes can be released sooner.

Thanks again for your work!

Original comment by stickymaddness on 31 Dec 2013 at 12:10