Open nexushoratio opened 3 weeks ago
Because of the requirement to have a Lightship Developer account, it is better that it be a third-party plugin
As a counter point:
The sync plugin requires a Google account. If that plugin was proposed today, would you have the same opinion?
(Obviously, it is a special case since Ingress started internally at Google and required a Google account, so it made sense back then.)
Imho the point wasn't about the account, but rather about its purpose. Lightship should be used by developers, not by players.
Yeah, we all know how it is since it's enough to create some account without any proof of the "developer" part, but including such a plugin in core IITC could bring more people/players there - which I guess NIA really don't want.
What about a "Bring Your Own URL" feature that could take a handful of tokens that get replaced?
For example, in Python I might do an f-string like:
f'https://example.com/path/to/resource?ll={lat},{lng}&z={zoom}&g={guid}&label={title}'
Alas, I don't think that JavaScript
Oh, MDN suggests that JS can do nested templates, so maybe such a feature would be possible without manual parsing of the template.
That sounds interesting. Maybe you could define multiple URLs for different tools and have those buttons appear in portal info and such.
But I'd say this is certainly something for community plugins, not for the core plugins.
But I'd say this is certainly something for community plugins, not for the core plugins.
Is there documentation about how to maintain a community plugin? I see https://github.com/IITC-CE/Community-plugins/blob/master/CONTRIBUTING.md, but I'm not sure how write and build a plug in outside of forking IITC and dropping it into the plugins directory.
I suppose I could add a cp
to the pre_build
list. But I feel like I'm missing something official.
(I don't use tg, hence asking here :-)
I'm not sure how write and build a plug in
https://github.com/IITC-CE/ingress-intel-total-conversion/wiki/Your-First-Plugin This article may be useful to you
Come to TG, the whole ingress is there including us 😉
But to answer...
This is pretty much up to you. It's enough to have the js file available somewhere. It just needs to be a proper userscript. Imho some people really write them as a single file with all the header comments in vanilla JS, others use typescript with some build... there's so many options 😉 There's also this kit for example - https://github.com/McBen/IITCPluginKit
Maybe you can start with a simple js file, or explore repositories of others (don't look at mine, it's a mess ðŸ¤)
Oh, MDN suggests that JS can do nested templates, so maybe such a feature would be possible without manual parsing of the template.
Now the list of links of the "Map links" dialog is generated in the function window.showPortalPosLinks
I'm just refactoring that file https://github.com/IITC-CE/ingress-intel-total-conversion/pull/773 and you gave a good idea to allow plugins to easily extend the list of such links. Now the plugin has to interfere with the function and rewrite the code of the displayed links, but it would be better to put them in a separate array
I had looked at a few, but still garnered no clue. That's why for my personal projects, I just used the whole code base (https://github.com/nexushoratio/ingress-intel-total-conversion/tree/explore)
I'm just refactoring that file #773 and you gave a good idea to allow plugins to easily extend the list of such links.
I know it says "this PR is big enough" but....
I just noticed that sync.js uses a custom made generateUUID()
rather than crypto.randomUUID()
. I did not look to see how compatible they are, but might be a good polyfill candidate (or just say, not support browsers older than 2022... not sure what the policy is on that front).
Would you all be willing to take patches to enhance the build system to enable additional directories for plugins?
Personally, I've always like the dead simple way that the IITC stuff build, and would prefer to continue to use that method. But, if I could say, register extra plugin directories in localbuildsettings.py
and plumb that all the way through, that would be cool
Stretch goals could include also registering a path to a Community Plugins repo to copy the resulting files to. (not needed, but maybe push user.js
back to originating directory)
If so, I'd write up a new issue for such a thing.
What about a "Bring Your Own URL" feature that could take a handful of tokens that get replaced?
That's somewhat close to my plugin share-by-coords
That's somewhat close to my plugin share-by-coords
Out of curiosity, is there any drawback to adding some of these to the Community Plugins?
Would you all be willing to take patches to enhance the build system to enable additional directories for plugins?
I think what you want is already possible. Try this command
./build_plugin.py local plugins/tidy-links.js --out-dir build/example --watch
That's somewhat close to my plugin share-by-coords
Out of curiosity, is there any drawback to adding some of these to the Community Plugins?
None, I just didn't take the time to do it.
The
Map links
currently supports Google, Bing, and OSM maps.Would supporting Niantic's own site be of interest?
The URL appears to be: https://lightship.dev/account/geospatial-browser/{lat},{lng},{zoom},,{guid}
Where, are the center of the map (which may or may not be the portal), standard map zoom, and guid of the portal.
For example: https://lightship.dev/account/geospatial-browser/37.423521,-122.089649,20,,09d5d1e149014c70ba3154fe3421e2a6.12
One problem with this is for it to be usable, one much actually have a Lightship Developer account.
On the other hand, it is a great way to see information like the description without having to switch over to the Scanner. And other details like VPS status.