User.Client
Last updated
Last updated
The user interface can be used to modify the local user's rich presence data and read data from other users. In large the features and capabilities of the User interface are available through the related data object
Checks if the current user looks like they are behind a NAT device.
This is only valid if the user is connected to the Steam servers and may not catch all forms of NAT.
Checks whether the user's phone number is used to uniquely identify them.
Checks whether the current user's phone number is awaiting (re)verification.
Set the rich presence data for an unsecured game server that the user is playing on. This allows friends to be able to view the game info and join your game.
When you are using Steam authentication system this call is never required, the auth system automatically sets the appropriate rich presence.
Gets the level of the users Steam badge for your game.
Requests a URL which authenticates an in-game browser for store check-out, and then redirects to the specified URL. As long as the in-game browser accepts and handles session cookies, Steam microtransaction checkout pages will automatically recognize the user instead of presenting a login page.
The callback handler should take the form of:
The simplest way is
You can read this from the API as well
Set the rich presence data for an unsecured game server that the user is playing on. This allows friends to be able to view the game info and join your game.
Heathen engineering is not and will never support this sort of behaviour. If you need it look else where.
The same applies for SetDurationControlOnlineState and anything of similar nature.
Checks whether the current user has verified their phone number. See the page on the customer facing Steam Support site for more information.
Checks whether the current user has Steam Guard two factor authentication enabled on their account. See the page on the customer facing Steam Support site for more information.
Checks if the current user's Steam client is connected to the Steam servers. If it's not then no real-time services provided by the Steamworks API will be enabled. The Steam client will automatically be trying to recreate the connection as often as possible. When the connection is restored a callback will be posted. You usually don't need to check for this yourself. All of the API calls that rely on this will check internally. Forcefully disabling stuff when the player loses access is usually not a very good experience for the player and you could be preventing them from accessing APIs that do not need a live connection to Steam.
You can learn more about the
you can also get key data about the local user either from the resulting object as read from ID or directly from the interface as shown below