search

Map-A-Droid / MAD

Map PoGo stuff with Android devices
211 stars 133 forks source link

Make IVList more userfriendly #888

Closed JabLuszko closed 2 years ago

JabLuszko commented 4 years ago

There are few issues how IVList works (on top of UI, different ticket, however this would probably mostly sort it too).

Few things would be nice:

  1. Make MAD fill all the missing mons - if IV List is [15, 13, 14, 659, 479] just throw everything missing in numeric order [from 1 to 900] after what was explicitly configured.

  2. Create a default IV list, automagically used everywhere, make it empty by default (but not really, first point - everything).

  3. [Probably, could be achieved other way] do not store "missing mons" in database - fill those on runtime - this way there is no need to rework madmin UI iv list mon picker and with only what we explicitly configure that list would have (for most people) 60 entries, rather than 900.

crhbetz commented 4 years ago

Good idea and should be easy to implement in principle. Point 3 should absolutely be done this way, way better usability to not store the auto-filled numbers in database.

We'll need to consider iv_mitm though, in that mode it can make sense to leave out unwanted mons because it builds a prioQ/route through active, unchecked mons that are in the IV list. I think it only orders by time, not IV list priority, even?

We could

  1. not do the autofill on iv_mitm
  2. make the autofill toggleable

Should be discussed before implementation.

JabLuszko commented 4 years ago

iv_mitm seems to be using mon order priority to sort entries (not time) (however it's also using it earlier to discard results from db), so putting all unwanted mons will just (or "just") increase the number of events in queue, final order should stay the same.

https://github.com/Map-A-Droid/MAD/blob/d04a0531518b8eb9c8c7ec5f9ddf832b87a6f1b0/mapadroid/db/DbWrapper.py#L420

crhbetz commented 4 years ago

So to sum it up - no negative side effects for iv_mitm scan results?

Another thought: numeric order [from 1 to 900] - wouldn't it be more interesting going backwards 900 to 1?

JabLuszko commented 4 years ago

Another thought: numeric order [from 1 to 900] - wouldn't it be more interesting going backwards 900 to 1?

Yes / No / Depends. PVPers wants everything, random new people would probably like 35 level first gen starters before December "CD". In theory we could steal dkmurs newest IV list and use that one, just... because it's already done and better than 1-900 or 900-1. https://github.com/dkmur/MAD_IV_list/blob/master/ivlist_2020-05-06

So to sum it up - no negative side effects for iv_mitm scan results?

Yes. DISCLAIMER: If I am reading code correctly. I do not use iv_mitm [more mon_mitm here] at all so can't really test, just throwing ideas and my basic python knowledge

crhbetz commented 4 years ago

Could probably even auto-integrate the newest dkmur list :trollface:

Not using iv_mitm either and previously overlooked the DbWrapper part you linked.

I'll whip up a PR for this as soon as I find the time. Not mad if someone else does it faster though.

marcb1387 commented 4 years ago

To add to this can arrows (up and down, next to the trash can) be added when looking at the specific mons on an IV list. This would allow us to send mons to the top or bottom of the list without having to drag them to the top or bottom.

sn0opy commented 2 years ago

Is this still needed? I think we could even get rid of IV lists completely

JabLuszko commented 2 years ago

Except (kinda) point 2 it's implemented as all_mons in Area settings.

People still use IV mitm lists for prioritizing iv_mitm or there are some people showing up on Discord from time to time saying they only using it for specific mons because those rattatatas are useless to them (no idea why, but there are) - I would leave the IV list there tbh.