Sorry for the confusion, I was under the impression a publisher key gave you certain read-only permissions on a user given they own your game (this was silly in hindsight)

While the users in question had public profiles, their privacy settings for friends lists were set to private.

Thank you for your help! I now understand what you meant by "as long as users grant your app permission".

brainCloud will automatically retrieve and reflect that friendship (as long as users grant your app permission)

Could you expand on this? I'm not sure what permission agreement needs to be made given I have already provided brainCloud with the publisher steam key.

Right now when I return ListFriends the list is empty while both players are: 1. Friends on steam 2. Logged into brainCloud.

After a conversation with brainBot, I'm told:

"To populate the "externalData" field in API responses, you'll need to use our external authentication script system with the authPayload parameter."

I was hoping Steam was already considered an external auth ! This means I need to write a steam authentication provider, a PSN provider, and so on just to mark the user with their appropriate platform/id for others to read?

I understand profiles need to be linked to brainCloud but when I call GetFriends and I've specified these friends are from Steam, why would there be no data in the response regarding the friends originating platforms?

This is really unfortunate!

Edit:
Now brainBot is saying I don't need an external provider, so I would love some clarification..

Here is what I'm experiencing:

1. Friend login and uses Steam auth provided by BrainCloud
2. Locally call AddPlatformFriends("SYNC" or "ADD"); success
3. Locally call ListFriends; returns the steam friend with only "brainCloud" returned as FriendPlatform.

Hello,

I see in the docs AddFriendsFromPlatform when set to sync is supposed add friends from a given platform which it does; but when I later request a list of friends the external data is null and friend platform returned says BrainCloud which is not what I was expecting to see (friendPlatform: Steam, externalId: SteamId)

What am I doing wrong?

@JasonL Thanks,

I guess in the case of Photon Realtime which doesn't have servers BrainCloud would call on for matchmaking, the idea would be to create a cloud script which is called by BrainCloud through matchmaking, and in theory simply return a room Id the realtime clients can use to connect?

The only doubt for Lobbies is that BrainCloud's matchmaking seems like it's tightly coupled with the Multiplayer concept in that in order to create a lobby definition, you need to define a Room server, and to define a room server you need to pass either a BrainCloud hosted room or Custom, and to that I'm trying to trying to understand where Photon Realtime fits where I don't have any servers to call or IPs to supply BrainCloud.

My view is that there should be a "guaranteed service availability" at the time of purchase not unlike buying an appliance with a year warranty..

Pull the game from stores and let the remaining players enjoy the sunset.
Of course it's not always as simple as "just keep the lights on longer" but a guaranteed period of availability which is tied to new purchases should be in your plans before your service ever reaches the public, rather than hoping to grab as much money as possible before dumping it and throwing the consumer under the bus.

Hi,

I'm looking at the Lobby system and it almost sounds perfect for my needs (gathering participants before entering a game experience); but I'm curious how it would go for a Pre-Game lobby, which is a very popular and common use case. (Fortnite, etc honestly I can't think of a single online game that doesn't do this)

I see there is no Invite to lobby, and brainBot is suggesting I use the platform's messaging service to invite but I just wanted to confirm this is the only way to go about it and that lobbies would be fine for a situation which is persisting before matchmaking takes place.

I'm also wondering would Groups be better option?

Groups reads as more of a long term persistent thing for guilds, clans and so on but the API does look like it fits all my needs [create, invite, kick, transfer ownership], but maybe there is a more restrictive rate limiting on creation etc that would be an issue for people creating and deleting lobbies every session.

Hi, not involved with BrainCloud but seeing as the team may be offline during the weekend I thought I would suggest looking at Player Stats:
https://docs.braincloudservers.com/api/capi/playerstats/

Converting into a table for display on the client should then be straightforward.

@Paul-Winterhalder Thanks, I ended up going with Entities/Groups for character/location business.

Since locations are player-owned and (which I forgot to mention) can have crew members/roles groups seemed to make the most sense with the builtin invites etc, using the group Id as the shareable Id as you mentioned for entities.

For matchmaking I see we have GetRandomGroupsMatching so I think that works out great!

Hello!

I'm migrating my Mongo data and game service, and I'm hoping for the best BrainCloud (cloud api) recommendations/pointers in the right direction for the below situation:

Players are assigned a session Id represented as a ship or location in-game. Players can connect if the player shares with them the session id. The session Id should be hidden from those it is not shared, hidden from matchmaking until requirements are met.

Is this a case of simply using ProfileId as the session Id? It seems a little unsafe. Let's say we have a social hub, and you have access to other player's profile id to common shared things such as avatars nicknames etc- now you could potentially join anyone's session or location even if they haven't entered the matchmaking pool yet.

Each "location"/session which persists also progresses along with the player, so in addition to a simple key-value Id ships/sessions get upgrades, so I guess this is the case for a player-owned entity?

Location Ids (essentially a session/room at a given location, within the game server):

Q: Where is this "location" (current per-player server) id best stored?

• Can be shared with friends, and once shared the friend can re-join provided it's saved somewhere
• Player can't modify it; only cloud api changes it
• Tied to matchmaking if the player meets requirements (has no shield, is within the same region ie (CA/US) and meets the XP requirements) this id will be presented as a means to join (raid) the player's session.

Thank you for your time!

After an email with a member on the Photon team, it turns out I was using the wrong key. In order for BC to obtain the secret with it's specific name, I should have been using using WebHookCustomHttpHeaders where instead I was using WebHookSecret which forced the name to X-Secret - this change allowed me to include the BC secret in the header rather than URL (which was working but obviously in the header is preferred)

No errors on Quantum's side (they have no logs forwarded in dashboard) left me thinking it was on BC, when in fact all was working on their end.

Thanks again !

Apparently what I thought was working was actually just photon's default behavior when it doesn't receive the appropriate response from the webhook.

@Paul-Winterhalder
Plenty may use photon but the Quantum 3 sdk is quite new and uses a new webhooks plugin that is restricted to a single base url and some static settings.. the way it works is appending the request type to the base url, ie join/create which I can't just include as a parameter since this happens dynamically within the photon server outside my control.

While I have had success using postman to receive an expected returned result and logs accordingly in BrainCloud, I don't actually see Any of photon's attempts to contact the Same url in the logs, which I'm guessing makes this a no-go?

I would at least expect to see something log in the Unreadable Requests section of logs? The fact it's ignoring photon completely but not postman is really bizarre, or maybe intended as the above comments indicate.. either way I need this functionality so that's unfortunate.

https://docs.braincloudservers.com/api/cc/writingscripts/webhooks

My profile displays in a different format than my logs do yes - reading 16:05:53.051 PST vs 4:05:53 PM PST, it's not a huge thing but would be nice as preference in profile settings (or cycling format on the log view timestamp itself)

IE user preference based on location or profile setting eg local standard of 12 hour vs 24 time.. It makes reading logs much less of a chore for some (those in US/Canada etc)

Unfortunately, I won't be able to use BrainCloud with Photon webhooks at all which is a shame, your end-point names also don't allow '/'s so I can't even create two different URLs.

That clears up some confusion! Thanks.

Say I have a webhook below:
<base braincloud webhook url>

Now, I want to call this, but at the same time I want to append a route depending on the state:

• /game/join
  or
• /game/create

How can I manage this in braincloud when the server (Photon) that is attempting to call the webhook can't be modified and is essentially a blackbox to customers?

Does braincloud support this type of "routing" from a single base url?