August 9th, 2022
Features #
Added requestingPlayer
parameter to limit access to party detail changes.
- Description: The
requestingPlayer
parameter has been added to the Party plugin interface to allow plugins to decide who can change party details. For example, you can deny changes requested by a party member other than the party leader. - Related notes: See related integration note.
Added new account tag actions in the Unity/Unreal SDKs for Partners.
- Description: Partner sessions can now view and bulk modify tags on player accounts via Unity and Unreal SDKs.
- Details:
- New SDK bindings for the following existing Partner endpoints:
AccountService.getAccountTagsPartnerV1(playerSocialIds
: get the tags for a given list of accountsAccountService.AddAccountTagsPartnerV1(playerSocialIds, tagsToAdd)
: add tags to multiple accountsAccountService.removeAccountTagsPartnerV1(playerSocialIds, tagsToRemove)
: remove tags from multiple accounts
- New endpoint and SDK binding:
AccountService.viewTagsPartnerV1()
: retrieve all existing tags in the system
- New SDK bindings for the following existing Partner endpoints:
Integrations #
Add the requestingPlayer
parameter to implementations of PartyPlugin.updateParty()
.
- Descriptions: To enable the new
requestingPlayer
feature, you must complete the listed integration step. - Integration step: Add
requestingPlayer: PartyPlayer
as the first parameter of thePartyPlugin.updateParty()
method. Update any references toUpdateDisplayNameV1Request
toUpdateDisplayNameOperatorV1Request
.
Original | Replacement |
---|---|
|
|
- Related note: See related feature note.
If you’re using dynamicSharding
support, correct columnNameOfpropertyToConsistentHash
in InventoryDaoConfig
by capitalizing the word Property
.
- Description: We’ve adjusted this capitalization to more accurately follow naming standards.
- Integration step:
- Make the following change in
InventoryDaoConfig
:original replacement columnNameOfpropertyToConsistentHash
columnNameOfPropertyToConsistentHash
- Make the following change in
Migrate all instances of ShutdownV1Notification
to the new RemovedV1Notification
.
- Description: We’ve replaced
ShutdownV1Notification
with a more accurately named notification calledRemovedV1Notification
. This should be used to alert clients when a player is removed from a party. - Integration step: Complete the following migration:
original replacement ShutdownV1Notification
RemovedNotification
Replace all uses of authenticateOrCreateV1
with authenticateOrCreateV2
.
- Description: The
authenticateOrCreateV1
http
endpoint and theAuthenticateOrCreateV1Request
andAuthenticateOrCreateV1Response
messages have been removed. - Integration steps:
- Update any usages of
authenticateOrCreateV1
endpoint to theauthenticateOrCreateV2
endpoint and use the correspondingAuthenticateOrCreateV2Request
andAuthenticateOrCreateV2Response
messages. - The
AuthenticateOrCreateV2Response
no longer contains thepragma_player_token
. Instead you should use thepragma_game_toke
n andpragma_social_token
depending on what service is being connected to.original replacement authenticateOrCreateV1
authenticateOrCreateV2
pragma_player_token
pragma_game_token
andpragma_social_token
- Update any usages of
Update all references of the MatchFoundPlugin
to the Match Lifecycle service package.
- Description:
MatchFoundPlugin
’s definition has been moved from the Matchmaking service package to a Match Lifecycle service package. You’ll need to update theMatchFoundPlugin
import if you’ve defined your own implementation, or update the config if you use the Pragma Engine-provided one. - Integration steps:
- If you’ve defined your own implementation of
MatchFoundPlugin
, update the import frompragma.matchmaking.MatchFoundPlugin
topragma.matchlifecycle.MatchFoundPlugin
. - If your config uses the Pragma Engine-provided
pragma.matchmaking.DefaultMatchFoundPlugin
, update it topragma.matchlifecycle.DefaultMatchFoundPlugin
.
- If you’ve defined your own implementation of
Update all references to UpdateDisplayNameV1Request
to UpdateDisplayNameOperatorV1Request
.
- Description: We’ve renamed the
UpdateDisplayNameV1Request
Operator RPC to match our naming standards and avoid session-type collisions. - Integration step: Update references to
UpdateDisplayNameV1Request
to capture the rename.original replacement UpdateDisplayNameV1Request
UpdateDisplayNameOperatorV1Request
- Note that If you’ve built a Portal from
source
instead of using the packagedportal-base
, you’ll need to rebuild and redeploy Portal.
Add configuration for PaymentDaoNodeService
to prepare for upcoming payments functionality.
- Description: In preparation for upcoming payments functionality, a new
DaoNodeService
has been created which will require configuration. - Integration step: Add the following new configuration for the
PaymentDaoNodeService
in your YAML file:
social:
serviceConfigs:
PaymentDaoConfig:
databaseConfig:
driver: "MYSQLDB"
username: "<database user>"
password: "<encrypted password>"
hostPortSchemas:
1: "<database host>:<database port>/<shard>_social_orderhistory1"
2: "<database host>:<database port>/<shard>_social_orderhistory2"