Closed k3nsanders closed 1 year ago
I think this would be great as well! I need to look into how feasible it would be to get current fireteam status - but I know that even if we can get who is in your current fireteam, we won't be able to get stats about the current activity until it's over (yet). That'll require some more involved infrastructure improvements: ones I'd like to see happen, but I have to admit I don't know if it'll ever be something that will be able to come to pass. (there's a lot of work that'd have to happen both on the API side and the game side itself to make it possible, and the game teams in particular are swamped with game work!)
But I may at least be able to get you current Fireteam... I need to look into that, it may be possible. I'll mark this as up for investigation at the moment. Thanks for the suggestion!
This would be amazingly handy. Depending on which platform your working on, sometimes you can use data from the current fireteam to then hit one of the XBL/PSN/PC services and see what they report at the current activity. Generally you can get the same data as you would see in your friends list, so if you could chain that data together you'd likely have enough to construct a pretty accurate picture of what everyone was doing.
If there's any chance of getting fireteam data there are a lot of other cool opportunities as well for stream overlays, dashboards, etc. :D
Definitely! I dig it! I'll see what can be done - I'm not actually sure offhand if the parts of the system that we do have connectivity to know this information, but when I get some time I'll look into it. (I feel a strange sense of deja vu... I may have looked into this back in D1 and found it didn't, but we'll see what the situation is today at least)
I'm going to put this on Santa's wish list.
Hey, I appreciate the response! I had a funny suspicion that you were going to respond as you did with regards to information pertaining to the current activity itself (kills, deaths, etc.). It’s not surprising at all and I can appreciate the situation. This all started with me wanting to make a web-based overlay for my Destiny 2 stream to show information about my current fireteam. It would be super cool if this were to be implemented, but I know what it’s like to be a developer with only two hands, so I wish you luck! Thanks again, look forward to watching this one in the future.
This indeed would be very cool!
Personally, I would like to see this as part of the Destiny2.GetChracter endpoint with a new component type (maybe say 600 = CurrentFireteam).
I would envision the response to be something like this below. You could make use of the existing destiny user objects.
For example if I were execute https://www.bungie.net/Platform/Destiny2/1/Profile/4611686018429681104/Character/2305843009261332945/?components=600 maybe I would get something like this to represent a fireteam of 3 in a Vanguard Strike.
{
"Response": {
"currentFireteam": {
"directorActivityHash": 1984315274,
"entries": [
{
"player": {
"destinyUserInfo": {
"iconPath": "/common/destiny2_content/icons/ba127a92c13cef64c11b803efeefef23.jpg",
"membershipType": 1,
"membershipId": "4611686018429681104",
"displayName": "xlx CLU xlx"
},
"characterClass": "Titan",
"characterLevel": 20,
"lightLevel": 282,
"bungieNetUserInfo": {
"iconPath": "/img/profile/avatars/CarnageZone.gif",
"membershipType": 254,
"membershipId": "12360",
"displayName": "xlx CLU xlx"
}
},
"characterId": "2305843009261332945"
},
{
"player": {
"destinyUserInfo": {
"iconPath": "/common/destiny2_content/icons/15f6e21a184429bb48cf071dc0893852.jpg",
"membershipType": 1,
"membershipId": "4611686018429591541",
"displayName": "Aces Charles19"
},
"characterClass": "Hunter",
"characterLevel": 20,
"lightLevel": 288,
"bungieNetUserInfo": {
"iconPath": "/img/profile/avatars/avatar29.jpg",
"membershipType": 254,
"membershipId": "4747413",
"displayName": "Aces Charles19"
}
},
"characterId": "2305843009262188131"
},
{
"player": {
"destinyUserInfo": {
"iconPath": "/common/destiny2_content/icons/ae97b9d545f5b40fc15df3b8f42b754d.jpg",
"membershipType": 1,
"membershipId": "4611686018440179600",
"displayName": "A1 Excalibur"
},
"characterClass": "Hunter",
"characterLevel": 20,
"lightLevel": 266
},
"characterId": "2305843009265637524"
}
],
"ErrorCode": 1,
"ThrottleSeconds": 0,
"ErrorStatus": "Success",
"Message": "Ok",
"MessageData": {}
}
}
}
I dig it - we'll see what if anything can be done! I'm hoping that in December I'm going to get a bit of time to dig into these desirable enhancements (along with fixing a lot of long-put-off bugs in this backlog), so hopefully we can make this come to pass!
Digging through some old forum topics here is what I could find on this topic:
Players in (current) Activity Endpoint possibility?
I swear I remember this appearing at least twice though...
Edit: #151 is relevant as well
Yeah, for sure current activity details: things like kills, deaths, health/shield status, position in the world, etc... won't be accessible to us without some significant new infrastructure that allows us to get at that information. What I'm not certain about at the moment is whether we can at least get at the Fireteam: I feel more hopeful about that, but I will have to investigate!
Hmm, and when it comes to what specific activity you're playing (referred to by that forum post), we should already have at least that data, albeit just for a single user at a time: that's in the DestinyCharacterActivitiesComponent - try that out if you're looking for the activity and activity mode you're playing!
Fantastic. Thanks as always.
I took a little more time to look into getting current Fireteam information: the change we'll need to make is a bit deeper than the BNet level, so I'm going to have to fit it into a game release (which means it won't be coming in the early February improvements), but after researching that it was possible I did enter a request into the game triage pipeline to get permission for including it in a future release. Pending approval of that, we'll see it in the future - unfortunately a bit more distant of a future than I would have liked, but it's on the table now and I know it is indeed in a place where we can reach it. So good news, just not good news for February. ;)
Regardless of timeline, having this available via the API would be an AMAZING thing to have at our disposal. Right now running through various unofficial platform APIs and mashing those results together with activity reports is the way I've messed with this effort in the past. Having any kind of access to the current fireteam would be such a cool addition and well-worth waiting for, IMO. Thank you for looking into this!
Woot! No prob, I'll keep you all posted when it finally gets closer to release ready!
Signing up for this one. Being able to access stats would be great!
Will this mean that we'll be able to create realtime glimmerfarming-tournaments using streamingservices on our websites?:D
Ha! Well yes I suppose ;)
Hey @vthornheart-bng - I'm unsure on what the progress is on this one (and I understand and agree that it's much lower priority compared to recent Forsaken work 😂), but even if fireteamId would be easy to expose in DestinyCharacterActivitiesComponent, that could solve some of the use cases for this. For example, for clan.report, I would like to show if clanmates are playing together. If I had a currentFireteamId for everyone, that could be used to figure out whos playing with who.
Would love to be able to access this info! Any idea if this will be coming soon?
Good question! In the Winter wishlist, I classified it as "Doubtful if feasible at this time - needs investigation". The last time I checked on this toward the end of Destiny 1, it wasn't feasible for us to access this data without significant infrastructure work (integrating with a different set of servers from those that the API currently has access to). I am 90% sure this hasn't changed since the last time I checked, but I haven't dug into investigate yet. However, I feel very un-hopeful about it: to get this data is going to require a significant investment in our backend that I don't think anyone's prepared to make yet.
But those of you who want this information, please keep posting here: and if you can, mention what you'd plan to use it for! I can point our designers and other decision-makers at this thread as evidence that the resources required to get this data could be worthwhile!
Still hoping it can happen someday. I mentioned this in the winter wishlist, but I’ll add it here just for posterity:
This would enable so much useful functionality, such as looking up opponents in real-time while loading into a competitive or Trials match, etc.
I know Trials Report was forced to just assume that your fireteam for your previous game was still with you for the next game, which is a pretty safe assumption for trials, which had no matchmaking. But in the competitive playlist, that assumption doesn’t hold as true, so this functionality would make a huge difference in the reliability and usability of real-time opponent lookup sites.
It would also make it easier to build functionality to check stats for everyone in your current fireteam before diving into challenging PvE content like a raid, so you can see at a glance who might need extra help or explanation, or who might not have the right loadout equipped etc.
In summary, IMO it’d be a huge change that would enable lots of really cool new types of third-party functionality.
^ I second all of those, specifically around getting information for your current teammates in a long-form PvE event. I'd love to see streamer overlays that had information about more than just their stats - think Destiny 2 Armory Overlay but for pertinent info about your team! 🤤
This is functionality that we had hoped to leverage for Raid Dad. We have worked around it by implementing manual fireteam building, but it has limitations:
With an endpoint that provides the current fireteam for a given player, Raid Dad could be streamlined down to simply logging in (or manually entering a player tag), at which point the player's current fireteam is retrieved and populated in Raid Dad. Then automatically updated if fireteam changes occur.
Any update on this one? It would by far be the most useful feature to get added. Trying to build up the current fireteam from activity history is painful and error-prone : (
Hmm, okay so let's say that we could theoretically get you Fireteam info, but:
1) It was potentially up to ~60 seconds old 2) If the user logs off suddenly or is disconnected, it may still appear as if they're in that Fireteam
Would that information still be useful to you?
Yes, that would still be awesome.
On Tue, Aug 20, 2019 at 1:54 PM Vendal Thornheart notifications@github.com wrote:
Hmm, okay so let's say that we could theoretically get you Fireteam info, but:
- It was potentially up to ~60 seconds old
- If the user logs off suddenly or is disconnected, it may still appear as if they're in that Fireteam
Would that information still be useful to you?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Bungie-net/api/issues/307?email_source=notifications&email_token=AABVGF5WYS3IJCFYXT3DCIDQFRKYRA5CNFSM4EEMEGW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4XUCMI#issuecomment-523190577, or mute the thread https://github.com/notifications/unsubscribe-auth/AABVGF2PYIQXTTQR2CVKY7LQFRKYRANCNFSM4EEMEGWQ .
Sweet, because I think we may actually have a path to get you that data, with those unfortunate caveats.
I will look into it and see if I can release it as an experimental feature.
That is still 100 times better than the current situation, so +1 in my book :D
It was potentially up to ~60 seconds old
I assume this also means that it may take that length of time after a player joins a fireteam for this new endpoint to have that information? Meaning, the response may be incorrect for up to a minute?
If the user logs off suddenly or is disconnected, it may still appear as if they're in that Fireteam
Is this a product of the prior caveat? E.g. after ~60 seconds it will properly reflect?
This sounds usable to me, for sure. I think players generally expect some delay when interfacing with any tool that uses the bnet API. 60 seconds is longer than normal, but not a deal breaker.
Hmm, okay so let's say that we could theoretically get you Fireteam info, but:
- It was potentially up to ~60 seconds old
- If the user logs off suddenly or is disconnected, it may still appear as if they're in that Fireteam
Would that information still be useful to you?
For sure, those limitations are very manageable. Hearing that this might actually come to fruition finally is incredible news!
@nathanhosselton Indeed on the first case: the response may be incorrect for up to a minute if they join a fireteam or swap fireteams. This is a consequence of two things: (1) some necessary caching between us and the game side, and (2) pulling this data from a non-authoritative source of information, which appears to be the only info we may be able to access from the API. (I stress may - I need to do some further testing on this)
For the second question, the root of the problem is actually in where we source the data. It's not an authoritative source: it's basically "what a specific type of server in our infrastructure saw as the last true state". But that nonauthoritative state doesn't necessarily get cleared out once you end your gaming session. It may, but it is not guaranteed to - and you can see some properties in the API that behave similarly due to this same reason.
I'll try not to get your folks' hopes up too much - I'm not sure how crappy this data and these limitations will be to use in practice. I always feel a bit hesitant returning this non-authoritative data. But if it's good enough for some interesting features, then at least that's better than nothing.
But that nonauthoritative state doesn't necessarily get cleared out once you end your gaming session.
Ah yeah was worried about that. Still, we will already have the player's current online status at that point. So it's a simple additional logic check from there to ensure we're not getting fooled by the hanging state.
As long as the experimental endpoint is well documented with its caveats and, where possible, workarounds (such as the above), I'd say it's fine. We can make better features with this, even if they're slow.
Sweet, good stuff. Ah yeah, and good call on that with the online state - I can do the same on our side I believe just so we don't return data we absolutely know to be false. I'll look into that - still won't help the lag, but it's something.
Yeah, even with those caveats and limitations, it would be a huge improvement over what we have now, which is basically to look at who they were teamed up with in their previous activity and hope it’s still the same fireteam. That method is pretty ineffective for any activities that have matchmaking turned on, which of course is almost all of them. So this would be a huge help, even if it’s imperfect.
Sweeet, good deal! I'll see what we can do!
Okay, here's the gameplan. We're going to introduce a new component - DestinyComponentType.Transitory - that will provide data that we consider to be non-authoritative but that potentially has useful data. I'm basically going to dump all this transitory data out with the caveat that we can't guarantee anything about it in hopes someone gets some use/fun out of it!
Requesting it will return a new profileTransitoryData property on DestinyProfileResponse.
It will have the following data, and none of it we'll be able to guarantee absolute canonical accuracy or timeliness:
Party Member data, though only displayName, emblemHash, and account ID. We can't get the character ID, and it'd be too expensive for us to look up all your party members every time someone requests profile data in order to get it. (this transitory data, unfortunately, didn't have it! Boo) Hopefully this will be sufficient - if you absolutely need the character ID, you can hit us separately for them but please avoid it unless your use case absolutely requires it.
current activity, if they're in one/if this data thinks you're in one, which will have the following. None of these should be considered canonical when compared to PGCR data:
Joinability info:
Tracking information, which is real loosey-goosey. An entry per "thing being tracked", which could have Location Hashes, Item hashes, questline hashes, activity hashes or other data in a big ugly bucket of optional properties.
The last destination in which you were orbiting, in case someone cares where your ship is?
“Currently orbiting X” Thank you ❤️
On Aug 20, 2019, at 17:13, Vendal Thornheart notifications@github.com wrote:
Okay, here's the gameplan. We're going to introduce a new component - DestinyComponentType.Transitory - that will provide data that we consider to be non-authoritative but that potentially has useful data. I'm basically going to dump all this transitory data out with the caveat that we can't guarantee anything about it in hopes someone gets some use/fun out of it!
Requesting it will return a new profileTransitoryData property on DestinyProfileResponse.
It will have the following data, and none of it we'll be able to guarantee absolute canonical accuracy or timeliness:
* Party Member data, though only displayName, emblemHash, and account ID. We can't get the character ID, and it'd be too expensive for us to look up all your party members every time someone requests profile data. Hopefully this will be sufficient - if you absolutely need the character ID, you can hit us separately for them but please avoid it unless your use case absolutely requires it.
* current activity, if they're in one/if this data thinks you're in one, which will have the following. None of these should be considered canonical when compared to PGCR data:
When it started When it ended, if they're still standing around after the activity officially ended but before they're kicked to orbit The "score" as far as the transitory data considers it to be. The highest opposing team's "score" The number of opponents The total number of players in the activity * Joinability info:
How many slots are left in your fireteam Whether you're accepting clan/friend/open/invite only fireteam invites Reasons why you can't accept Fireteam members, if any * Tracking information, which is real loosey-goosey. An entry per "thing being tracked", which could have Location Hashes, Item hashes, questline hashes, activity hashes or other data in a big ugly bucket of optional properties.
* The last destination in which you were orbiting, in case someone cares where your ship is?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
That's awesome. Thank you so much for adding this.
On Tue, Aug 20, 2019 at 5:13 PM Vendal Thornheart notifications@github.com wrote:
Okay, here's the gameplan. We're going to introduce a new component - DestinyComponentType.Transitory - that will provide data that we consider to be non-authoritative but that potentially has useful data. I'm basically going to dump all this transitory data out with the caveat that we can't guarantee anything about it in hopes someone gets some use/fun out of it!
Requesting it will return a new profileTransitoryData property on DestinyProfileResponse.
It will have the following data, and none of it we'll be able to guarantee absolute canonical accuracy or timeliness:
* Party Member data, though only displayName, emblemHash, and account ID. We can't get the character ID, and it'd be too expensive for us to look up all your party members every time someone requests profile data. Hopefully this will be sufficient - if you absolutely need the character ID, you can hit us separately for them but please avoid it unless your use case absolutely requires it.
* current activity, if they're in one/if this data thinks you're in one, which will have the following. None of these should be considered canonical when compared to PGCR data:
- When it started
- When it ended, if they're still standing around after the activity officially ended but before they're kicked to orbit
- The "score" as far as the transitory data considers it to be.
- The highest opposing team's "score"
- The number of opponents
- The total number of players in the activity
* Joinability info:
- How many slots are left in your fireteam
- Whether you're accepting clan/friend/open/invite only fireteam invites
- Reasons why you can't accept Fireteam members, if any
Tracking information, which is real* loosey-goosey. An entry per "thing being tracked", which could have Location Hashes, Item hashes, questline hashes, activity hashes or other data in a big ugly bucket of optional properties.
* The last destination in which you were orbiting, in case someone cares where your ship is?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Bungie-net/api/issues/307?email_source=notifications&email_token=AABVGF557PV5X2RZ2LMJRN3QFSCCHA5CNFSM4EEMEGW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4YA7HA#issuecomment-523243420, or mute the thread https://github.com/notifications/unsubscribe-auth/AABVGF24JPVFL7MY6HUI4KLQFSCCHANCNFSM4EEMEGWQ .
@floatingatoll Sweet, I'm glad someone will get use out of that one! :D
@vthornheart That’s great! That was nailed down surprisingly quickly. Any idea when this new endpoint will actually be available? Just out of curiosity.
Oh yeah, so the funny thing is when I jumped in there, I found where I'd done work almost a year ago to try and get this transitory data out - and it was for this very Github issue, along with fixing a problem with Fireteams. But then I started working on Cross Save, and had to drop the rest of it. It was much closer to finishing than I thought - what I'm missing time on at this point is vetting the quality of this data, but I think perfect is the enemy of good here it sounds like.
@vthornheart-bng you are a legend, thanks!
Would “tracking information” be where we expect to find “the location of the current activity”, if one is available — and would the location ID returned be present in the metadata for a given Ghost perk such as “Dreaming City Scanner”, or would we need to freetext/manual match those perks to those location IDs ourselves?
I'm unfortunately unsure - that's one of the things I haven't really had the time to examine about this data. I took the chance a few months ago when trying to pull out Fireteam data, and pulled out all the transitory data I could get my hands on with the intent of examining it more closely once I had time (time that never materialized). It appears to be a bucket of transitory data about "things being tracked" - but that could potentially mean a great deal of things unfortunately, and I don't know at the moment what type(s) of things being tracked are in there.
Oh man, this is super encouraging to see. I have so many ideas for this. :D Thanks for the fast updates!
No prob, sorry it's been such a long time coming! The turnaround between making a change on the game side to pull new data and actually being able to use it is long enough that sometimes the whole effort gets sidetracked by a more important project in the interim! I'm glad we were able to loop back on it, and I'm glad someone brought it up or it could have ended up in backlog limbo.
So did this experimental feature ever get released? Because I could use it in the Twitch Extension I just released! https://www.twitch.tv/ext/dhotyq5dp8pzkx4teu0dehen8o4b0h
[edit]
Hmm it looks like the tracking
property always returns [{}]
.
Also would it be possible to return a structure like partyMembers
but for all players in the activity where status
contains values for fireteam, opposing team, blueberry, etc? This would be very helpful in a pvp/matchmaking situation where folks aren't a part of your team and it could be very useful to show and overview of the teams to viewers while the streamer is playing.
Also with activity, could this also include the current bubbleHash? I think I made a separate jira for this a while back... 🤔
Indeed, this data is live - I'll see if there's more data in regards to party members or bubbleHash, but I'm 99% sure that the data I'm sending is everything I can access.
I'm unsure of what can cause tracking data to be populated, so it may very well be that this isn't being used as of Shadowkeep (which means it lived a very short life indeed!). If that continues to be the case, I'll pull the field out.
Is there an appetite at Bungie for supporting the ability to dynamically retrieve who is in your current fireteam in Destiny 2? I've been acquainting myself with the API recently and my first thought was that this was something you'd be able to get through the GetPostGameCarnageReport endpoint. After tinkering a bit I realized that only reports on finished activities. I'm trying to build a web portal so we can view fireteam status in real-time, but I'm now certain there's not a way to access this data. Longer term ambitions would include peeking into the current kill/death count, but I think just getting the fireteam list itself would be a great start.