Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vanity ship importing needs fixing #67

Closed
blitzmann opened this issue Mar 31, 2014 · 6 comments
Closed

Vanity ship importing needs fixing #67

blitzmann opened this issue Mar 31, 2014 · 6 comments
Labels
bug Confirmed to be a bug

Comments

@blitzmann
Copy link
Collaborator

Importing of vanity ships is somewhat broken. The import works, but there's no way of accessing it unless you search for the name as vanity ships are forcefully excluded from Pyfa's market.

This was not really an issue when they were limited ships, but now with the new skinning feature they are more common. Case in point: Police Pursuit Comet. Although these have the same stats as their regular counterpart, those who find a kill on the killboard may want to import the kill, and will not know to edit the kill to show the regular ship.

I propose one of three things:

  1. Maintain a skinned: unskinned relationship in the market service. On import, simply compare and save as the unskinned ship. However, this has an issue in that the price will not be accurate, and those who import a Police Pursuit Comet will not expect it to show up in the regular comet fittings.
  2. Add custom "Vanity / Skinned Ships" groups (like the custom "Limited Edition Ships"). This will allow people to import these fittings into Pyfa and show the correct ship / price info.
  3. A hybrid of the two: have a "Vanity" group, but also display any PPC fits with other Comet fittings (which would require us to maintain a relationship dict in the market service). This makes sense since it's essentially the same ship, and might be the best option.

I am not sure if CCP maintains the relationship internally. I don't think so, as there is no relationship in the variations tab in-game. If there is no internal relationship, it might be a pain to keep up to date when new skins are released.

@DarkFenX
Copy link
Member

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
Copy link
Collaborator Author

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
Copy link
Member

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 blitzmann added the bug label Apr 24, 2014
@blitzmann
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Confirmed to be a bug
Projects
None yet
Development

No branches or pull requests

2 participants