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

Meta Compare Iterations #646

Open
Aelonius opened this issue Jun 11, 2016 · 5 comments
Open

Meta Compare Iterations #646

Aelonius opened this issue Jun 11, 2016 · 5 comments
Labels
todo Neither really a bug nor a feature, just something that has to be done.

Comments

@Aelonius
Copy link

(Sorry for the many tickets in a row but I feel each subject deserves its own ticket to make them more managable!)

Whenever I am trying to design ship fittings it is fairly inconvenient to compare the differences between two setups in a clear fashion. I am curious to know if it's difficult to build a functionality that allows you to compare the stats of two fittings side-by-side, so that it's easier to both share (via screenshots) and gives a better insight in ship fits.

One way I can envision this is that you have one window with an item or fit, and it tells you the differences in final stats for a certain character selected next to it. If I were to gain 100m/s with the selected fit to compare, that it shows clearly how much difference there is.

@blitzmann
Copy link
Collaborator

This is something I think about every few months...

The problem here mostly has to do with the general layout of pyfa - this is one area where I think eft has a leg up on us, as two different fits can be shown side by side.

The proper way would be to allow someone to be able to drag out a fitting tab and pop a new window with it. Another way would be to simply open a stats view of a fit into another window without the fitting view (in which case, might as well get the fitting view as well...).

I honestly don't know how big of a scope those changes would be. Popping a new window with another fitting view is not in itself difficult, but decoupling all the events surrounding the fitting view (fit change, character change, state change, etc) would be a bitch and require quite a lot of refactoring to eliminate the assumption of only one view.

As for your idea or what it might look like, I'm not sure I understand. Do you mind elaborating?

@Aelonius
Copy link
Author

I pulled an example from wowhead.com's item comparison tool:

http://puu.sh/pq94u/43746ddd6f.png

That is pretty much what I'd love to see for items and/or ships. The third column in this example is the worse than the first column, so all values lower than the primary ship you compare it to should be red if worse, green if better.

Does that make sense?

@blitzmann
Copy link
Collaborator

Here's a thing

capture

I want to do some tweak ofc (column sorting, highlighting min/max, etc), but the base is there. Working off branch https://github.com/pyfa-org/Pyfa/tree/feature/item-compare

@blitzmann blitzmann added enhancement This is a feature request, or an idea to enhancement a current feature In Progress This issue is currently being worked on. labels Jun 16, 2016
@blitzmann
Copy link
Collaborator

I've added this feature as it is in the above image. The following logic is used:

  • If attribute does not have a display name, don't consider it for comparison. This is because attributes that don't have a display name are usually internal attributes. This can be reevaluated if needed.
  • Like attributes are compared on all the items, and if they are all the same, it is not considered for comparison. This is to keep the compare list from growing too long displaying redundant information.
  • Sorted by meta level

This feature will be released as-is with the June release next week. I'm going to mark this as done until then.

However, at that time I'll gear this issue as more of an iteration tracker for this feature, as there are still some things that I wish to get done for it. Namely:

  • Highlighting best values
  • Sortable columns
  • Selectable attributes

@blitzmann blitzmann added done This task is done! \o/ and removed In Progress This issue is currently being worked on. labels Jun 24, 2016
@Aelonius
Copy link
Author

Looks great! :-)

I am currently really occupied irl but when that's sorted I'll get back to
you about this w/ feedback.

2016-06-24 5:24 GMT+02:00 Ryan Holmes [email protected]:

I've added this feature as it is in the above image. The following logic
is used:

  • If attribute does not have a display name, don't consider it for
    comparison. This is because attributes that don't have a display name are
    usually internal attributes. This can be reevaluated if needed.
  • Like attributes are compared on all the items, and if they are all
    the same, it is not considered for comparison. This is to keep the compare
    list from growing too long displaying redundant information.
  • Sorted by meta level

This feature will be released as-is with the June release next week. I'm
going to mark this as done until then.

However, at that time I'll gear this issue as more of an iteration tracker
for this feature, as there are still some things that I wish to get done
for it. Namely:

  • Highlighting best values
  • Sortable columns
  • Selectable attributes


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#646 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ALRS9lY092nVtY5q5RiuLiFM2fFPc_5Fks5qO03ugaJpZM4Izl-x
.

@blitzmann blitzmann changed the title Request: Item and Fitting Comparisons. Meta Compare Iterations Jul 2, 2016
@blitzmann blitzmann added todo Neither really a bug nor a feature, just something that has to be done. and removed done This task is done! \o/ enhancement This is a feature request, or an idea to enhancement a current feature labels Jul 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
todo Neither really a bug nor a feature, just something that has to be done.
Projects
None yet
Development

No branches or pull requests

2 participants