Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement PlayerFacilityCapture / Defend events #173

Open
Maelstromeous opened this issue Oct 8, 2020 · 18 comments
Open

Implement PlayerFacilityCapture / Defend events #173

Maelstromeous opened this issue Oct 8, 2020 · 18 comments
Assignees
Labels
do next Issues needing picking up next enhancement New feature or request p2 Disruptive issues but not show stoppers request Requests from the community

Comments

@Maelstromeous
Copy link
Member

Maelstromeous commented Oct 8, 2020

Body:

character_id: "123456",
facility_id: "12345",
outfit_id: "123456",
timestamp: "123456"
world_id: "1",
zone_id: "8"

So, we can generate a list of players who were present at a particular facility capture. We will need to somehow ensure that the timestamps all line up, which should be possible enough, or we can do a "between" match of a few seconds for capture. Will need to test to see if it matches.

Thinking we should store this as raw events, in addition to an Aggregate for each facility capture totting up each outfit's contribution to said capture.

Related: ps2alerts/api#287

@Maelstromeous Maelstromeous added enhancement New feature or request p3 Minor issues labels Oct 8, 2020
@Maelstromeous Maelstromeous added this to To do in PS2Alerts v3.0 Alpha via automation Oct 8, 2020
@Maelstromeous Maelstromeous added this to To do in Aggregator 3.0 Beta via automation Oct 8, 2020
@Maelstromeous
Copy link
Member Author

Could do this via:

  1. Delay processing of these messages by 3/4 seconds (to give FacilityCaptures time to process)
  2. Create a decaying map of facility captures keyed by FacilityID and hold them for 5 seconds
  3. Create a method of checking said map for any Facility captures, if there is one, associate it with that facility and the exact timestamp / instance
  4. Potentially modify the FacilityControl raw event to have a "Participants" object, which is a list of characters keyed out via FactionID.

@Maelstromeous Maelstromeous added this to To do in PS2Alerts v3.0 Beta via automation Nov 22, 2020
@Maelstromeous Maelstromeous removed this from To do in PS2Alerts v3.0 Alpha Nov 22, 2020
@Maelstromeous Maelstromeous removed this from To do in PS2Alerts v3.0 Beta Dec 26, 2020
@Maelstromeous Maelstromeous added this to To do in PS2Alerts v3.0 GA via automation Dec 26, 2020
@Maelstromeous Maelstromeous self-assigned this Mar 7, 2022
@Maelstromeous Maelstromeous added p2 Disruptive issues but not show stoppers request Requests from the community p1 Show-stopping issues and removed p3 Minor issues p2 Disruptive issues but not show stoppers labels Mar 8, 2022
@Lanzerr
Copy link

Lanzerr commented May 25, 2022

I want to start tracking which players outfits were in the vicinity of a base's capture & defense every alert. The end goal is to boil this all down to an outfit's "Contribution" to an alert displaying a value & percentage on the grand total Outfits statistics table. I imagined this would probably be a formulaic equation of PlayerFacilityCapture against total facilities captured, kills, whatever else is reasonable. But I want to see how the data goes together before I get to that, so let's start at the granular level and take https://ps2alerts.com/alert/1-38388 as an example

1. Under "Faction Combat Metrics" table, I'd like a "Captured" row added that gives the total number of base captures (every base size) per faction for this alert. The same for "Defended" per faction for every base

2. Under "Player Metrics" table, I'd like

  • A new column in the stat table that says "Helped Capture" showing the total # of bases they were in the vicinity of when captured during this alert.

  • A column for "Helped Defend", same as "Helped Capture" but for defends.

  • A column for "Faction Activity %" showing the player's total "helped capture" + "helped defend" divided by the total number of captures & defenses their faction made that alert. I'd like this and the other % calculations to have a "Percentages" and "Numerical" tab buttons if possible.

  • A column that says "Alert Activity %" same as "Faction Activity %" but divided by total number of captures & defenses made that alert by all three factions.

3. Under "Outfits Metrics" table, I'd something similar, but different

  • A new column that says "Captured" showing the total # of bases that the outfit got credit for capturing

  • A column for "Captured for Faction %" showing total captured by outfit divided by total captured by faction.

  • A column for "Captured for Alert %" same as "Captured for Faction %" but divided by total captured by all three factions

  • A column for "Defended" showing the total # of bases that the outfit got credit for defending

  • A column for "Defended for Faction %" showing total defended by outfit divided by total defended by faction

  • A column for "Defended for Alert %" same as "Defended for Faction %" but divided by total defended by all three factions

  • A column for "Helped Capture" showing the bases captured where at least 1 player of this outfit was in the vicinity at time of capture (even if outfit didn't get credit for the capture)

  • A column for "Helped Defend", same thing as "Helped Capture" but for defends

  • A column for "Contributed Capture" showing the number of outfit players within the vicinity of a capture

  • A column for "Contributed Defend" same as "Contributed Capture" but within vicinity of defense

  • A column for "Faction Helped %" showing the total number of players an outfit had in vicinity of a capture % divided total players (outfit & non-outfit) of that outfit's faction that was in vicinity of a capture for the entire alert [see discord message I sent for excel example]

  • A column that says "Alert Helped %" same thing as "Faction Helped %" but divided against total players for all three factions

@Maelstromeous
Copy link
Member Author

Having looked into this in more detail, please see the below list of things technically possible and I have comitted to providing:

1. Under "Faction Combat Metrics" table, I'd like a "Captured" row added that gives the total number of base captures (every base size) per faction for this alert. The same for "Defended" per faction for every base

Yes

2. Under "Player Metrics" table, I'd like

  • A new column in the stat table that says "Helped Capture" showing the total # of bases they were in the vicinity of when captured during this alert.
  • A column for "Helped Defend", same as "Helped Capture" but for defends.
  • A column for "Faction Activity %" showing the player's total "helped capture" + "helped defend" divided by the total number of captures & defenses their faction made that alert. I'd like this and the other % calculations to have a "Percentages" and "Numerical" tab buttons if possible.
  • A column that says "Alert Activity %" same as "Faction Activity %" but divided by total number of captures & defenses made that alert by all three factions.

Yes, however these new stats will be in a sub-table underneath the player's statistics as there will be too many columns, and thus won't be sortable.

3. Under "Outfits Metrics" table, I'd something similar, but different

  • A new column that says "Captured" showing the total # of bases that the outfit got credit for capturing

This already exists for officially owned bases, however "participating in capturing" is a bit of a BS metric, as it'll mean if a single player is present at a capture they'll get contribution. Thought needs to be applied to if there's going to be any kind of threshold for this, otherwise it'll be extremely meaningless. This conflicts with your "Helped Capture" metrics below.

  • A column for "Captured for Faction %" showing total captured by outfit divided by total captured by faction.
  • A column for "Captured for Alert %" same as "Captured for Faction %" but divided by total captured by all three factions

Same comments as the point above.

  • A column for "Defended" showing the total # of bases that the outfit got credit for defending
  • A column for "Defended for Faction %" showing total defended by outfit divided by total defended by faction
  • A column for "Defended for Alert %" same as "Defended for Faction %" but divided by total defended by all three factions

Defences are going to be extremely skewed and inaccurate. Thresholds are commended here as, again, a single player will give a zergfit credit for "defending" a base.

  • A column for "Helped Capture" showing the bases captured where at least 1 player of this outfit was in the vicinity at time of capture (even if outfit didn't get credit for the capture)
  • A column for "Helped Defend", same thing as "Helped Capture" but for defends
  • A column for "Contributed Capture" showing the number of outfit players within the vicinity of a capture
  • A column for "Contributed Defend" same as "Contributed Capture" but within vicinity of defense
  • A column for "Faction Helped %" showing the total number of players an outfit had in vicinity of a capture % divided total players (outfit & non-outfit) of that outfit's faction that was in vicinity of a capture for the entire alert [see discord message I sent for excel example]
  • A column that says "Alert Helped %" same thing as "Faction Helped %" but divided against total players for all three factions

Yes. However, all metrics above will be forced to be within a sub-table, due to the number of columns, and thus not sortable.


I don't agree sub-tables are the ideal implementation because you lose sorting capability, however they are a necessary evil due to the sheer amount of columns you are proposing. There is a challenge I'm now facing with the number of columns, where on mobile the list is unreadable, and on desktop unless you know to "scroll sideways" which some mice don't even support, statistics will be missed. See below for an example of how I've implemented them for the XPM metrics stuff released today:

Screenshot 2022-06-02 at 15 21 34

It is technically possible to make them sortable via using a selector / dropdown (see the Player Leaderboards on the hoepage for an example of that), however it will be quite... jank. I'd have to remove the tradditional sorting ability of just clicking the table header, also then if we sort by an invisible column it would also make even less sense.

@Maelstromeous Maelstromeous added the do next Issues needing picking up next label Jun 2, 2022
@Lanzerr
Copy link

Lanzerr commented Jun 3, 2022

  1. Under "Player Metrics" table, I'd like
  • A new column in the stat table that says "Helped Capture" showing the total # of bases they were in the vicinity of when captured during this alert.
  • A column for "Helped Defend", same as "Helped Capture" but for defends.
  • A column for "Faction Activity %" showing the player's total "helped capture" + "helped defend" divided by the total number of captures & defenses their faction made that alert. I'd like this and the other % calculations to have a "Percentages" and "Numerical" tab buttons if possible.
  • A column that says "Alert Activity %" same as "Faction Activity %" but divided by total number of captures & defenses made that alert by all three factions.

Yes, however these new stats will be in a sub-table underneath the player's statistics as there will be too many columns, and thus won't be sortable.

Ok

  1. Under "Outfits Metrics" table, I'd something similar, but different
  • A new column that says "Captured" showing the total # of bases that the outfit got credit for capturing

This already exists for officially owned bases, however "participating in capturing" is a bit of a BS metric, as it'll mean if a single player is present at a capture they'll get contribution. Thought needs to be applied to if there's going to be any kind of threshold for this, otherwise it'll be extremely meaningless. This conflicts with your "Helped Capture" metrics below.

I was thinking about stipulating that it would only count if the outfit had a minimum number present, but due to today's lower population, it's entirely plausible that in a 1-12 fight, one person in an outfit gets more points than the rest of his/her allies, and while the hex would register that player's outfit as officially owned, an imposed minimum would exclude this from counting. And further, if an outfit running a 6-player squad decided to send all 6 players to separate bases, and each base was a 6-player fight, why wouldn't that outfit get 6 capture credits for contributing 15% of the capture population? I didn't feel it was more important to exclude those scenarios than give an outfit credit for having 1 player at a base. If you have a better suggestion, please share.

  • A column for "Defended" showing the total # of bases that the outfit got credit for defending
  • A column for "Defended for Faction %" showing total defended by outfit divided by total defended by faction
  • A column for "Defended for Alert %" same as "Defended for Faction %" but divided by total defended by all three factions

Defences are going to be extremely skewed and inaccurate. Thresholds are commended here as, again, a single player will give a zergfit credit for "defending" a base.

I think what I said above applies here. Maybe if we get to double the nightly population that we have now, we might consider changing it. Is there a statistic that lists all player scores in the vicinity of a captured/defended hex at the time it's captured/defended?

  • A column for "Helped Capture" showing the bases captured where at least 1 player of this outfit was in the vicinity at time of capture (even if outfit didn't get credit for the capture)
  • A column for "Helped Defend", same thing as "Helped Capture" but for defends
  • A column for "Contributed Capture" showing the number of outfit players within the vicinity of a capture
  • A column for "Contributed Defend" same as "Contributed Capture" but within vicinity of defense
  • A column for "Faction Helped %" showing the total number of players an outfit had in vicinity of a capture % divided total players (outfit & non-outfit) of that outfit's faction that was in vicinity of a capture for the entire alert [see discord message I sent for excel example]
  • A column that says "Alert Helped %" same thing as "Faction Helped %" but divided against total players for all three factions

Yes. However, all metrics above will be forced to be within a sub-table, due to the number of columns, and thus not sortable.

Ok

I don't agree sub-tables are the ideal implementation because you lose sorting capability, however they are a necessary evil due to the sheer amount of columns you are proposing. There is a challenge I'm now facing with the number of columns, where on mobile the list is unreadable, and on desktop unless you know to "scroll sideways" which some mice don't even support, statistics will be missed. See below for an example of how I've implemented them for the XPM metrics stuff released today:

Screenshot 2022-06-02 at 15 21 34

It is technically possible to make them sortable via using a selector / dropdown (see the Player Leaderboards on the homepage for an example of that), however it will be quite... jank. I'd have to remove the traditional sorting ability of just clicking the table header, also then if we sort by an invisible column it would also make even less sense.

Ok, display it however you think it needs to happen.

@Maelstromeous
Copy link
Member Author

I was thinking about stipulating that it would only count if the outfit had a minimum number present, but due to today's lower population, it's entirely plausible that in a 1-12 fight, one person in an outfit gets more points than the rest of his/her allies, and while the hex would register that player's outfit as officially owned, an imposed minimum would exclude this from counting.

I believe understandable (and more importantly, visualised) thresholds need to apply for the stat to be at all relevent. My idea was to take into account the outfit's current player count for the alert (a count of all players playing for that outfit), and create a threshold based off that, rounding down.

For example:

Case 1:
DIG (zergfit) has 50 players playing in the alert. We set the threshold to be 20% of the outfit's total players. This therefore means DIG requires 10 players present at the capture to consider their participation as "legit".

Case 2:
DIGT (1337fit) has 7 players playing the alert. We set the threshold to 20%, this means DIGT requires 1.4 people (rounded down to 1) players to participate in the capture.

Case 3:
EDIM (midfit) has 15 players playing in the alert. We set the threshold to 20%, this means EDIM requires 3 people to participate in the capture.

Above cases would handle:

  • Solofits (they would always get credit due to a minimum of 1 person needed)
  • 1337fits spreading their players around (they would still get credit due to a low minimum)
  • Midfits (likely they're fielding a singular / two squads)
  • Zergfits - preventing a singular person claiming participation when chances are they're just some rando playing solo

Is there a statistic that lists all player scores in the vicinity of a captured/defended hex at the time it's captured/defended?

There is no data available for scoreboards / leaderboards for the game either on a base or even game level via the API. In fact there's very little data in terms of score. Additionally, while we may get Experience tick data, we have no geolocational awareness of where they earned that experience, all we know is X player revived Y person for example.

I think what I said above applies here. Maybe if we get to double the nightly population that we have now, we might consider changing it.

In terms of the scale I suggested, it would scale alongside the population. E.g. if it's a low or a dead bracket alert, naturally the 20% threshold will also apply. Or, we could remove thresholds entirely in those kind of scenarios.

@Maelstromeous
Copy link
Member Author

Was thinking in the capture history section, a dropdown showing all outfits, a set of bars like this:

DIG:  [##|######     ] 31/50 online players present at this base - Credit Given
DIGT  [##|#          ] 3/10 online players present at this base - Credit Given
EDIM: [# |           ] 1/10 online players present at this base - Credit NOT Given
VCBC: [##|##         ] 5/13 online players present at this base - Credit Given

@Maelstromeous
Copy link
Member Author

Maelstromeous commented Jun 3, 2022

In doing some more analysis and research into this, the best method may be to mimick the game's way of calculating scores for the facility leaderboards.

Thanks to some excellent work from some redditors we now have a list of what XP events contribute to score.

Via this method, it's now feasible to make a system which holds the last say 5 minutes of XP events a player has collected, store them temporarily, and when a player is involved in a Facility Capture apply the stored events to the player, generate a score, and from that score then calculate the outfit's contribution and from then on we have our contributors to the capture, based on actual activity (roughly).

There are still some slight holes and caveats where players could still fight for 4 minutes at 1 base then randomly be at another base at the time of capture, but it's much better than just not only going off player counts, but using arbitary thresholds no-one will understand.

I'm now thinking we should take the average score for the faction for the capture, and apply a threshold to that instead, lets say outfits who gain less than 50% of the average won't be included. This means players who were not active during the fight don't get credit (whereas if it was purely presence only based, they would).

This would then turn the metric more from "who had the most numbers on point at the time" to "who actually contributed to the particular base's fight" (mostly). To me, this is vastly better than a simple player counting exercise.

Additonally, since it's a scoring system that the game already uses, it should be pretty familar and will be more widely adopted / accepted by the player base. Addiitonally, because it's score based, it would be much easier to visualize than by introducing arbitary thresholds.

@Maelstromeous
Copy link
Member Author

Maelstromeous commented Jun 3, 2022

Another factor I may have to consider is the "ghost" players - people who leave the base before the PlayerFacility events have a chance to emit. This would be especially prudent for defenders of the base who redeploy from a no-winning scenario. What I may have to do is from the list of players who were actually present at the base, scan their histories to see who they last "interacted" with, and assume they too were present with them on the base.

This then will generate a list of players who "abandoned" the fight. It won't be 100% accurate, but it will likely catch the vast majority of players who left the fight or were simply not in range of the facility boundary (control points need to show up on the HUD to get included in the PlayerFacilityCapture/Defend events). There will be players have interacted with the "captors" who were nowhere close to the fight, but generally it could be assumed that a player who captures a base shot one of the defenders, the captors will have either healed or revived someone who left the base, etc.

Note to self: Checks may need to be added where we must confirm defenders from multiple sources. Can't just assume since 1 captor saw a person that they were absolutely defending that base, ideally we need confirms from at least 2+ people. From there we can generate a more accurate list of ghost defenders. Alternatively, we could use a weighted system where if confirmed defenders (via event) also saw the player as well as the captor, they were much more likely to be present at the base.

@Lanzerr
Copy link

Lanzerr commented Jun 4, 2022

Under "Outfits Metrics" table, I'd something similar, but different
A new column that says "Captured" showing the total # of bases that the outfit got credit for capturing

This already exists for officially owned bases, however "participating in capturing" is a bit of a BS metric, as it'll mean if a single player is present at a capture they'll get contribution. Thought needs to be applied to if there's going to be any kind of threshold for this, otherwise it'll be extremely meaningless. This conflicts with your "Helped Capture" metrics below.

I was thinking about stipulating that it would only count if the outfit had a minimum number present, but due to today's lower population, it's entirely plausible that in a 1-12 fight, one person in an outfit gets more points than the rest of his/her allies, and while the hex would register that player's outfit as officially owned, an imposed minimum would exclude this from counting.

I believe understandable (and more importantly, visualised) thresholds need to apply for the stat to be at all relevent. My idea was to take into account the outfit's current player count for the alert (a count of all players playing for that outfit), and create a threshold based off that, rounding down.

I need raw data. Applying a limiter based on a value judgment of what this stat should show is going to skew the data I need to make calculations. The point of this stat is to track outfit participation in fights. Whether there is 50 outfit players or 1, both give me a picture of how outfits are playing. It's as important to see outfits who aren't playing in large numbers as it is to see outfits that are. If only 1 outfit member is playing in a fight, and this is happening frequently across multiple territories, that's an interesting phenomenon that I want to have the raw data to investigate. I can't do that when you've coded the stat to exclude those scenarios. I need to first see everything this stat can do, then we can narrow down and reset as it makes reasonable sense.

For example:

Case 1: DIG (zergfit) has 50 players playing in the alert. We set the threshold to be 20% of the outfit's total players. This therefore means DIG requires 10 players present at the capture to consider their participation as "legit".

Case 2: DIGT (1337fit) has 7 players playing the alert. We set the threshold to 20%, this means DIGT requires 1.4 people (rounded down to 1) players to participate in the capture.

Case 3: EDIM (midfit) has 15 players playing in the alert. We set the threshold to 20%, this means EDIM requires 3 people to participate in the capture.

Above cases would handle:

  • Solofits (they would always get credit due to a minimum of 1 person needed)
  • 1337fits spreading their players around (they would still get credit due to a low minimum)
  • Midfits (likely they're fielding a singular / two squads)
  • Zergfits - preventing a singular person claiming participation when chances are they're just some rando playing solo

That's a good idea. Instead of applying this threshold to this exact stat, maybe it would be smarter to add duplicate stats and apply multiple thresholds. So for instance, you have a PlayerFacilityCapture that counts everything, then a PFC that counts 25%, 50%, 75%. That way I have my control stat, which I can then test and measure alongside the quartile stats. That would give me some super interesting analysis opportunities.

Is there a statistic that lists all player scores in the vicinity of a captured/defended hex at the time it's captured/defended?

There is no data available for scoreboards / leaderboards for the game either on a base or even game level via the API. In fact there's very little data in terms of score. Additionally, while we may get Experience tick data, we have no geolocational awareness of where they earned that experience, all we know is X player revived Y person for example.

Got it.

Was thinking in the capture history section, a dropdown showing all outfits, a set of bars like this:

DIG:  [##|######     ] 31/50 online players present at this base - Credit Given
DIGT  [##|#          ] 3/10 online players present at this base - Credit Given
EDIM: [# |           ] 1/10 online players present at this base - Credit NOT Given
VCBC: [##|##         ] 5/13 online players present at this base - Credit Given

I have absolutely no idea what this means :) but I assume it's the coding for the 20% threshold?

In doing some more analysis and research into this, the best method may be to mimick the game's way of calculating scores for the facility leaderboards.

Thanks to some excellent work from some redditors we now have a list of what XP events contribute to score.

Via this method, it's now feasible to make a system which holds the last say 5 minutes of XP events a player has collected, store them temporarily, and when a player is involved in a Facility Capture apply the stored events to the player, generate a score, and from that score then calculate the outfit's contribution and from then on we have our contributors to the capture, based on actual activity (roughly).

There are still some slight holes and caveats where players could still fight for 4 minutes at 1 base then randomly be at another base at the time of capture, but it's much better than just not only going off player counts, but using arbitary thresholds no-one will understand.

I'm now thinking we should take the average score for the faction for the capture, and apply a threshold to that instead, lets say outfits who gain less than 50% of the average won't be included. This means players who were not active during the fight don't get credit (whereas if it was purely presence only based, they would).

This would then turn the metric more from "who had the most numbers on point at the time" to "who actually contributed to the particular base's fight" (mostly). To me, this is vastly better than a simple player counting exercise.

Additonally, since it's a scoring system that the game already uses, it should be pretty familar and will be more widely adopted / accepted by the player base. Addiitonally, because it's score based, it would be much easier to visualize than by introducing arbitary thresholds.

Wow. This is brilliant. I think we should do both. Count a raw PlayerCapture as I noted up above, and then count this score-mimick. It's starting to overwhelm my ability to comprehend...I can't picture how this stat would interact with the others. I need an example to know how to integrate this into the statistical architecture we're building here.

Another factor I may have to consider is the "ghost" players - people who leave the base before the PlayerFacility events have a chance to emit. This would be especially prudent for defenders of the base who redeploy from a no-winning scenario. What I may have to do is from the list of players who were actually present at the base, scan their histories to see who they last "interacted" with, and assume they too were present with them on the base.

This then will generate a list of players who "abandoned" the fight. It won't be 100% accurate, but it will likely catch the vast majority of players who left the fight or were simply not in range of the facility boundary (control points need to show up on the HUD to get included in the PlayerFacilityCapture/Defend events). There will be players have interacted with the "captors" who were nowhere close to the fight, but generally it could be assumed that a player who captures a base shot one of the defenders, the captors will have either healed or revived someone who left the base, etc.

Note to self: Checks may need to be added where we must confirm defenders from multiple sources. Can't just assume since 1 captor saw a person that they were absolutely defending that base, ideally we need confirms from at least 2+ people. From there we can generate a more accurate list of ghost defenders. Alternatively, we could use a weighted system where if confirmed defenders (via event) also saw the player as well as the captor, they were much more likely to be present at the base.

Very nice thinking. Sounds good to me. Would this add itself to the score-mimick stat or the PFC stat?

@Maelstromeous
Copy link
Member Author

Maelstromeous commented Jun 4, 2022

So my proposal is the following:

Player / Outfit sections

  1. Add raw "player got capture /defend credit confirmation" stats, as a # of occurrences, as you asked for originally. This will not include "ghosts / proxy confirms".
  2. Add the "score based" capture credit system, and display that too. Thinking of showing three numbers for the display of this, e.g. "4|8=12", and informing the user that means "4 confirms, 8 "proximity" confirms equaling 12 credits"
  3. Add an average of the score system values as a displayed metric

For example:

Players:

| Name                | PFCs | PFDs | SB-PFC  | SB-PFC score | Avg SB-PFC score |
|---------------------|------|------|---------|--------------|------------------|
| [DIG] Maelstrome26  | 4    | 7    | 4|10=14 | 20,340       | 2,167.48         |

Key:

  • PFC = Player Facility Capture (player was confirmed to be in control point HUD range)
  • PFD = Ditto for defends
  • SB-PFC = Score Based PFC, last 5 minutes of score is used. Represented as confirms|proximity=total

So essentially we'd have two flavours of the PFC stat, one where it's just the raw values and that's all, another with the score system.

This would look slightly different for outfits, where I'd add some per participant averages as well.

Under both each player and each outfit, I will display their associated captures, along with their contributions and their eligibility to said capture in a more detailed manner.

Capture history

Capture history will show:

  • Population bar, with each faction having two segments:
    1. A "solid" segment with confirmed (via PFC data) players
    2. A "nearby" segment with players found via the system of interaction based discovery
  • List of captors, each showing their score based stats for contribution to the capture
  • List of defenders, again showing their score based stats

I'm thinking this would look rather cool as then we would, in theory, have a snapshot of the fight itself and how busy it was. We could also use the score based data to create a "heatmap" of fights, adding to the map itself as a overlay like you can do in game for populations for example.

Maelstromeous added a commit that referenced this issue Jun 5, 2022
…ing into a processing queue, with priority support, including better configuration. Implemented delay queues with configurable message TTLs. Update ampqlib deps to latest. #173
@Lanzerr
Copy link

Lanzerr commented Jun 6, 2022

Player / Outfit sections

  1. Add raw "player got capture /defend credit confirmation" stats, as a # of occurrences, as you asked for originally. This will not include "ghosts / proxy confirms".

Yup

  1. Add the "score based" capture credit system, and display that too. Thinking of showing three numbers for the display of this, e.g. "4|8=12", and informing the user that means "4 confirms, 8 "proximity" confirms equaling 12 credits"

Help me understand these numbers please. 4 confirms what? 8 proximity what? What does a credit signify?

  1. Add an average of the score system values as a displayed metric

For example:

Players:

| Name                | PFCs | PFDs | SB-PFC  | SB-PFC score | Avg SB-PFC score |
|---------------------|------|------|---------|--------------|------------------|
| [DIG] Maelstrome26  | 4    | 7    | 4|10=14 | 20,340       | 2,167.48         |

Key:

  • PFC = Player Facility Capture (player was confirmed to be in control point HUD range)
  • PFD = Ditto for defends
  • SB-PFC = Score Based PFC, last 5 minutes of score is used. Represented as confirms|proximity=total

So essentially we'd have two flavours of the PFC stat, one where it's just the raw values and that's all, another with the score system.

So this would show that you were in vicinity of 4 captures, 4 defends, got 14 credits (I'll know what this means when you explain up above), which totaled 20.3K points, and your average score per capture/defend was 2.1K.

Yes?

This would look slightly different for outfits, where I'd add some per participant averages as well.

Under both each player and each outfit, I will display their associated captures, along with their contributions and their eligibility to said capture in a more detailed manner.

Capture history

Capture history will show:

  • Population bar, with each faction having two segments:

    1. A "solid" segment with confirmed (via PFC data) players
    2. A "nearby" segment with players found via the system of interaction based discovery
  • List of captors, each showing their score based stats for contribution to the capture

  • List of defenders, again showing their score based stats

I'm thinking this would look rather cool as then we would, in theory, have a snapshot of the fight itself and how busy it was. We could also use the score based data to create a "heatmap" of fights, adding to the map itself as a overlay like you can do in game for populations for example.

Let's do it.

@Maelstromeous
Copy link
Member Author

Maelstromeous commented Jun 6, 2022

Help me understand these numbers please. 4 confirms what? 8 proximity what? What does a credit signify?

So confirmed means that the player was confirmed to be at the base at the time of capture via the PFC event.

Proximity is players who have recently interacted with those people who were confirmed at the base within the last 5 minutes. This applies to both captors and defenders. This will therefore give us more of a picture of those players who leave the base early or were quite simply just not in range of the capture point radius where it shows up on your HUD. I'm going to require a player be seen by at least 2 confirmed players before they're counted.

Example:
Maelstrome26 (captor and PFC confirmed) killed players Bob and Doug within the last 5 minutes. Bob was also a confirmed defender via PFC. Doug was not confirmed via PFC. Doug is yet to be counted as a proximity defender as his involvement has yet to be confirmed.

Player Bob (confirmed defender) killed no one but revived Doug at some point during the last 5 minutes.

Therefore Doug is now a proximity defender as he was confirmed to be around by two confirmed players.

To make the proximity capture thing a bit more accurate, I'm only going to enable people to be considered a proximity participant if they were confirmed by two players directly confirmed via PFC. However that confirmation will be determined by any players who were confirmed, regardless of faction.

@Lanzerr
Copy link

Lanzerr commented Jun 8, 2022

I'm going to require a player be seen by at least 2 confirmed players before they're counted.

Two questions here: 1) Are you requiring this for my control PFC stat? 2) What about exceptionally talented infil snipers who are not seen but assassinate loads of players before it captures/defends.

To make the proximity capture thing a bit more accurate, I'm only going to enable people to be considered a proximity participant if they were confirmed by two players directly confirmed via PFC. However that confirmation will be determined by any players who were confirmed, regardless of faction.

That makes reasonable sense to me. Why two though? Why not one?

Does "q" spot but not interacted with (revived/killed/etc) also count as being seen? Is this affected by the counterintelligence implant?

I can think of a scenario armor team of 6 on the spawn side of Eisa who are guarding the spawn shield door and never see or engage an enemy because no one has pulled or gone to that side. Base captures, are the 6 armor players counted?

@Maelstromeous
Copy link
Member Author

Maelstromeous commented Jun 8, 2022

  1. Are you requiring this for my control PFC stat?

No. As stated there will be a raw "confirmed" stat which is purely just those seen by the PFC/D events and a proximity stat for those seen via interactions with confirmed people.

  1. What about exceptionally talented infil snipers who are not seen but assassinate loads of players before it captures/defends.

If they shot someone who was confirmed to be there within 5 mins, they will be counted as a proxy.

There are however always going to be edge case scenarios and inaccuracies, despite how much thought we put into it, in the absence of official data from Census. I'll be advertising the stat as "a rough guess so take it with a pinch of salt". My aim is to get it around 80% accurate.

Why two though?

Simply put, increased accuracy. The chance of a player interacting with a singular confirmed player nowhere near the fight (e.g. the confirm redeployed to the fight from another base) is quite high. However the chance that two players have interacted with them at two different locations is much much lower. Therefore, they will need to be confirmed by at least two players at the confirmed same location as them in order to be counted.

Case scenario #1:

Maelstrome26 on VS redeploys from The Octagon to Allatum which has 2 minutes remaining to be captured by TR in order to defend it.

Maelstrome26 gets utterly wrecked and redeploys before the base is captured (thus, not eligible for PFD event). However in this time they killed 3 captors and got revived twice by 2 players who remained. All 3 captors remained on the base and thus got PFC events.

Maelstrome26 would be awarded a proxy defence credit due to being confirmed present by the 2+ captors who were also present at the base.

Case scenario #2:

MrBigs (TR) is sniping on the outskirts of Cobalt Geological of which VS is capping, not within HUD range and thus not eligible for a PFD event. He snipes 10 people in the space of 5 minutes. 2 of those people received PFC events.

MrBigs gets PFD proxy credit as they were confirmed to be in the area the players were killed in, within the last 5 minutes.

This ignores the other 8 players who cannot be confirmed being on the base itself. Rather than doing a search of all players who were involved with proxys of proxys, which in some cases might be legit, I'm narrowing it to purely interactions with confirmed players only, as that's the only basis we have to go on that someone was present at the base at the time.

Where this falls down is long base timers where either the fight has been raging for a long time and some players who legitimately helped capture/defend the base are not counted as they've left the area in the last 5 minutes, or ghost caps with little to no activity. I'm in the opinion that the latter is still correct as those kinds of base captures are a bit scummy anyway and shouldn't be awarded. Chances are anyway ghost cappers will be fairly close to points and will get counted via PFC events anyway.

@Maelstromeous
Copy link
Member Author

Does "q" spot but not interacted with (revived/killed/etc) also count as being seen? Is this affected by the counterintelligence implant?

I don't believe we have a XP event that says you "spotted X player", like the "you revived X person" events we do have... just a "you spotted someone" event. I'll have to investigate all the event types and understand which ones we can use to attribute players to other players.

@Lanzerr
Copy link

Lanzerr commented Jun 12, 2022

I'll be advertising the stat as "a rough guess so take it with a pinch of salt". My aim is to get it around 80% accurate.

I don't have an opinion for how you advertise it, but keep in mind that I won't be taking this stat with a punch of salt. It will very much be the backbone of the stat interpretations I do I give my "Largefits, Midfits, Smallfits" podcast talk. What would it take to get it 90% accurate?

@Maelstromeous
Copy link
Member Author

A miracle or DBG actually supplying us with both ends of the fight per facility event.

@Lanzerr
Copy link

Lanzerr commented Jun 13, 2022

A miracle or DBG actually supplying us with both ends of the fight per facility event.

Lol...whelp. Then 80% is the best we can do then. That'll have to be enough.

@Maelstromeous Maelstromeous added p2 Disruptive issues but not show stoppers and removed p1 Show-stopping issues labels Apr 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
do next Issues needing picking up next enhancement New feature or request p2 Disruptive issues but not show stoppers request Requests from the community
Projects
Status: In Progress
Development

No branches or pull requests

2 participants