Support for Current Fireteam/Activity

k3nsanders commented 6 years ago

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.

vthornheart-bng commented 6 years 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!

ckhicks commented 6 years ago

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

vthornheart-bng commented 6 years ago

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.

k3nsanders commented 6 years ago

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.

xlxCLUxlx commented 6 years ago

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": {}
    }
  }
}

vthornheart-bng commented 6 years ago

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!

ArkahnX commented 6 years ago

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

vthornheart-bng commented 6 years ago

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!

ckhicks commented 6 years ago

Fantastic. Thanks as always.

vthornheart-bng commented 6 years ago

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. ;)

ckhicks commented 6 years ago

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!

vthornheart-bng commented 6 years ago

Woot! No prob, I'll keep you all posted when it finally gets closer to release ready!

mime55 commented 6 years ago

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

vthornheart-bng commented 6 years ago

Ha! Well yes I suppose ;)

joshhunt commented 6 years ago

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.

joshuaburkhalter commented 5 years ago

Would love to be able to access this info! Any idea if this will be coming soon?

vthornheart-bng commented 5 years ago

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!

cowgod commented 5 years ago

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.

ckhicks commented 5 years ago

^ 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! 🤤

nathanhosselton commented 5 years ago

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:

Cannot make any assumptions about fireteam based off of prior post-game report since raiding is a PvE activity
Only sensible reference for manual player selection is from a clan
Not all raid teams are intra-clan, and adding inter-clan or clan-less players requires one-off player searches (which is added complexity with its own limitations such as knowing battle tag hashes on PC)
Swapping out raid team members is a manual process

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.

wShaw commented 5 years ago

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 : (

vthornheart-bng commented 5 years ago

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?

TorKallon commented 5 years ago

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 .

vthornheart-bng commented 5 years ago

Sweet, because I think we may actually have a path to get you that data, with those unfortunate caveats.

vthornheart-bng commented 5 years ago

I will look into it and see if I can release it as an experimental feature.

wShaw commented 5 years ago

That is still 100 times better than the current situation, so +1 in my book :D

nathanhosselton commented 5 years ago

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.

cowgod commented 5 years ago

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!

vthornheart-bng commented 5 years ago

@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.

nathanhosselton commented 5 years ago

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.

vthornheart-bng commented 5 years ago

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.

cowgod commented 5 years ago

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.

vthornheart-bng commented 5 years ago

Sweeet, good deal! I'll see what we can do!

vthornheart-bng commented 5 years ago

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:

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?

floatingatoll commented 5 years ago

“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.

TorKallon commented 5 years ago

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 .

vthornheart-bng commented 5 years ago

@floatingatoll Sweet, I'm glad someone will get use out of that one! :D

cowgod commented 5 years ago

@vthornheart That’s great! That was nailed down surprisingly quickly. Any idea when this new endpoint will actually be available? Just out of curiosity.

vthornheart-bng commented 5 years ago

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.

bladefist commented 5 years ago

@vthornheart-bng you are a legend, thanks!

floatingatoll commented 5 years ago

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?

EdgarVerona commented 5 years ago

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.

ckhicks commented 5 years ago

Oh man, this is super encouraging to see. I have so many ideas for this. :D Thanks for the fast updates!

vthornheart-bng commented 5 years ago

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.

lowlines commented 4 years ago

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]

Ooooh 👀 https://bungie-net.github.io/multi/schema_Destiny-Components-Profiles-DestinyProfileTransitoryComponent.html#schema_Destiny-Components-Profiles-DestinyProfileTransitoryComponent

lowlines commented 4 years ago

Hmm it looks like the tracking property always returns [{}].

lowlines commented 4 years ago

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.

lowlines commented 4 years ago

Also with activity, could this also include the current bubbleHash? I think I made a separate jira for this a while back... 🤔

vthornheart-bng commented 4 years ago

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.

lowlines commented 4 years ago

prays in gamedev *

Bungie-net / api

Support for Current Fireteam/Activity #307