Incorporating Ornaments and Targets

[Yeggstry]

This is primarily for anomaly events, where the scoring is affected by this data.

Ornaments would have to be derived from the Intel map, extracting the data from the getEntities and getPortalDetails calls. This may take a few minutes to extract and provide in a similar format to the processed data i.e. portal number, lat/lng, title, but I believe it is possible.

Targets are provided in the shard jump data, but only at the point where they are visible within the game - there is no history of the targets in a similar fashion to the shards. As I was viewing Sao Paulo a few months ago I was able to get a copy of the shard jump data at each wave so providing the targets for that site would be possible, but a longer term solution would be required that doesn't involve as many manual steps!

I was thinking about a Shards Map IITC plugin, which has a copy of the series metadata and / or geocode, so knows which events are happening and what data it should be able to see on the map, so it could extract the data from the intel in real time and store it, ready to be saved and included in this project.

These are all thoughts I'm having after the latest tranche of changes to the map, and I'm trying to get these out so I can come back to it in the New Year and take a break! 🙈

[Yeggstry]

After working through the possibile setups that we could use moving forward, I decided to create individual repos rather than a monorepo. To help keep these together in one place I've created a new organisation to keep things tidy: Ingress Shards. This currently contains two repos at this time:

• shards-core - Core logic for Ingress applications which interact with shards, written in Typescript. Currently this includes only the date and math utils which are in the shared folder in the shards map repo, but the intention is to move some of the logic that is in the shards map repo into this central location so that it can be used by the shards map and the iitc plugin. I don't know which functions will be included at this point but likely the data functions would be useful. This is released as a GitHub Package which anyone with a GH personal access token can use.
• iitc-plugin-shards-observer - Observes and records shard data from the Ingress Intel map, also written in Typescript. The first version is just an outline at this point, but was a useful independent project to help with versioning and the release process without cluttering up the shards map repo.

I wanted to keep the Shards Observer plugin development separate from the shards map whilst it is in development, and the only changes I've made to the shards map for this is to make the config available - releasing a new plugin version every time the config changed seemed excessive for users of the plugin, but I am open to suggestions for how to handle this.

Once the Shards Observer plugin and shards-core are more mature, we can look at what level they can be coupled with the shards map project. This can include:

• Export function in the plugin to a file to be included in the shards map data folder - this is the most logical approach and the first file export is likely to be ornaments, which should be fairly straightforward to incorporate - the generated processed series data would include all portals with ornament ids included, and the ui would be updated to allow for ornaments to be turned on and off independent of other data shown i.e. waves.
• Include shards-core as a dependency in shards-map and remove duplicate code.
• Move shards map into the ingress-shards organisation, change the repo name to shards-map, the package.json name from ingress-shards-map to @ingress-shards/shards-map . This is the most intrusive and likely to break existing links as the likely GitHub Pages URL would be https://ingress-shards.github.io/shards-map/

I wanted to lay this out as a possible direction moving forward; whilst this does include quite a few changes, my primary interest is to ensure that the functionality is available to provide as accurate a view of the shard events as possible, whilst keeping a reasonably clean and maintainable codebase. I don't want to be overbearing about how things are done but put my thoughts down 😃

[neon-ninja]

Sounds good to me - could I please get an invite to https://github.com/ingress-shards? Then I can transfer this repo over to there

If the repo is named ingress-shards.github.io, the resulting GH pages URL would just be https://ingress-shards.github.io/, which is shorter

I can add a redirect from https://neon-ninja.github.io/shards/ -> https://ingress-shards.github.io/ so existing links still work

[Yeggstry]

Sorry for not picking this up sooner! I've invited you as an owner of the organisation.

Changing the repo to that name makes complete sense, I didn't realise that you could name it in that manner but does make it simpler. I'll have to do some testing to see if it has an impact on any other URLs but those are downstream additions that can be changed.

[neon-ninja]

Transfer complete 👍