also reordered munge list to match the order found in the stock page (makes it easier to update) and tweaked the code that detects and auto-tries munge sets
- get mods from portal details, filtered by type and sorted by strength
- get mitigation values
TODO: convert existing plugins to use these new functions
this gives a simple method of expiring entries. also, prevents localStorage from filling up with thousands of player names over time
(ideally something controllable with configurable age should be used, but this was a quick and simple change to try first)
the existing idle resume function can be used on returning to iitc
also, fix the long-standing bug on mobile where the map disappears after repeated touch panning/zooming. seems leaflet gets confused about zoom levels and ends up with a non-ingeger. when this is found, force it back to an ingeger zoom level when this happens
note: need to add code to hide short links from the map - and update the shown/hidden links after a zoom
(similar to the portal cluster showing/hiding portals after a zoom)
now only some portals are drawn to the map it's OK to bring them all to front at the end of the render
use larger squares for portal clustering on mobile - as the portal markers are larger
- delay briefly before retrying a timeout, and a bit longer before other errors
- also delay briefly before running the queue after a request, to give a chance of more than one request's requeued entries being handled atr once
- add a min tiles per request, to avoid sending multiple requests when only a few queued items remain
these are attempts to be nicer to the niantic servers, particularly in error cases, with some based on my best guess of the stock site behaviour, and others based on what seems reasonable to me
- ensure the selected portal isn't deleted when it isn't in the map data (e.g. due to zoom level)
- always show the selected portal on the map, even if the high density clustering code would have removed it
- deselect the selected portal, and clear the details bar, in the rare instance of the portal being deleted server-side (i.e. in the deletedEntities list)
- fix idle resume, so it only occurs if the existing timer has been cancelled
- re-instate the cache, and updates for interface changes
- add a short delay between the initialisation of map data retreival, and actually starting network requests
the original reason for longer term storage were the frequent error==TIMEOUT from map tiles. since these are now retried, as the stock site does, the remaining use for the cache is more short term, while panning around an area
Subtle, but it's driven me crazy in the past where seemingly reasonable
searches do nothing and "worked - but found nothing" and "maybe it's
just taking a second to work" aren't apparent.
