Vanity ship importing needs fixing about pyfa

[DarkFenX]

I would not assume it is the same ship. There were cases when ship stats differ (after t1 hull rebalance, vanity variation wasn't updated, e.g. ishukone watch scorpion). Thus hybrid approach won't be a very good idea.

[blitzmann]

Point noted, that would require us to trust CCP to update accordingly. -_-

A custom group would seem to be the best course of action, then, unless there is objection. I've got a local branch with these changes - currently with all vanity ships noted in the market service. However, not all vanity ships are part of the new, replenish able skinned ships. Should we just include those that were added with Rubicon 1.3?

[DarkFenX]

It might be good solution, but short-term: i think chances that ccp will change painting approach rather sooner than later (to single typeID with multiple paint 'modules' or whatever). When they do it, we might need to do database conversion jobs which are always pain in the ass - both to prooftest and maintain in future.

Considering this, i would prefer 'mapping' to original typeIDs, even though it might be not very accurate in some edge cases (CCP probably even fixed ishukone scorp, i didn't check). This could also be used to maintain map of old names to typeIDs if we will want to support old module names for importing in future.

[blitzmann]

Totally forgot about this issue. I think we need to do this at EOS level, so that way we can easily do the conversion from eos.getItem(). I haven't looked at it, but we could simply import the map, and if found simply replace it and got from there.

We could also import the mapping into the market service so that we can force publish settings. I'll take another look at this soon.

[blitzmann]

Actually, this was fairly easy: #97

Wasn't really sure where to put the conversion map, so I made a new file for it. And I'm also bad at naming files, so feel free to rename it to something better =3

[DarkFenX]

Just for the sake of documentation:

I suggest to move it to service layer, or at least move from DB-related eos part to fit importing part.