Incorrect handling of pll GET parameter

[l1bbcsg]

IITC does not set the view to pll GET parameter if launched with it and thus does not highlight the portal if ll parameter does not point to its location too (or not provided at all).

For example, https://www.ingress.com/intel?pll=37.791541,-122.390014 in Intel will set map view to the portal and select it. In IITC it will open the map with whatever view it had before and won't highlight the portal (unless it happened to be in the view).

Intel evidently works the following way and IITC should probably too:

• If neither pll nor ll are provided, open the map with its previous view and no portals selected
• If only ll is provided, open map with corresponding view and not select any portals
• If only pll is provided, snap the view to its coordinates, and select the portal they point to. IITC fails this
• If both pll and ll are provided, ignore ll and use pll as described above

The latter however may be modified for greater flexibility as following: If both are provided, open view at ll, select portal at pll. Which is what IITC currently does.

[flamusdiu]

Look at this merge request: https://github.com/jonatkins/ingress-intel-total-conversion/pull/923

Might be partly fix this if it gets merged.

[Fragger]

923 will fix this besides the last bullet which I don't think needs to be done

[nexushoratio]

I've been using #923 in my local version of iitc for a while now and am happy with it.

[nexushoratio]

Ping?

A reasonable fix is already available as a PR from a long time contributor. Sure would be nice to at least be compatible with stock Intel.

[nexushoratio]

If there was a way for me to edit the $SUBJECT of this issue, I would change it to say:

IITC does not respect pll parameter when it is the only parameter.

I wonder if the current title makes it seem like a bogus issue (since IITC obviously does respect it when ll is also present).

[l1bbcsg]

It does handle it differently from intel in all cases though. If it's about the wording, I used "does not respect" as weaker form of "ignores", which is the case when it's the only parameter, but not entirely true when both are present (I may be wrong though, English is not my native language) Anyway, renamed it to something bit more generic, but I think it's not the real problem here as the issue is open and not even responded by maintainers for two months (and a pull request for 3), not sure rewording title would help that.

[dingram]

923 merged.