-
-
Notifications
You must be signed in to change notification settings - Fork 3
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
Comments
Could do this via:
|
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
3. Under "Outfits Metrics" table, I'd something similar, but different
|
Having looked into this in more detail, please see the below list of things technically possible and I have comitted to providing:
Yes
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.
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.
Same comments as the point above.
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.
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: 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. |
Ok
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.
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?
Ok
Ok, display it however you think it needs to happen. |
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: Case 2: Case 3: Above cases would handle:
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.
In terms of the scale I suggested, it would scale alongside the population. E.g. if it's a |
Was thinking in the capture history section, a dropdown showing all outfits, a set of bars like this:
|
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. |
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 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. |
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.
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.
Got it.
I have absolutely no idea what this means :) but I assume it's the coding for the 20% threshold?
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.
Very nice thinking. Sounds good to me. Would this add itself to the score-mimick stat or the PFC stat? |
So my proposal is the following: Player / Outfit sections
For example: Players:
Key:
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 historyCapture history will show:
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. |
…ing into a processing queue, with priority support, including better configuration. Implemented delay queues with configurable message TTLs. Update ampqlib deps to latest. #173
Yup
Help me understand these numbers please. 4 confirms what? 8 proximity what? What does a credit signify?
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?
Let's do it. |
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: 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. |
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.
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? |
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.
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.
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. |
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. |
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? |
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. |
Body:
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
The text was updated successfully, but these errors were encountered: