Hello,
I am aware that the current Group API (V1, as I've seen it called) is lacking functionality that will be added in the future. However, we aim to have a Group-Based beta guild implementation in Q1/Q2 and we'd like to make the most out of the system as it is right now.
We have solved the fact that Groups are not searchable by storing their IDs/names somewhere else on creation.
I have a number of questions:
1. How can I map TitleIDs to PlayFabIDs (to retrieve DisplayName)?
Group applications need to be approved by an Admin - How can I get that player's DisplayName and UserData? (There has to be at least SOME information regarding that player in the application itself, of course, admins would have a hard time approving or denying applications otherwise).
The Group Application ID is an Entity ID, but I have been reading the documentation and I found no way to map Entity ID (Player Title ID) to a PlayFabID, that I would need in CloudScript to retrieve more info about that player.
Of course, once I have the PlayFabID, I can use GetUserData or GetAccountInfo for all I need.
This would also solve our player index (we use outside storage to store a mapping between Player Title IDs and their display names). The plan is to store the user's name in the outside storage and only update it when a user joins or leaves the Group.
2. Are Group SetObjects/GetObjects CloudScript calls vulnerable to concurrency issues?
We plan to use Group Objects to store guild-specific data (for example, a treasury where all players can contribute with their gold).
The code would be on CloudScript. Would concurrent writes be an issue? If I have a function that reads a value (GetObjects) and then writes it back (SetObjects) on the Group entity, would that be a problem for a small-sized guild system? (10-15 members per guild).
3. I was reading some other posts and in one of the comments, Brendan mentioned that the V2 extended feature set for Groups may be available early summer. Any updates on that?
Many thanks,
Dani