From 08cefc21ab0e8c10b7ec8e42475aa9a3b8b058f0 Mon Sep 17 00:00:00 2001 From: tudor <7089284+tudddorrr@users.noreply.github.com> Date: Mon, 24 Aug 2026 20:20:27 +0100 Subject: [PATCH] drop docs prefix, make 1.x the default --- app/lib/shared.ts | 2 +- app/routes.ts | 5 ++-- app/routes/docs.tsx | 26 +++---------------- app/routes/home.tsx | 11 ++++++-- app/routes/intro-redirect.tsx | 8 ++++-- app/routes/not-found.tsx | 7 +---- content/docs/1.x/admin/authentication.mdx | 2 +- content/docs/1.x/admin/common-errors.mdx | 4 +-- content/docs/1.x/admin/dev-data.mdx | 2 +- content/docs/1.x/admin/game-stat-api.mdx | 4 +-- content/docs/1.x/admin/leaderboard-api.mdx | 2 +- content/docs/1.x/godot/channels.mdx | 6 ++--- content/docs/1.x/godot/feedback.mdx | 2 +- content/docs/1.x/godot/identifying.mdx | 10 +++---- content/docs/1.x/godot/install.mdx | 4 +-- content/docs/1.x/godot/leaderboards.mdx | 2 +- content/docs/1.x/godot/live-config.mdx | 2 +- .../docs/1.x/godot/player-authentication.mdx | 6 ++--- content/docs/1.x/godot/player-props.mdx | 2 +- .../docs/1.x/godot/player-relationships.mdx | 2 +- content/docs/1.x/godot/settings-reference.mdx | 8 +++--- content/docs/1.x/godot/socket.mdx | 10 +++---- content/docs/1.x/http/authentication.mdx | 6 ++--- content/docs/1.x/http/bruno-collection.mdx | 6 ++--- content/docs/1.x/http/player-auth-api.mdx | 4 +-- .../docs/1.x/http/request-verification.mdx | 2 +- content/docs/1.x/http/socket-ticket-api.mdx | 2 +- content/docs/1.x/index.mdx | 14 +++++----- .../1.x/integrations/apple-game-center.mdx | 2 +- .../1.x/integrations/google-play-games.mdx | 2 +- content/docs/1.x/integrations/steamworks.mdx | 2 +- content/docs/1.x/sockets/common-errors.mdx | 4 +-- content/docs/1.x/sockets/intro.mdx | 8 +++--- content/docs/1.x/unity/channels.mdx | 6 ++--- content/docs/1.x/unity/feedback.mdx | 2 +- content/docs/1.x/unity/identifying.mdx | 10 +++---- content/docs/1.x/unity/install.mdx | 4 +-- content/docs/1.x/unity/leaderboards.mdx | 2 +- content/docs/1.x/unity/live-config.mdx | 2 +- .../docs/1.x/unity/player-authentication.mdx | 6 ++--- content/docs/1.x/unity/player-props.mdx | 2 +- .../docs/1.x/unity/player-relationships.mdx | 2 +- content/docs/1.x/unity/settings-reference.mdx | 10 +++---- content/docs/1.x/unity/socket.mdx | 10 +++---- content/docs/index.mdx | 14 +++++----- content/docs/pre-1.0/godot/channels.mdx | 6 ++--- content/docs/pre-1.0/godot/feedback.mdx | 2 +- content/docs/pre-1.0/godot/identifying.mdx | 10 +++---- content/docs/pre-1.0/godot/install.mdx | 2 +- content/docs/pre-1.0/godot/leaderboards.mdx | 2 +- content/docs/pre-1.0/godot/live-config.mdx | 2 +- .../pre-1.0/godot/player-authentication.mdx | 6 ++--- content/docs/pre-1.0/godot/player-props.mdx | 2 +- .../pre-1.0/godot/player-relationships.mdx | 2 +- .../docs/pre-1.0/godot/settings-reference.mdx | 8 +++--- content/docs/pre-1.0/godot/socket.mdx | 10 +++---- content/docs/pre-1.0/http/authentication.mdx | 6 ++--- .../docs/pre-1.0/http/bruno-collection.mdx | 6 ++--- content/docs/pre-1.0/http/player-auth-api.mdx | 4 +-- .../pre-1.0/http/request-verification.mdx | 2 +- .../docs/pre-1.0/http/socket-ticket-api.mdx | 2 +- content/docs/pre-1.0/index.mdx | 14 +++++----- .../integrations/apple-game-center.mdx | 2 +- .../integrations/google-play-games.mdx | 2 +- .../docs/pre-1.0/integrations/steamworks.mdx | 2 +- .../docs/pre-1.0/sockets/common-errors.mdx | 4 +-- content/docs/pre-1.0/sockets/intro.mdx | 8 +++--- content/docs/pre-1.0/unity/channels.mdx | 6 ++--- content/docs/pre-1.0/unity/feedback.mdx | 2 +- content/docs/pre-1.0/unity/identifying.mdx | 10 +++---- content/docs/pre-1.0/unity/install.mdx | 2 +- content/docs/pre-1.0/unity/leaderboards.mdx | 2 +- content/docs/pre-1.0/unity/live-config.mdx | 2 +- .../pre-1.0/unity/player-authentication.mdx | 6 ++--- content/docs/pre-1.0/unity/player-props.mdx | 2 +- .../pre-1.0/unity/player-relationships.mdx | 2 +- .../docs/pre-1.0/unity/settings-reference.mdx | 10 +++---- content/docs/pre-1.0/unity/socket.mdx | 10 +++---- react-router.config.ts | 4 +-- workers/app.ts | 25 +++++------------- 80 files changed, 206 insertions(+), 230 deletions(-) diff --git a/app/lib/shared.ts b/app/lib/shared.ts index b9e07ec..73de898 100644 --- a/app/lib/shared.ts +++ b/app/lib/shared.ts @@ -1,4 +1,4 @@ export const appName = 'Talo' -export const docsRoute = '/docs' +export const docsRoute = '/' export const baseApiUrl = import.meta.env.DEV ? 'http://localhost:3000' : 'https://api.trytalo.com' diff --git a/app/routes.ts b/app/routes.ts index 0608cb8..4da4c46 100644 --- a/app/routes.ts +++ b/app/routes.ts @@ -2,8 +2,7 @@ import { index, route, type RouteConfig } from '@react-router/dev/routes' export default [ index('routes/home.tsx'), - route('docs/intro', 'routes/intro-redirect.tsx'), - route('docs/*', 'routes/docs.tsx'), + route('intro', 'routes/intro-redirect.tsx'), route('api/search', 'routes/search.ts'), - route('*', 'routes/not-found.tsx'), + route(':version/*', 'routes/docs.tsx'), ] satisfies RouteConfig diff --git a/app/routes/docs.tsx b/app/routes/docs.tsx index b756b47..1a76e90 100644 --- a/app/routes/docs.tsx +++ b/app/routes/docs.tsx @@ -3,7 +3,6 @@ import { useFumadocsLoader } from 'fumadocs-core/source/client' import { DocsLayout } from 'fumadocs-ui/layouts/docs' import { DocsBody, DocsDescription, DocsPage, DocsTitle } from 'fumadocs-ui/layouts/docs/page' import { use } from 'react' -import { redirect } from 'react-router' import { Breadcrumb } from '@/components/breadcrumb' import { Feedback } from '@/components/feedback/client' import { useMDXComponents } from '@/components/mdx' @@ -12,32 +11,15 @@ import { baseOptions } from '@/lib/layout.shared' import { docs, source } from '@/lib/source' import type { Route } from './+types/docs' -// Pre-versioning paths (e.g. /docs/godot/install) redirect to the default version. -const DEFAULT_VERSION = '1.x' -const LEGACY_SECTIONS = ['godot', 'unity', 'http', 'sockets', 'selfhosting', 'integrations'] -const VERSION_REDIRECTS: Record = { - '1.0': '1.x', - '0.49': 'pre-1.0', - '0.60': 'pre-1.0', -} - +// Pre-versioning paths are redirected to the default version by the Cloudflare +// Worker (see workers/app.ts). export async function loader({ params }: Route.LoaderArgs) { - const slugs = params['*'].split('/').filter((v) => v.length > 0) + const version = params.version ?? '' + const slugs = [version, ...params['*'].split('/').filter((v) => v.length > 0)] const page = source.getPage(slugs) if (!page) { - const first = slugs[0] ?? '' - if (LEGACY_SECTIONS.includes(first)) { - throw redirect(`/docs/${DEFAULT_VERSION}/${slugs.join('/')}`) - } - if (VERSION_REDIRECTS[first]) { - throw redirect(`/docs/${VERSION_REDIRECTS[first]}/${slugs.slice(1).join('/')}`) - } throw new Response('Not found', { status: 404 }) } - // Default the docs root to the default version. - if (slugs.length === 0) { - throw redirect(`/docs/${DEFAULT_VERSION}`) - } return { path: page.path, diff --git a/app/routes/home.tsx b/app/routes/home.tsx index 05be887..9f8d821 100644 --- a/app/routes/home.tsx +++ b/app/routes/home.tsx @@ -1,5 +1,12 @@ -import { Navigate } from 'react-router' +import { useEffect } from 'react' +import { useNavigate } from 'react-router' export default function Home() { - return + const navigate = useNavigate() + + useEffect(() => { + navigate('/1.x', { replace: true }) + }, [navigate]) + + return null } diff --git a/app/routes/intro-redirect.tsx b/app/routes/intro-redirect.tsx index dc665ea..c6d9b5c 100644 --- a/app/routes/intro-redirect.tsx +++ b/app/routes/intro-redirect.tsx @@ -1,5 +1,9 @@ -import { Navigate } from 'react-router' +import { redirect } from 'react-router' + +export async function loader() { + throw redirect('/') +} export default function IntroRedirect() { - return + return null } diff --git a/app/routes/not-found.tsx b/app/routes/not-found.tsx index 3d75113..15919aa 100644 --- a/app/routes/not-found.tsx +++ b/app/routes/not-found.tsx @@ -1,11 +1,6 @@ import { HomeLayout } from 'fumadocs-ui/layouts/home' import { Link } from 'react-router' import { baseOptions } from '@/lib/layout.shared' -import type { Route } from './+types/not-found' - -export function meta({}: Route.MetaArgs) { - return [{ title: 'Not Found' }] -} export default function NotFound() { return ( @@ -15,7 +10,7 @@ export default function NotFound() {

This page could not be found.

Back to Docs diff --git a/content/docs/1.x/admin/authentication.mdx b/content/docs/1.x/admin/authentication.mdx index 0685673..0768c2a 100644 --- a/content/docs/1.x/admin/authentication.mdx +++ b/content/docs/1.x/admin/authentication.mdx @@ -7,7 +7,7 @@ title: Authentication The Admin API is a way of programmatically managing your game data like stats and leaderboards. -Unlike the gameplay-orientated [HTTP API](/docs/1.x/http/authentication), which authenticates requests on behalf of players, the Admin API authenticates requests using admin API keys scoped to your game. +Unlike the gameplay-orientated [HTTP API](/1.x/http/authentication), which authenticates requests on behalf of players, the Admin API authenticates requests using admin API keys scoped to your game. ## Creating an admin API key diff --git a/content/docs/1.x/admin/common-errors.mdx b/content/docs/1.x/admin/common-errors.mdx index 68acaf8..bafbbdf 100644 --- a/content/docs/1.x/admin/common-errors.mdx +++ b/content/docs/1.x/admin/common-errors.mdx @@ -9,7 +9,7 @@ title: Common errors The `Authorization` header is required, with its value set to `Bearer your-admin-api-key`. -Admin API keys are prefixed with `ta_` and are created inside the [dashboard](https://dashboard.trytalo.com/api-keys). Unlike the gameplay [HTTP API](/docs/1.x/http/authentication), admin API keys are scoped to a single game rather than authenticating on behalf of a player. +Admin API keys are prefixed with `ta_` and are created inside the [dashboard](https://dashboard.trytalo.com/api-keys). Unlike the gameplay [HTTP API](/1.x/http/authentication), admin API keys are scoped to a single game rather than authenticating on behalf of a player. ## Missing scopes @@ -66,4 +66,4 @@ The `Retry-After` header will return how many seconds to wait before retrying - Admin endpoints that read entities (e.g. listing leaderboard entries or listing stats) respect the `X-Talo-Include-Dev-Data` header. Set it to `1` to include development data, or leave it unset to only return live data. -Learn more in the [dev data guide](/docs/1.x/admin/dev-data). +Learn more in the [dev data guide](/1.x/admin/dev-data). diff --git a/content/docs/1.x/admin/dev-data.mdx b/content/docs/1.x/admin/dev-data.mdx index 6195816..1344312 100644 --- a/content/docs/1.x/admin/dev-data.mdx +++ b/content/docs/1.x/admin/dev-data.mdx @@ -4,7 +4,7 @@ title: Separating development data --- ## Dev build headers -When creating players through the [HTTP API](/docs/1.x/http/dev-data), you can optionally specify if the player belongs to a development build and therefore if they should be excluded from live data. +When creating players through the [HTTP API](/1.x/http/dev-data), you can optionally specify if the player belongs to a development build and therefore if they should be excluded from live data. By default, the Admin API only returns data associated with live players. To include development data in these reads, set the `X-Talo-Include-Dev-Data` header to `1`. diff --git a/content/docs/1.x/admin/game-stat-api.mdx b/content/docs/1.x/admin/game-stat-api.mdx index 27a7ae6..1df0b7e 100644 --- a/content/docs/1.x/admin/game-stat-api.mdx +++ b/content/docs/1.x/admin/game-stat-api.mdx @@ -19,7 +19,7 @@ export const pageToc = [ ## Overview -The game stat admin API lets you create, update, delete and reset [game stats](/docs/1.x/http/game-stat-api) programmatically, as well as read stats and their metrics. This is useful for automation like creating stats ahead of a new patch or resetting player stats between competitive seasons. +The game stat admin API lets you create, update, delete and reset [game stats](/1.x/http/game-stat-api) programmatically, as well as read stats and their metrics. This is useful for automation like creating stats ahead of a new patch or resetting player stats between competitive seasons. ## Endpoints @@ -52,7 +52,7 @@ type Stat = { ### StatMetrics -Metrics are **optional** and only included when the `withMetrics` query parameter is set on [list](/docs/1.x/admin/game-stat-api#get-all-game-stats) and [find](/docs/1.x/admin/game-stat-api#get-an-individual-game-stat) requests. When `withMetrics` is set, the `metrics` property is included with the stat response. +Metrics are **optional** and only included when the `withMetrics` query parameter is set on [list](/1.x/admin/game-stat-api#get-all-game-stats) and [find](/1.x/admin/game-stat-api#get-an-individual-game-stat) requests. When `withMetrics` is set, the `metrics` property is included with the stat response. ```ts type StatMetrics = { diff --git a/content/docs/1.x/admin/leaderboard-api.mdx b/content/docs/1.x/admin/leaderboard-api.mdx index ec22267..a1c6fdc 100644 --- a/content/docs/1.x/admin/leaderboard-api.mdx +++ b/content/docs/1.x/admin/leaderboard-api.mdx @@ -19,7 +19,7 @@ export const pageToc = [ ## Overview -The leaderboard admin API lets you create, update, delete and reset [leaderboards](/docs/1.x/http/leaderboard-api) programmatically, as well as read leaderboards and their entries. This is useful for automation like creating a new leaderboard ahead of a patch, resetting entries between competitive seasons or hiding suspicious entries. +The leaderboard admin API lets you create, update, delete and reset [leaderboards](/1.x/http/leaderboard-api) programmatically, as well as read leaderboards and their entries. This is useful for automation like creating a new leaderboard ahead of a patch, resetting entries between competitive seasons or hiding suspicious entries. ## Endpoints diff --git a/content/docs/1.x/godot/channels.mdx b/content/docs/1.x/godot/channels.mdx index 8d4a069..13a1720 100644 --- a/content/docs/1.x/godot/channels.mdx +++ b/content/docs/1.x/godot/channels.mdx @@ -306,7 +306,7 @@ if not result.success: For channel **storage** prop errors, use the `channel_storage_props_failed_to_set` signal instead. -See [Players and props - Prop rejection reasons](/docs/1.x/godot/player-props#prop-rejection-reasons) for the full list of rejection reason codes. +See [Players and props - Prop rejection reasons](/1.x/godot/player-props#prop-rejection-reasons) for the full list of rejection reason codes. ## Channel storage @@ -345,7 +345,7 @@ func _ready() -> void: ) ``` -`TaloRejectedProp` includes a `message` with a human-readable description of the error, alongside the `code`. See [Players and props - Prop rejection reasons](/docs/1.x/godot/player-props#prop-rejection-reasons) for the full list of rejection reason codes. +`TaloRejectedProp` includes a `message` with a human-readable description of the error, alongside the `code`. See [Players and props - Prop rejection reasons](/1.x/godot/player-props#prop-rejection-reasons) for the full list of rejection reason codes. ### Setting storage prop arrays @@ -463,7 +463,7 @@ This function will return a `TaloChannelStorageProp` array, allowing you to iter #### Prop arrays -If any of the keys you pass are [prop arrays](/docs/1.x/godot/channels#getting-storage-prop-arrays), append `[]` to the key to fetch every item stored under it. Scalar and array keys can be mixed in a single call: +If any of the keys you pass are [prop arrays](/1.x/godot/channels#getting-storage-prop-arrays), append `[]` to the key to fetch every item stored under it. Scalar and array keys can be mixed in a single call: ```gdscript # storage_prop_1 is a scalar, world_items[] is a prop array diff --git a/content/docs/1.x/godot/feedback.mdx b/content/docs/1.x/godot/feedback.mdx index 342ad9e..9806ddf 100644 --- a/content/docs/1.x/godot/feedback.mdx +++ b/content/docs/1.x/godot/feedback.mdx @@ -75,4 +75,4 @@ if not result.success: print("Rejected prop '%s': %s (%s)" % [prop.key, prop.message, prop.code]) ``` -See [Players and props - Prop rejection reasons](/docs/1.x/godot/player-props#prop-rejection-reasons) for the full list of rejection reason codes. +See [Players and props - Prop rejection reasons](/1.x/godot/player-props#prop-rejection-reasons) for the full list of rejection reason codes. diff --git a/content/docs/1.x/godot/identifying.mdx b/content/docs/1.x/godot/identifying.mdx index da42d9c..635eb02 100644 --- a/content/docs/1.x/godot/identifying.mdx +++ b/content/docs/1.x/godot/identifying.mdx @@ -34,7 +34,7 @@ You cannot use "Talo" for the `service` parameter as this is reserved for **Talo If you are using Talo Player Authentication, `Talo.players.identify()` will be invoked automatically and the `Talo.players.identified` signal will also emit as normal. -Visit the [Player authentication docs](/docs/1.x/godot/player-authentication) to learn more about identifying players with authentication enabled. +Visit the [Player authentication docs](/1.x/godot/player-authentication) to learn more about identifying players with authentication enabled. @@ -134,7 +134,7 @@ In the example above, the two players created with `Talo.players.identify()` are page](https://dashboard.trytalo.com/integrations). -If you have the Steamworks integration enabled, Talo can sync a Steam player ([as described here](/docs/1.x/integrations/steamworks#authentication)). You can do this via the `Talo.players.identify_steam` function. Here's an example using [GodotSteam](https://godotsteam.com): +If you have the Steamworks integration enabled, Talo can sync a Steam player ([as described here](/1.x/integrations/steamworks#authentication)). You can do this via the `Talo.players.identify_steam` function. Here's an example using [GodotSteam](https://godotsteam.com): ```gdscript extends Node @@ -157,7 +157,7 @@ The `identity` parameter is optional but strongly recommended as it ensures prop ### Steamworks player props -After successfully authenticating the player, several [props](/docs/1.x/godot/player-props) will automatically be created for them: +After successfully authenticating the player, several [props](/1.x/godot/player-props) will automatically be created for them: - `META_STEAMWORKS_VAC_BANNED` - "true" or "false" - `META_STEAMWORKS_PUBLISHER_BANNED` - "true" or "false" @@ -209,7 +209,7 @@ Replace "yourid.apps.googleusercontent.com" with the client ID you generated ear ### Google Play Games player props -After successfully authenticating the player, these [props](/docs/1.x/godot/player-props) will automatically be created for them: +After successfully authenticating the player, these [props](/1.x/godot/player-props) will automatically be created for them: - `META_GOOGLE_PLAY_GAMES_DISPLAY_NAME` - The player's chosen display name - `META_GOOGLE_PLAY_GAMES_AVATAR_URL` - A direct link to the player's avatar @@ -296,7 +296,7 @@ This function will return the identifier (if one exists) or an empty string. If ## Display names -Every player alias has a `display_name` that provides a human-readable name for the player. You can read it from `Talo.current_alias.display_name` after a player has been identified. Display names are resolved from a [player's props](/docs/1.x/godot/player-props) - arbitrary properties persisted across all of a player's aliases. +Every player alias has a `display_name` that provides a human-readable name for the player. You can read it from `Talo.current_alias.display_name` after a player has been identified. Display names are resolved from a [player's props](/1.x/godot/player-props) - arbitrary properties persisted across all of a player's aliases. ```gdscript title="welcome_label.gd" extends Label diff --git a/content/docs/1.x/godot/install.mdx b/content/docs/1.x/godot/install.mdx index ba41b23..d7c3b39 100644 --- a/content/docs/1.x/godot/install.mdx +++ b/content/docs/1.x/godot/install.mdx @@ -23,7 +23,7 @@ You can download the latest version of the Godot plugin from our [itch.io page]( Upgrading from an older version of the plugin? Read the [upgrading to 1.0 - guide](/docs/1.x/godot/upgrading-to-1.0) for the breaking changes. + guide](/1.x/godot/upgrading-to-1.0) for the breaking changes. ## Enable the plugin @@ -67,4 +67,4 @@ If you're self-hosting Talo, you can configure your custom endpoint here in the ### Settings reference -You can visit the [settings reference](/docs/1.x/godot/settings-reference) for a detailed overview of Talo's configuration options. +You can visit the [settings reference](/1.x/godot/settings-reference) for a detailed overview of Talo's configuration options. diff --git a/content/docs/1.x/godot/leaderboards.mdx b/content/docs/1.x/godot/leaderboards.mdx index 2f9f898..b1be441 100644 --- a/content/docs/1.x/godot/leaderboards.mdx +++ b/content/docs/1.x/godot/leaderboards.mdx @@ -107,7 +107,7 @@ if not res.success: print("Rejected prop '%s': %s (%s)" % [prop.key, prop.message, prop.code]) ``` -See [Players and props - Prop rejection reasons](/docs/1.x/godot/player-props#prop-rejection-reasons) for the full list of rejection reason codes. +See [Players and props - Prop rejection reasons](/1.x/godot/player-props#prop-rejection-reasons) for the full list of rejection reason codes. ## Getting entries diff --git a/content/docs/1.x/godot/live-config.mdx b/content/docs/1.x/godot/live-config.mdx index 7115684..fc542dd 100644 --- a/content/docs/1.x/godot/live-config.mdx +++ b/content/docs/1.x/godot/live-config.mdx @@ -58,4 +58,4 @@ func _on_live_config_updated(live_config: TaloLiveConfig) -> void: label.text = live_config.get_prop("live_string", "Not set!") ``` -The `live_config_updated` signal is emitted (via the [Talo Socket](/docs/1.x/socket)) whenever the live config is updated. +The `live_config_updated` signal is emitted (via the [Talo Socket](/1.x/socket)) whenever the live config is updated. diff --git a/content/docs/1.x/godot/player-authentication.mdx b/content/docs/1.x/godot/player-authentication.mdx index 728ba57..8450957 100644 --- a/content/docs/1.x/godot/player-authentication.mdx +++ b/content/docs/1.x/godot/player-authentication.mdx @@ -242,7 +242,7 @@ You can migrate a player's account to a different service and identifier using ` The original player auth account will be deleted and they will only be able to use their new identifier. -Here is an example of migrating to a [Steam alias](/docs/1.x/godot/identifying#steamworks-integration): +Here is an example of migrating to a [Steam alias](/1.x/godot/identifying#steamworks-integration): ```gdscript @onready var current_password: TextEdit = %CurrentPassword @@ -267,7 +267,7 @@ func _migrate_account(ticket: String) -> void: validation_label.text = res.error.message ``` -You can also migrate to the `google_play_games` service by providing an [auth code](/docs/1.x/godot/identifying#google-play-games-integration). +You can also migrate to the `google_play_games` service by providing an [auth code](/1.x/godot/identifying#google-play-games-integration). When a migration is successful, the current session is cleared, the player's alias is updated to the new service and identifier, and the `Talo.players.identified` signal is emitted. @@ -275,4 +275,4 @@ When a migration is successful, the current session is cleared, the player's ali As shown in the examples above, every auth method returns a result object. On failure, `res.success` is `false` and `res.error` holds a `TaloPlayerAuthError` with a machine-readable `code` enum value and a human-readable `message`. -You can view all the authentication errors and their descriptions [here](/docs/1.x/http/player-auth-api#error-codes). +You can view all the authentication errors and their descriptions [here](/1.x/http/player-auth-api#error-codes). diff --git a/content/docs/1.x/godot/player-props.mdx b/content/docs/1.x/godot/player-props.mdx index 9ad59ef..137ba2b 100644 --- a/content/docs/1.x/godot/player-props.mdx +++ b/content/docs/1.x/godot/player-props.mdx @@ -37,7 +37,7 @@ print("Found %s results: %s" % [search_page.count, ", ".join(identifiers)]) Players can have a list of arbitrary properties that are persisted across all of their aliases. These props are identified by their unique key and can have any string value. Keys can be up to 128 characters long and values can be up to 512 characters long. -All functions that modify props accept an optional `update` parameter (default `true`) that controls whether the player is synced with Talo after the change. They return an awaitable `PlayerUpdateResult`, and setting `update` to `false` returns a valid result without triggering a sync - use it to batch multiple changes and avoid redundant [debounces](/docs/1.x/godot/settings-reference#debounce_timer_seconds). +All functions that modify props accept an optional `update` parameter (default `true`) that controls whether the player is synced with Talo after the change. They return an awaitable `PlayerUpdateResult`, and setting `update` to `false` returns a valid result without triggering a sync - use it to batch multiple changes and avoid redundant [debounces](/1.x/godot/settings-reference#debounce_timer_seconds). The `Talo.players.player_updated(success: bool)` signal fires after every player update settles, and `Talo.players.flush_updates()` immediately flushes any pending or in-flight update (returning a `FlushResult`). Pending updates are also flushed automatically when the game quits. diff --git a/content/docs/1.x/godot/player-relationships.mdx b/content/docs/1.x/godot/player-relationships.mdx index b61d813..d2e39af 100644 --- a/content/docs/1.x/godot/player-relationships.mdx +++ b/content/docs/1.x/godot/player-relationships.mdx @@ -33,7 +33,7 @@ A complete sample is available in the Godot plugin at `addons/talo/samples/frien To subscribe to a player, you need to first decide what type of relationship you want to create: unidirectional or bidirectional. Unidirectional relationships create a subscription to the target player and bidirectional relationships will create a reciprocal subscription between both players. -You also need to know the target player alias' ID. You can get this through [player presence updates](/docs/1.x/godot/player-presence), or by searching for players using [player search](/docs/1.x/godot/player-props#searching-for-players). +You also need to know the target player alias' ID. You can get this through [player presence updates](/1.x/godot/player-presence), or by searching for players using [player search](/1.x/godot/player-props#searching-for-players). Once you have both of these pieces of information, you can create the relationship: diff --git a/content/docs/1.x/godot/settings-reference.mdx b/content/docs/1.x/godot/settings-reference.mdx index 93f5b27..969d01f 100644 --- a/content/docs/1.x/godot/settings-reference.mdx +++ b/content/docs/1.x/godot/settings-reference.mdx @@ -40,7 +40,7 @@ At a minimum, the Talo Godot plugin requires the `read:players` and `write:playe ### api_url -This is the location of the Talo API. The default cloud version is `https://api.trytalo.com`. If you're [self-hosting Talo](/docs/1.x/selfhosting/overview), this should be the address of your `backend` container. +This is the location of the Talo API. The default cloud version is `https://api.trytalo.com`. If you're [self-hosting Talo](/1.x/selfhosting/overview), this should be the address of your `backend` container. ### socket_url @@ -79,11 +79,11 @@ If enabled, Talo will automatically cache the player after a successful online i ### continuity.enabled -If enabled, Talo will try to automatically replay failed network requests - [learn more about Continuity here](/docs/1.x/godot/continuity). +If enabled, Talo will try to automatically replay failed network requests - [learn more about Continuity here](/1.x/godot/continuity). ### player_auth.auto_start_session -If enabled and a valid session token is found, the player will be automatically authenticated. This is documented on the [Player Authentication page](/docs/1.x/godot/player-authentication#automatic-logins). +If enabled and a valid session token is found, the player will be automatically authenticated. This is documented on the [Player Authentication page](/1.x/godot/player-authentication#automatic-logins). ### logging.requests @@ -109,7 +109,7 @@ If enabled, HTTP requests run on a separate thread (`HTTPRequest.use_threads`), ### verification.enabled -Enable request verification to cryptographically sign requests and socket messages. This must also be enabled in the Talo dashboard. Learn more on the [Request verification page](/docs/1.x/godot/request-verification). +Enable request verification to cryptographically sign requests and socket messages. This must also be enabled in the Talo dashboard. Learn more on the [Request verification page](/1.x/godot/request-verification). ### verification.key_version diff --git a/content/docs/1.x/godot/socket.mdx b/content/docs/1.x/godot/socket.mdx index b9c7983..33479aa 100644 --- a/content/docs/1.x/godot/socket.mdx +++ b/content/docs/1.x/godot/socket.mdx @@ -11,7 +11,7 @@ Ideally you should never need to use the socket directly because individual serv The socket connection is automatically established (this can disabled by setting `auto_connect_socket` to `false` in your config). When a player gets identified, they also get automatically identified with the socket server. -You can learn more about how the socket works [here](/docs/1.x/sockets/intro). +You can learn more about how the socket works [here](/1.x/sockets/intro). ## Obtaining a socket ticket @@ -23,7 +23,7 @@ Opening a socket connection using `Talo.socket.open_connection()` will automatic ## Receiving messages -The `message_received` signal provides you with a [response](/docs/1.x/sockets/responses) and payload. For example, if you were building a chat system, you would connect a function similar to the one below to listen for new chat messages: +The `message_received` signal provides you with a [response](/1.x/sockets/responses) and payload. For example, if you were building a chat system, you would connect a function similar to the one below to listen for new chat messages: ```gdscript func _ready() -> void: @@ -38,7 +38,7 @@ func _on_message_received(res: String, data: Dictionary) -> void: ## Sending messages -Sending messages is handled by functions in services like `Talo.channels.send_message()` where the correct data is prepared and sent for you. You can also use the `Talo.socket.send(req, data)` function to send your own [requests](/docs/1.x/sockets/requests): +Sending messages is handled by functions in services like `Talo.channels.send_message()` where the correct data is prepared and sent for you. You can also use the `Talo.socket.send(req, data)` function to send your own [requests](/1.x/sockets/requests): ```gdscript func send_message(channel_id: int, message: String) -> void: @@ -57,7 +57,7 @@ func send_message(channel_id: int, message: String) -> void: -The socket server can disconnect for a number of reasons such as the player going offline or being [rate limited](/docs/1.x/sockets/common-errors#rate-limit-exceeded). The socket will emit a `connection_closed` signal with a status code and reason. +The socket server can disconnect for a number of reasons such as the player going offline or being [rate limited](/1.x/sockets/common-errors#rate-limit-exceeded). The socket will emit a `connection_closed` signal with a status code and reason. The Talo socket automatically reconnects when the [connection is restored](continuity#connection_restored). If you need to manually re-open the socket, you can establish a connection and re-identify the player like this: @@ -75,7 +75,7 @@ You can choose to manually end the socket connection using `Talo.socket.close_co ## Request verification -If your game has [request verification](/docs/1.x/godot/request-verification) enabled, socket messages are automatically signed for players. The server validates these signatures to prevent replay attacks and tampering. +If your game has [request verification](/1.x/godot/request-verification) enabled, socket messages are automatically signed for players. The server validates these signatures to prevent replay attacks and tampering. ## Error handling diff --git a/content/docs/1.x/http/authentication.mdx b/content/docs/1.x/http/authentication.mdx index 5bfffbc..a868bdb 100644 --- a/content/docs/1.x/http/authentication.mdx +++ b/content/docs/1.x/http/authentication.mdx @@ -28,15 +28,15 @@ Most endpoints perform actions on behalf of players.If you are using [player aut The Godot plugin and Unity package will automatically populate these headers for you. If you're receiving session-related errors, visit the [Common - errors](/docs/1.x/http/common-errors#missing-or-invalid-session) page for more information. + errors](/1.x/http/common-errors#missing-or-invalid-session) page for more information. ### Session token lifetimes -By default, session tokens returned by [register, login, verify, and refresh](/docs/1.x/http/player-auth-api) are long-lived and do not need to be renewed. Your game can store the token on the device and reuse it for as long as the player keeps playing. +By default, session tokens returned by [register, login, verify, and refresh](/1.x/http/player-auth-api) are long-lived and do not need to be renewed. Your game can store the token on the device and reuse it for as long as the player keeps playing. If you prefer shorter-lived sessions, you can opt in to the refresh token flow using the `withRefresh` parameter. When enabled: - The session token expires after **15 minutes**. - A **30-day refresh token** is returned alongside it. -- Call the [refresh session](/docs/1.x/http/player-auth-api) endpoint with the refresh token to receive a new session and refresh token. +- Call the [refresh session](/1.x/http/player-auth-api) endpoint with the refresh token to receive a new session and refresh token. diff --git a/content/docs/1.x/http/bruno-collection.mdx b/content/docs/1.x/http/bruno-collection.mdx index 173dbec..c9dbe4b 100644 --- a/content/docs/1.x/http/bruno-collection.mdx +++ b/content/docs/1.x/http/bruno-collection.mdx @@ -44,12 +44,12 @@ Most player-scoped endpoints expect two headers in addition to the API key: 1. `x-talo-player` - the player's ID 2. `x-talo-alias` - the ID of one of the player's identified alias -To get these, run the [Identify](/docs/1.x/http/player-api) endpoint first (found in the **Players** folder of the collection). This will automatically set the variables for both of those headers. +To get these, run the [Identify](/1.x/http/player-api) endpoint first (found in the **Players** folder of the collection). This will automatically set the variables for both of those headers. ### Talo player authentication -If your game uses [Talo's player authentication](/docs/1.x/http/player-auth-api), you'll also need the `x-talo-session` header. +If your game uses [Talo's player authentication](/1.x/http/player-auth-api), you'll also need the `x-talo-session` header. Run the **register** and **login** requests (from the **Player auth** folder). This will set the `x-talo-session` variable and refresh token variable (for refreshing the short-lived session token). -See [Player authentication](/docs/1.x/http/authentication#player-authentication) for the full flow. +See [Player authentication](/1.x/http/authentication#player-authentication) for the full flow. diff --git a/content/docs/1.x/http/player-auth-api.mdx b/content/docs/1.x/http/player-auth-api.mdx index be5d8e9..edd19eb 100644 --- a/content/docs/1.x/http/player-auth-api.mdx +++ b/content/docs/1.x/http/player-auth-api.mdx @@ -28,7 +28,7 @@ Learn more about player authentication [here](https://trytalo.com/players#authen ## Identifying players using Talo Authentication -Once you have registered a player, you can identify them using the [identify](/docs/1.x/http/player-api) endpoint. You will need to ensure that: +Once you have registered a player, you can identify them using the [identify](/1.x/http/player-api) endpoint. You will need to ensure that: 1. The `identifier` is the one you used to register the player (email, username, etc.) 2. The `service` is set to `talo` @@ -39,7 +39,7 @@ To create a new session token, you will need to go through the login flow again By default session tokens are long-lived. You can opt in to short-lived (15-minute) session tokens paired with a 30-day refresh token using the `withRefresh` parameter. See [Session token - lifetimes](/docs/1.x/http/authentication#session-token-lifetimes) for the full details. + lifetimes](/1.x/http/authentication#session-token-lifetimes) for the full details. ## Endpoints diff --git a/content/docs/1.x/http/request-verification.mdx b/content/docs/1.x/http/request-verification.mdx index c6b7767..d0b81eb 100644 --- a/content/docs/1.x/http/request-verification.mdx +++ b/content/docs/1.x/http/request-verification.mdx @@ -94,7 +94,7 @@ You can then send the signature in the `x-talo-signature` header alongside your Enabling request verification also enables verification for socket messages. -See the [socket request verification docs](/docs/1.x/sockets/request-verification) for details on how to prepend the signature to the message payload. +See the [socket request verification docs](/1.x/sockets/request-verification) for details on how to prepend the signature to the message payload. ## When verification applies diff --git a/content/docs/1.x/http/socket-ticket-api.mdx b/content/docs/1.x/http/socket-ticket-api.mdx index 0e33cb8..def249e 100644 --- a/content/docs/1.x/http/socket-ticket-api.mdx +++ b/content/docs/1.x/http/socket-ticket-api.mdx @@ -18,7 +18,7 @@ export const pageToc = [ Talo provides a secure socket system for real-time communication between your game and players. The Talo Socket powers services like [channels](https://trytalo.com/channels?utm_source=socket-docs&utm_medium=api-docs) and [player relationships](https://trytalo.com/player-relationships?utm_source=socket-docs&utm_medium=api-docs). -To connect to the socket server, you need to obtain a socket ticket. Learn more about socket authentication [here](/docs/1.x/sockets/intro#authentication). +To connect to the socket server, you need to obtain a socket ticket. Learn more about socket authentication [here](/1.x/sockets/intro#authentication). ## Endpoints diff --git a/content/docs/1.x/index.mdx b/content/docs/1.x/index.mdx index 648f034..32ace9c 100644 --- a/content/docs/1.x/index.mdx +++ b/content/docs/1.x/index.mdx @@ -6,13 +6,13 @@ title: Talo overview ## Choose your adventure - - - - - - - + + + + + + + ## Everything you need in one place diff --git a/content/docs/1.x/integrations/apple-game-center.mdx b/content/docs/1.x/integrations/apple-game-center.mdx index 5e4c09e..85708cb 100644 --- a/content/docs/1.x/integrations/apple-game-center.mdx +++ b/content/docs/1.x/integrations/apple-game-center.mdx @@ -17,4 +17,4 @@ To get started, enter your app's Bundle ID into the dashboard. Talo will use thi To identify a player, fetch the local player's identity verification signature from Game Center and pass the values to Talo. Talo will cryptographically verify the signature against Apple's public key and automatically identify the player without them needing to create an account. -Check out the [Godot plugin docs](/docs/1.x/godot/identifying#apple-game-center-integration) or [Unity package docs](/docs/1.x/unity/identifying#apple-game-center-integration) for more details. +Check out the [Godot plugin docs](/1.x/godot/identifying#apple-game-center-integration) or [Unity package docs](/1.x/unity/identifying#apple-game-center-integration) for more details. diff --git a/content/docs/1.x/integrations/google-play-games.mdx b/content/docs/1.x/integrations/google-play-games.mdx index 4ed2055..3b5792b 100644 --- a/content/docs/1.x/integrations/google-play-games.mdx +++ b/content/docs/1.x/integrations/google-play-games.mdx @@ -19,4 +19,4 @@ To identify a player, [request a server auth code](https://developer.android.com Talo will also add helpful `props` to your player such as their display name and avatar URL. -Check out the [Godot plugin docs](/docs/1.x/godot/identifying#google-play-games-integration) or [Unity package docs](/docs/1.x/unity/identifying#google-play-games-integration) for more details. +Check out the [Godot plugin docs](/1.x/godot/identifying#google-play-games-integration) or [Unity package docs](/1.x/unity/identifying#google-play-games-integration) for more details. diff --git a/content/docs/1.x/integrations/steamworks.mdx b/content/docs/1.x/integrations/steamworks.mdx index 31d7c93..b811c26 100644 --- a/content/docs/1.x/integrations/steamworks.mdx +++ b/content/docs/1.x/integrations/steamworks.mdx @@ -19,7 +19,7 @@ You'll need to pass the ticket generated by the [GetAuthTicketForWebApi](https:/ Talo will also add helpful `props` to your player such as app ownership details, profile names and avatars. -Check out the [Godot plugin docs](/docs/1.x/godot/identifying#steamworks-integration) or [Unity package docs](/docs/1.x/unity/identifying#steamworks-integration) for more details. +Check out the [Godot plugin docs](/1.x/godot/identifying#steamworks-integration) or [Unity package docs](/1.x/unity/identifying#steamworks-integration) for more details. ## Leaderboards diff --git a/content/docs/1.x/sockets/common-errors.mdx b/content/docs/1.x/sockets/common-errors.mdx index 34fa354..a9fcbad 100644 --- a/content/docs/1.x/sockets/common-errors.mdx +++ b/content/docs/1.x/sockets/common-errors.mdx @@ -4,7 +4,7 @@ title: Common errors ## Missing authentication -A valid socket ticket is required when opening a socket connection. Learn more about how to obtain a socket ticket and connect to the socket server [here](/docs/1.x/intro#connecting-to-the-socket-server). +A valid socket ticket is required when opening a socket connection. Learn more about how to obtain a socket ticket and connect to the socket server [here](/1.x/intro#connecting-to-the-socket-server). Connections without a valid ticket will be closed immediately. @@ -129,7 +129,7 @@ A request listener can throw an error specific to its own internal logic. These } ``` -If your game has [request verification](/docs/1.x/sockets/request-verification) enabled, all socket messages sent after identifying a player must include a valid signature. If the signature is missing, malformed or fails Talo's validation, you will receive this error. +If your game has [request verification](/1.x/sockets/request-verification) enabled, all socket messages sent after identifying a player must include a valid signature. If the signature is missing, malformed or fails Talo's validation, you will receive this error. ## Rate limit exceeded diff --git a/content/docs/1.x/sockets/intro.mdx b/content/docs/1.x/sockets/intro.mdx index 0df3f4b..d8afd09 100644 --- a/content/docs/1.x/sockets/intro.mdx +++ b/content/docs/1.x/sockets/intro.mdx @@ -7,7 +7,7 @@ title: Socket basics The socket used by Talo follows the web socket standard and is compatible with libraries that also do the same. -One major difference is that the Talo Socket will validate messages against a request type and payload structure. For example, if you send a message with the `v1.players.identified` request, your payload's data must also match the expected schema. The list of available [requests](/docs/1.x/requests) and [responses](/docs/1.x/responses) are available on their respective pages. +One major difference is that the Talo Socket will validate messages against a request type and payload structure. For example, if you send a message with the `v1.players.identified` request, your payload's data must also match the expected schema. The list of available [requests](/1.x/requests) and [responses](/1.x/responses) are available on their respective pages. Using the identification example, here is the JSON expected by the Talo Socket when identifying a player: @@ -51,7 +51,7 @@ Responses use a similar message structure, except that `req` is replaced by `res The Talo Socket provides two layers of authentication: -1. You must provide a [socket ticket](/docs/1.x/http/socket-ticket-api) when opening a socket connection. This identifies your game and the key's scopes are used to determine whether a client is eligible to receive specific responses. +1. You must provide a [socket ticket](/1.x/http/socket-ticket-api) when opening a socket connection. This identifies your game and the key's scopes are used to determine whether a client is eligible to receive specific responses. 2. When players are identified, a `socketToken` is stored against the player alias for 1 hour. While the socket token is valid, you can use it to authenticate your player with the socket. @@ -72,7 +72,7 @@ The default socket URL is `wss://api.trytalo.com`. When opening a socket connect wss://api.trytalo.com/socket?ticket=your-ticket-here ``` -Your ticket should be a valid socket ticket, i.e. it was created within the last 5 minutes. Visit the [API docs](/docs/1.x/http/socket-ticket-api) for more information on how to obtain a socket ticket. +Your ticket should be a valid socket ticket, i.e. it was created within the last 5 minutes. Visit the [API docs](/1.x/http/socket-ticket-api) for more information on how to obtain a socket ticket. ## Error responses @@ -103,4 +103,4 @@ Some errors may also return a "cause" key which drills down into why a request f } ``` -For a more detailed look into the available error codes, visit the [common errors](/docs/1.x/common-errors) page. +For a more detailed look into the available error codes, visit the [common errors](/1.x/common-errors) page. diff --git a/content/docs/1.x/unity/channels.mdx b/content/docs/1.x/unity/channels.mdx index 5d17325..5f02999 100644 --- a/content/docs/1.x/unity/channels.mdx +++ b/content/docs/1.x/unity/channels.mdx @@ -278,7 +278,7 @@ if (!result.Success) For **channel storage** prop errors, use the `OnChannelStoragePropsFailedToSet` event instead. -See [Players and props - Prop rejection reasons](/docs/1.x/unity/player-props#prop-rejection-reasons) for the full list of rejection reason codes. +See [Players and props - Prop rejection reasons](/1.x/unity/player-props#prop-rejection-reasons) for the full list of rejection reason codes. ## Channel storage @@ -321,7 +321,7 @@ void Start() } ``` -`RejectedProp` includes a `message` with a human-readable description of the error, alongside the `error` code. See [Players and props - Prop rejection reasons](/docs/1.x/unity/player-props#prop-rejection-reasons) for the full list of rejection reason codes. +`RejectedProp` includes a `message` with a human-readable description of the error, alongside the `error` code. See [Players and props - Prop rejection reasons](/1.x/unity/player-props#prop-rejection-reasons) for the full list of rejection reason codes. ### Setting storage prop arrays @@ -444,7 +444,7 @@ This function will return a `ChannelStorageProp` array, allowing you to iterate #### Prop arrays -If any of the keys you pass are [prop arrays](/docs/1.x/unity/channels#getting-storage-prop-arrays), append `[]` to the key to fetch every item stored under it. Scalar and array keys can be mixed in a single call: +If any of the keys you pass are [prop arrays](/1.x/unity/channels#getting-storage-prop-arrays), append `[]` to the key to fetch every item stored under it. Scalar and array keys can be mixed in a single call: ```csharp // storage_prop_1 is a scalar, world_items[] is a prop array diff --git a/content/docs/1.x/unity/feedback.mdx b/content/docs/1.x/unity/feedback.mdx index f7d0f8c..0f37ab9 100644 --- a/content/docs/1.x/unity/feedback.mdx +++ b/content/docs/1.x/unity/feedback.mdx @@ -100,4 +100,4 @@ if (!result.Success) } ``` -See [Players and props - Prop rejection reasons](/docs/1.x/unity/player-props#prop-rejection-reasons) for the full list of rejection reason codes. +See [Players and props - Prop rejection reasons](/1.x/unity/player-props#prop-rejection-reasons) for the full list of rejection reason codes. diff --git a/content/docs/1.x/unity/identifying.mdx b/content/docs/1.x/unity/identifying.mdx index 810f919..f0e6bd8 100644 --- a/content/docs/1.x/unity/identifying.mdx +++ b/content/docs/1.x/unity/identifying.mdx @@ -50,7 +50,7 @@ You cannot use "Talo" for the `service` parameter as this is reserved for **Talo If you are using Talo Player Authentication, `Talo.Players.Identify()` will be invoked automatically and the `Talo.Players.OnIdentified` event will also invoke as normal. -Visit the [Player authentication docs](/docs/1.x/unity/player-authentication) to learn more about identifying players with authentication enabled. +Visit the [Player authentication docs](/1.x/unity/player-authentication) to learn more about identifying players with authentication enabled. @@ -166,7 +166,7 @@ In the example above, the two players created with `Talo.Players.Identify()` are page](https://dashboard.trytalo.com/integrations). -If you have the Steamworks integration enabled, Talo can sync a Steam player ([as described here](/docs/1.x/integrations/steamworks#authentication)). You can do this via the `Talo.Players.IdentifySteam` function. Here's a modified version of an example [provided by Unity](https://docs.unity.com/ugs/en-us/manual/authentication/manual/platform-signin-steam) using Steamworks.NET: +If you have the Steamworks integration enabled, Talo can sync a Steam player ([as described here](/1.x/integrations/steamworks#authentication)). You can do this via the `Talo.Players.IdentifySteam` function. Here's a modified version of an example [provided by Unity](https://docs.unity.com/ugs/en-us/manual/authentication/manual/platform-signin-steam) using Steamworks.NET: ```csharp Callback m_AuthTicketForWebApiResponseCallback; @@ -201,7 +201,7 @@ The `identity` parameter is optional but strongly recommended as it ensures prop ### Steamworks player props -After successfully authenticating the player, several [props](/docs/1.x/unity/player-props) will automatically be created for them: +After successfully authenticating the player, several [props](/1.x/unity/player-props) will automatically be created for them: - `META_STEAMWORKS_VAC_BANNED` - "true" or "false" - `META_STEAMWORKS_PUBLISHER_BANNED` - "true" or "false" @@ -256,7 +256,7 @@ PlayGamesPlatform.Instance.RequestServerSideAccess( ### Google Play Games player props -After successfully authenticating the player, these [props](/docs/1.x/unity/player-props) will automatically be created for them: +After successfully authenticating the player, these [props](/1.x/unity/player-props) will automatically be created for them: - `META_GOOGLE_PLAY_GAMES_DISPLAY_NAME` - The player's chosen display name - `META_GOOGLE_PLAY_GAMES_AVATAR_URL` - A direct link to the player's avatar @@ -333,7 +333,7 @@ If the `cachePlayerOnIdentify` setting is enabled (default `true`), Talo will st ## Display names -Every player alias has a `displayName` that provides a human-readable name for the player. You can read it from `Talo.CurrentAlias.displayName` after a player has been identified. Display names are resolved from a [player's props](/docs/1.x/unity/player-props) - arbitrary properties persisted across all of a player's aliases. +Every player alias has a `displayName` that provides a human-readable name for the player. You can read it from `Talo.CurrentAlias.displayName` after a player has been identified. Display names are resolved from a [player's props](/1.x/unity/player-props) - arbitrary properties persisted across all of a player's aliases. ```csharp title="WelcomeLabel.cs" using TaloGameServices; diff --git a/content/docs/1.x/unity/install.mdx b/content/docs/1.x/unity/install.mdx index c84e182..ad16d59 100644 --- a/content/docs/1.x/unity/install.mdx +++ b/content/docs/1.x/unity/install.mdx @@ -29,7 +29,7 @@ Once downloaded, you can open the `talo.unitypackage` file to import it into you Upgrading from an older version of the package? Read the [upgrading to 1.0 - guide](/docs/1.x/unity/upgrading-to-1.0) for the breaking changes. + guide](/1.x/unity/upgrading-to-1.0) for the breaking changes. ## Generate an API key @@ -54,4 +54,4 @@ If you're self-hosting Talo, you can configure your custom endpoint here in the ### Settings reference -You can visit the [settings reference](/docs/1.x/unity/settings-reference) for a detailed overview of Talo's configuration options. +You can visit the [settings reference](/1.x/unity/settings-reference) for a detailed overview of Talo's configuration options. diff --git a/content/docs/1.x/unity/leaderboards.mdx b/content/docs/1.x/unity/leaderboards.mdx index df05438..02a0374 100644 --- a/content/docs/1.x/unity/leaderboards.mdx +++ b/content/docs/1.x/unity/leaderboards.mdx @@ -130,7 +130,7 @@ if (!result.Success) } ``` -See [Players and props - Prop rejection reasons](/docs/1.x/unity/player-props#prop-rejection-reasons) for the full list of rejection reason codes. +See [Players and props - Prop rejection reasons](/1.x/unity/player-props#prop-rejection-reasons) for the full list of rejection reason codes. ## Getting entries diff --git a/content/docs/1.x/unity/live-config.mdx b/content/docs/1.x/unity/live-config.mdx index fdaf24a..f6468c7 100644 --- a/content/docs/1.x/unity/live-config.mdx +++ b/content/docs/1.x/unity/live-config.mdx @@ -77,4 +77,4 @@ void Start() } ``` -The `OnLiveConfigUpdated` event is invoked (via the [Talo Socket](/docs/1.x/socket)) whenever the live config is updated. +The `OnLiveConfigUpdated` event is invoked (via the [Talo Socket](/1.x/socket)) whenever the live config is updated. diff --git a/content/docs/1.x/unity/player-authentication.mdx b/content/docs/1.x/unity/player-authentication.mdx index 976c24a..951d26e 100644 --- a/content/docs/1.x/unity/player-authentication.mdx +++ b/content/docs/1.x/unity/player-authentication.mdx @@ -289,7 +289,7 @@ You can migrate a player's account to a different service and identifier using ` The original player auth account will be deleted and they will only be able to use their new identifier. -Here is an example of migrating to a [Steam alias](/docs/1.x/unity/identifying#steamworks-integration): +Here is an example of migrating to a [Steam alias](/1.x/unity/identifying#steamworks-integration): ```csharp Callback m_AuthTicketForWebApiResponseCallback; @@ -318,7 +318,7 @@ async void OnAuthCallback(GetTicketForWebApiResponse_t callback) } ``` -You can also migrate to the `google_play_games` service by providing an [auth code](/docs/1.x/unity/identifying#google-play-games-integration). +You can also migrate to the `google_play_games` service by providing an [auth code](/1.x/unity/identifying#google-play-games-integration). When a migration is successful, the current session is cleared, the player's alias is updated to the new service and identifier, and the `OnPlayerIdentified` event is invoked. @@ -328,4 +328,4 @@ As shown in the examples above, whenever a request fails with an authentication- The exception provides a `ErrorCode` property that returns a matching `PlayerAuthErrorCode` enum value for the error response. -You can view all the authentication errors and their descriptions [here](/docs/1.x/http/player-auth-api#error-codes). +You can view all the authentication errors and their descriptions [here](/1.x/http/player-auth-api#error-codes). diff --git a/content/docs/1.x/unity/player-props.mdx b/content/docs/1.x/unity/player-props.mdx index 0fe5a36..f659a08 100644 --- a/content/docs/1.x/unity/player-props.mdx +++ b/content/docs/1.x/unity/player-props.mdx @@ -51,7 +51,7 @@ private async void SearchPlayers() Players can have a list of arbitrary properties that are persisted across all of their aliases. These props are identified by their unique key and can have any string value. Keys can be up to 128 characters long and values can be up to 512 characters long. -All functions that modify props accept an optional `update` parameter (default `true`) that controls whether the player is synced with Talo after the change. They return an awaitable `Task`, and setting `update` to `false` returns a valid result without triggering a sync - use it to batch multiple changes and avoid redundant [debounces](/docs/1.x/unity/settings-reference#debouncetimerseconds). +All functions that modify props accept an optional `update` parameter (default `true`) that controls whether the player is synced with Talo after the change. They return an awaitable `Task`, and setting `update` to `false` returns a valid result without triggering a sync - use it to batch multiple changes and avoid redundant [debounces](/1.x/unity/settings-reference#debouncetimerseconds). ### Getting props diff --git a/content/docs/1.x/unity/player-relationships.mdx b/content/docs/1.x/unity/player-relationships.mdx index c8164db..69f9a86 100644 --- a/content/docs/1.x/unity/player-relationships.mdx +++ b/content/docs/1.x/unity/player-relationships.mdx @@ -33,7 +33,7 @@ A complete sample is available in the Unity package at `Assets/Talo Game Service To subscribe to a player, you need to first decide what type of relationship you want to create: unidirectional or bidirectional. Unidirectional relationships create a subscription to the target player and bidirectional relationships will create a reciprocal subscription between both players. -You also need to know the target player alias' ID. You can get this through [player presence updates](/docs/1.x/unity/player-presence), or by searching for players using [player search](/docs/1.x/unity/player-props#searching-for-players). +You also need to know the target player alias' ID. You can get this through [player presence updates](/1.x/unity/player-presence), or by searching for players using [player search](/1.x/unity/player-props#searching-for-players). Once you have both of these pieces of information, you can create the relationship: diff --git a/content/docs/1.x/unity/settings-reference.mdx b/content/docs/1.x/unity/settings-reference.mdx index e49a8e5..ac2a7f9 100644 --- a/content/docs/1.x/unity/settings-reference.mdx +++ b/content/docs/1.x/unity/settings-reference.mdx @@ -23,7 +23,7 @@ At a minimum, the Talo Unity package requires the `read:players` and `write:play ### apiUrl -This is the location of the Talo API. The default cloud version is `https://api.trytalo.com`. If you're [self-hosting Talo](/docs/1.x/selfhosting/overview), this should be the address of your `backend` container. +This is the location of the Talo API. The default cloud version is `https://api.trytalo.com`. If you're [self-hosting Talo](/1.x/selfhosting/overview), this should be the address of your `backend` container. ### socketUrl @@ -37,7 +37,7 @@ If enabled, the package will automatically connect to the Talo Socket when the g Talo uses the `OnApplicationQuit()` message to flush events before the game is closed. This is not available on the WebGL platform so a timer is used to flush events periodically instead. This setting controls how often events are flushed (in seconds). -Learn more about [event flushing here](/docs/1.x/unity/events#flushing). +Learn more about [event flushing here](/1.x/unity/events#flushing). ### cachePlayerOnIdentify @@ -45,11 +45,11 @@ If enabled, Talo will automatically cache the player after a successful online i ### continuityEnabled -If enabled, Talo will try to automatically replay failed network requests - [learn more about Continuity here](/docs/1.x/unity/continuity). +If enabled, Talo will try to automatically replay failed network requests - [learn more about Continuity here](/1.x/unity/continuity). ### autoStartSession -If enabled and a valid session token is found, the player will be automatically authenticated. This is documented on the [Player Authentication page](/docs/1.x/unity/player-authentication#automatic-logins). +If enabled and a valid session token is found, the player will be automatically authenticated. This is documented on the [Player Authentication page](/1.x/unity/player-authentication#automatic-logins). ### logRequests @@ -71,7 +71,7 @@ It is strongly recommended that you do not set this value below the default. A l ### verificationEnabled -Enable request verification to cryptographically sign requests and socket messages. This must also be enabled in the Talo dashboard. Learn more on the [Request verification page](/docs/1.x/unity/request-verification). +Enable request verification to cryptographically sign requests and socket messages. This must also be enabled in the Talo dashboard. Learn more on the [Request verification page](/1.x/unity/request-verification). ### verificationKeyVersion diff --git a/content/docs/1.x/unity/socket.mdx b/content/docs/1.x/unity/socket.mdx index abee849..8a196e0 100644 --- a/content/docs/1.x/unity/socket.mdx +++ b/content/docs/1.x/unity/socket.mdx @@ -11,7 +11,7 @@ Ideally you should never need to use the socket directly because individual serv The socket connection is automatically established (this can disabled by setting `autoConnectSocket` to `false` in your config). When a player gets identified, they also get automatically identified with the socket server. -You can learn more about how the socket works [here](/docs/1.x/sockets/intro). +You can learn more about how the socket works [here](/1.x/sockets/intro). ## Obtaining a socket ticket @@ -23,7 +23,7 @@ Opening a socket connection using `Talo.Socket.OpenConnection()` will automatica ## Receiving messages -The `OnMessageReceived` event provides you with a [response](/docs/1.x/sockets/responses) and payload. For example, if you were building a chat system, you would connect a function similar to the one below to listen for new chat messages: +The `OnMessageReceived` event provides you with a [response](/1.x/sockets/responses) and payload. For example, if you were building a chat system, you would connect a function similar to the one below to listen for new chat messages: ```csharp private void Start() @@ -51,7 +51,7 @@ private void OnMessageReceived(SocketResponse response) ## Sending messages -Sending messages is handled by functions in services like `Talo.Channels.SendMessage()` where the correct data is prepared and sent for you. You can also use the `Talo.Socket.Send()` function to send your own [requests](/docs/1.x/sockets/requests): +Sending messages is handled by functions in services like `Talo.Channels.SendMessage()` where the correct data is prepared and sent for you. You can also use the `Talo.Socket.Send()` function to send your own [requests](/1.x/sockets/requests): ```csharp public void SendMessage(int channelId, string message) @@ -72,7 +72,7 @@ public void SendMessage(int channelId, string message) -The socket server can disconnect for a number of reasons such as the player going offline or being [rate limited](/docs/1.x/sockets/common-errors#rate-limit-exceeded). The socket will invoke a `OnConnectionClosed` event with a status code and reason. +The socket server can disconnect for a number of reasons such as the player going offline or being [rate limited](/1.x/sockets/common-errors#rate-limit-exceeded). The socket will invoke a `OnConnectionClosed` event with a status code and reason. The Talo socket automatically reconnects when the [connection is restored](continuity#onconnectionrestored). If you need to manually re-open the socket, you can establish a connection and re-identify the player like this: @@ -94,7 +94,7 @@ You can choose to manually end the socket connection using `Talo.Socket.CloseCon ## Request verification -If your game has [request verification](/docs/1.x/unity/request-verification) enabled, socket messages are automatically signed for players. The server validates these signatures to prevent replay attacks and tampering. +If your game has [request verification](/1.x/unity/request-verification) enabled, socket messages are automatically signed for players. The server validates these signatures to prevent replay attacks and tampering. ## Error handling diff --git a/content/docs/index.mdx b/content/docs/index.mdx index bd16c15..b3ebe3d 100644 --- a/content/docs/index.mdx +++ b/content/docs/index.mdx @@ -6,13 +6,13 @@ title: Talo overview ## Choose your adventure - - - - - - - + + + + + + + ## Everything you need in one place diff --git a/content/docs/pre-1.0/godot/channels.mdx b/content/docs/pre-1.0/godot/channels.mdx index 2b1060d..a619c23 100644 --- a/content/docs/pre-1.0/godot/channels.mdx +++ b/content/docs/pre-1.0/godot/channels.mdx @@ -285,7 +285,7 @@ func _on_channel_props_rejected(rejected_props: Array[TaloRejectedProp]) -> void **storage** prop errors, use `channel_storage_props_failed_to_set` instead. -See [Players and props - Prop rejection reasons](/docs/pre-1.0/godot/player-props#prop-rejection-reasons) for the full list of rejection reason codes. +See [Players and props - Prop rejection reasons](/pre-1.0/godot/player-props#prop-rejection-reasons) for the full list of rejection reason codes. ## Channel storage @@ -324,7 +324,7 @@ func _ready() -> void: ) ``` -`TaloChannelStoragePropError` includes a `message` with a human-readable description of the error, alongside the `error` code. See [Players and props - Prop rejection reasons](/docs/pre-1.0/godot/player-props#prop-rejection-reasons) for the full list of rejection reason codes. +`TaloChannelStoragePropError` includes a `message` with a human-readable description of the error, alongside the `error` code. See [Players and props - Prop rejection reasons](/pre-1.0/godot/player-props#prop-rejection-reasons) for the full list of rejection reason codes. ### Setting storage prop arrays @@ -442,7 +442,7 @@ This function will return a `TaloChannelStorageProp` array, allowing you to iter #### Prop arrays -If any of the keys you pass are [prop arrays](/docs/pre-1.0/godot/channels#getting-storage-prop-arrays), append `[]` to the key to fetch every item stored under it. Scalar and array keys can be mixed in a single call: +If any of the keys you pass are [prop arrays](/pre-1.0/godot/channels#getting-storage-prop-arrays), append `[]` to the key to fetch every item stored under it. Scalar and array keys can be mixed in a single call: ```gdscript # storage_prop_1 is a scalar, world_items[] is a prop array diff --git a/content/docs/pre-1.0/godot/feedback.mdx b/content/docs/pre-1.0/godot/feedback.mdx index e8835b9..076f1c5 100644 --- a/content/docs/pre-1.0/godot/feedback.mdx +++ b/content/docs/pre-1.0/godot/feedback.mdx @@ -77,4 +77,4 @@ func _on_props_rejected(rejected_props: Array[TaloRejectedProp]) -> void: print("Rejected prop '%s': %s (%s)" % [prop.key, prop.message, prop.error]) ``` -See [Players and props - Prop rejection reasons](/docs/pre-1.0/godot/player-props#prop-rejection-reasons) for the full list of rejection reason codes. +See [Players and props - Prop rejection reasons](/pre-1.0/godot/player-props#prop-rejection-reasons) for the full list of rejection reason codes. diff --git a/content/docs/pre-1.0/godot/identifying.mdx b/content/docs/pre-1.0/godot/identifying.mdx index 4c91fe2..e887a9b 100644 --- a/content/docs/pre-1.0/godot/identifying.mdx +++ b/content/docs/pre-1.0/godot/identifying.mdx @@ -34,7 +34,7 @@ You cannot use "Talo" for the `service` parameter as this is reserved for **Talo If you are using Talo Player Authentication, `Talo.players.identify()` will be invoked automatically and the `Talo.players.identified` signal will also emit as normal. -Visit the [Player authentication docs](/docs/pre-1.0/godot/player-authentication) to learn more about identifying players with authentication enabled. +Visit the [Player authentication docs](/pre-1.0/godot/player-authentication) to learn more about identifying players with authentication enabled. @@ -130,7 +130,7 @@ In the example above, the two players created with `Talo.players.identify()` are page](https://dashboard.trytalo.com/integrations). -If you have the Steamworks integration enabled, Talo can sync a Steam player ([as described here](/docs/pre-1.0/integrations/steamworks#authentication)). You can do this via the `Talo.players.identify_steam` function. Here's an example using [GodotSteam](https://godotsteam.com): +If you have the Steamworks integration enabled, Talo can sync a Steam player ([as described here](/pre-1.0/integrations/steamworks#authentication)). You can do this via the `Talo.players.identify_steam` function. Here's an example using [GodotSteam](https://godotsteam.com): ```gdscript extends Node @@ -153,7 +153,7 @@ The `identity` parameter is optional but strongly recommended as it ensures prop ### Steamworks player props -After successfully authenticating the player, several [props](/docs/pre-1.0/godot/player-props) will automatically be created for them: +After successfully authenticating the player, several [props](/pre-1.0/godot/player-props) will automatically be created for them: - `META_STEAMWORKS_VAC_BANNED` - "true" or "false" - `META_STEAMWORKS_PUBLISHER_BANNED` - "true" or "false" @@ -205,7 +205,7 @@ Replace "yourid.apps.googleusercontent.com" with the client ID you generated ear ### Google Play Games player props -After successfully authenticating the player, these [props](/docs/pre-1.0/godot/player-props) will automatically be created for them: +After successfully authenticating the player, these [props](/pre-1.0/godot/player-props) will automatically be created for them: - `META_GOOGLE_PLAY_GAMES_DISPLAY_NAME` - The player's chosen display name - `META_GOOGLE_PLAY_GAMES_AVATAR_URL` - A direct link to the player's avatar @@ -292,7 +292,7 @@ This function will return the identifier (if one exists) or an empty string. If ## Display names -Every player alias has a `display_name` that provides a human-readable name for the player. You can read it from `Talo.current_alias.display_name` after a player has been identified. Display names are resolved from a [player's props](/docs/pre-1.0/godot/player-props) - arbitrary properties persisted across all of a player's aliases. +Every player alias has a `display_name` that provides a human-readable name for the player. You can read it from `Talo.current_alias.display_name` after a player has been identified. Display names are resolved from a [player's props](/pre-1.0/godot/player-props) - arbitrary properties persisted across all of a player's aliases. ```gdscript title="welcome_label.gd" extends Label diff --git a/content/docs/pre-1.0/godot/install.mdx b/content/docs/pre-1.0/godot/install.mdx index a3f44c6..b981100 100644 --- a/content/docs/pre-1.0/godot/install.mdx +++ b/content/docs/pre-1.0/godot/install.mdx @@ -62,4 +62,4 @@ If you're self-hosting Talo, you can configure your custom endpoint here in the ### Settings reference -You can visit the [settings reference](/docs/pre-1.0/godot/settings-reference) for a detailed overview of Talo's configuration options. +You can visit the [settings reference](/pre-1.0/godot/settings-reference) for a detailed overview of Talo's configuration options. diff --git a/content/docs/pre-1.0/godot/leaderboards.mdx b/content/docs/pre-1.0/godot/leaderboards.mdx index a28b641..acc14f7 100644 --- a/content/docs/pre-1.0/godot/leaderboards.mdx +++ b/content/docs/pre-1.0/godot/leaderboards.mdx @@ -108,7 +108,7 @@ func _on_props_rejected(rejected_props: Array[TaloRejectedProp]) -> void: print("Rejected prop '%s': %s (%s)" % [prop.key, prop.message, prop.error]) ``` -See [Players and props - Prop rejection reasons](/docs/pre-1.0/godot/player-props#prop-rejection-reasons) for the full list of rejection reason codes. +See [Players and props - Prop rejection reasons](/pre-1.0/godot/player-props#prop-rejection-reasons) for the full list of rejection reason codes. ## Getting entries diff --git a/content/docs/pre-1.0/godot/live-config.mdx b/content/docs/pre-1.0/godot/live-config.mdx index e928012..0800abd 100644 --- a/content/docs/pre-1.0/godot/live-config.mdx +++ b/content/docs/pre-1.0/godot/live-config.mdx @@ -58,4 +58,4 @@ func _on_live_config_updated(live_config: TaloLiveConfig) -> void: label.text = live_config.get_prop("live_string", "Not set!") ``` -The `live_config_updated` signal is emitted (via the [Talo Socket](/docs/pre-1.0/socket)) whenever the live config is updated. +The `live_config_updated` signal is emitted (via the [Talo Socket](/pre-1.0/socket)) whenever the live config is updated. diff --git a/content/docs/pre-1.0/godot/player-authentication.mdx b/content/docs/pre-1.0/godot/player-authentication.mdx index 000db62..5deca72 100644 --- a/content/docs/pre-1.0/godot/player-authentication.mdx +++ b/content/docs/pre-1.0/godot/player-authentication.mdx @@ -249,7 +249,7 @@ You can migrate a player's account to a different service and identifier using ` The original player auth account will be deleted and they will only be able to use their new identifier. -Here is an example of migrating to a [Steam alias](/docs/pre-1.0/godot/identifying#steamworks-integration): +Here is an example of migrating to a [Steam alias](/pre-1.0/godot/identifying#steamworks-integration): ```gdscript @onready var current_password: TextEdit = %CurrentPassword @@ -274,7 +274,7 @@ func _migrate_account(ticket: String) -> void: validation_label.text = Talo.player_auth.last_error.get_string() ``` -You can also migrate to the `google_play_games` service by providing an [auth code](/docs/pre-1.0/godot/identifying#google-play-games-integration). +You can also migrate to the `google_play_games` service by providing an [auth code](/pre-1.0/godot/identifying#google-play-games-integration). When a migration is successful, the current session is cleared, the player's alias is updated to the new service and identifier, and the `Talo.players.identified` signal is emitted. @@ -284,4 +284,4 @@ As shown in the examples above, whenever a request fails you can query the last You can get the `TaloAuthError.ErrorCode` enum value using the `get_code()` function or the raw string using the `get_string()` function. -You can view all the authentication errors and their descriptions [here](/docs/pre-1.0/http/player-auth-api#error-codes). +You can view all the authentication errors and their descriptions [here](/pre-1.0/http/player-auth-api#error-codes). diff --git a/content/docs/pre-1.0/godot/player-props.mdx b/content/docs/pre-1.0/godot/player-props.mdx index 1e85160..0b5e58b 100644 --- a/content/docs/pre-1.0/godot/player-props.mdx +++ b/content/docs/pre-1.0/godot/player-props.mdx @@ -37,7 +37,7 @@ print("Found %s results: %s" % [search_page.count, ", ".join(identifiers)]) Players can have a list of arbitrary properties that are persisted across all of their aliases. These props are identified by their unique key and can have any string value. Keys can be up to 128 characters long and values can be up to 512 characters long. -All functions that modify props accept an optional `update` parameter (default `true`) that controls whether the player is synced with Talo after the change. Set it to `false` to batch multiple changes and avoid redundant [debounces](/docs/pre-1.0/godot/settings-reference#debounce_timer_seconds). +All functions that modify props accept an optional `update` parameter (default `true`) that controls whether the player is synced with Talo after the change. Set it to `false` to batch multiple changes and avoid redundant [debounces](/pre-1.0/godot/settings-reference#debounce_timer_seconds). ### Getting props diff --git a/content/docs/pre-1.0/godot/player-relationships.mdx b/content/docs/pre-1.0/godot/player-relationships.mdx index 13f1e0a..f4bd5f0 100644 --- a/content/docs/pre-1.0/godot/player-relationships.mdx +++ b/content/docs/pre-1.0/godot/player-relationships.mdx @@ -33,7 +33,7 @@ A complete sample is available in the Godot plugin at `addons/talo/samples/frien To subscribe to a player, you need to first decide what type of relationship you want to create: unidirectional or bidirectional. Unidirectional relationships create a subscription to the target player and bidirectional relationships will create a reciprocal subscription between both players. -You also need to know the target player alias' ID. You can get this through [player presence updates](/docs/pre-1.0/godot/player-presence), or by searching for players using [player search](/docs/pre-1.0/godot/player-props#searching-for-players). +You also need to know the target player alias' ID. You can get this through [player presence updates](/pre-1.0/godot/player-presence), or by searching for players using [player search](/pre-1.0/godot/player-props#searching-for-players). Once you have both of these pieces of information, you can create the relationship: diff --git a/content/docs/pre-1.0/godot/settings-reference.mdx b/content/docs/pre-1.0/godot/settings-reference.mdx index ef3474e..dc8f899 100644 --- a/content/docs/pre-1.0/godot/settings-reference.mdx +++ b/content/docs/pre-1.0/godot/settings-reference.mdx @@ -38,7 +38,7 @@ At a minimum, the Talo Godot plugin requires the `read:players` and `write:playe ### api_url -This is the location of the Talo API. The default cloud version is `https://api.trytalo.com`. If you're [self-hosting Talo](/docs/pre-1.0/selfhosting/overview), this should be the address of your `backend` container. +This is the location of the Talo API. The default cloud version is `https://api.trytalo.com`. If you're [self-hosting Talo](/pre-1.0/selfhosting/overview), this should be the address of your `backend` container. ### socket_url @@ -77,11 +77,11 @@ If enabled, Talo will automatically cache the player after a successful online i ### continuity.enabled -If enabled, Talo will try to automatically replay failed network requests - [learn more about Continuity here](/docs/pre-1.0/godot/continuity). +If enabled, Talo will try to automatically replay failed network requests - [learn more about Continuity here](/pre-1.0/godot/continuity). ### player_auth.auto_start_session -If enabled and a valid session token is found, the player will be automatically authenticated. This is documented on the [Player Authentication page](/docs/pre-1.0/godot/player-authentication#automatic-logins). +If enabled and a valid session token is found, the player will be automatically authenticated. This is documented on the [Player Authentication page](/pre-1.0/godot/player-authentication#automatic-logins). ### logging.requests @@ -103,7 +103,7 @@ It is strongly recommended that you do not set this value below the default. A l ### verification.enabled -Enable request verification to cryptographically sign requests and socket messages. This must also be enabled in the Talo dashboard. Learn more on the [Request verification page](/docs/pre-1.0/godot/request-verification). +Enable request verification to cryptographically sign requests and socket messages. This must also be enabled in the Talo dashboard. Learn more on the [Request verification page](/pre-1.0/godot/request-verification). ### verification.key_version diff --git a/content/docs/pre-1.0/godot/socket.mdx b/content/docs/pre-1.0/godot/socket.mdx index f5d4e8e..d24845b 100644 --- a/content/docs/pre-1.0/godot/socket.mdx +++ b/content/docs/pre-1.0/godot/socket.mdx @@ -11,7 +11,7 @@ Ideally you should never need to use the socket directly because individual serv The socket connection is automatically established (this can disabled by setting `auto_connect_socket` to `false` in your config). When a player gets identified, they also get automatically identified with the socket server. -You can learn more about how the socket works [here](/docs/pre-1.0/sockets/intro). +You can learn more about how the socket works [here](/pre-1.0/sockets/intro). ## Obtaining a socket ticket @@ -23,7 +23,7 @@ Opening a socket connection using `Talo.socket.open_connection()` will automatic ## Receiving messages -The `message_received` signal provides you with a [response](/docs/pre-1.0/sockets/responses) and payload. For example, if you were building a chat system, you would connect a function similar to the one below to listen for new chat messages: +The `message_received` signal provides you with a [response](/pre-1.0/sockets/responses) and payload. For example, if you were building a chat system, you would connect a function similar to the one below to listen for new chat messages: ```gdscript func _ready() -> void: @@ -38,7 +38,7 @@ func _on_message_received(res: String, data: Dictionary) -> void: ## Sending messages -Sending messages is handled by functions in services like `Talo.channels.send_message()` where the correct data is prepared and sent for you. You can also use the `Talo.socket.send(req, data)` function to send your own [requests](/docs/pre-1.0/sockets/requests): +Sending messages is handled by functions in services like `Talo.channels.send_message()` where the correct data is prepared and sent for you. You can also use the `Talo.socket.send(req, data)` function to send your own [requests](/pre-1.0/sockets/requests): ```gdscript func send_message(channel_id: int, message: String) -> void: @@ -57,7 +57,7 @@ func send_message(channel_id: int, message: String) -> void: -The socket server can disconnect for a number of reasons such as the player going offline or being [rate limited](/docs/pre-1.0/sockets/common-errors#rate-limit-exceeded). The socket will emit a `connection_closed` signal with a status code and reason. +The socket server can disconnect for a number of reasons such as the player going offline or being [rate limited](/pre-1.0/sockets/common-errors#rate-limit-exceeded). The socket will emit a `connection_closed` signal with a status code and reason. The Talo socket automatically reconnects when the [connection is restored](continuity#connection_restored). If you need to manually re-open the socket, you can establish a connection and re-identify the player like this: @@ -75,7 +75,7 @@ You can choose to manually end the socket connection using `Talo.socket.close_co ## Request verification -If your game has [request verification](/docs/pre-1.0/godot/request-verification) enabled, socket messages are automatically signed for players. The server validates these signatures to prevent replay attacks and tampering. +If your game has [request verification](/pre-1.0/godot/request-verification) enabled, socket messages are automatically signed for players. The server validates these signatures to prevent replay attacks and tampering. ## Error handling diff --git a/content/docs/pre-1.0/http/authentication.mdx b/content/docs/pre-1.0/http/authentication.mdx index 40730ae..afb35ee 100644 --- a/content/docs/pre-1.0/http/authentication.mdx +++ b/content/docs/pre-1.0/http/authentication.mdx @@ -28,15 +28,15 @@ Most endpoints perform actions on behalf of players.If you are using [player aut The Godot plugin and Unity package will automatically populate these headers for you. If you're receiving session-related errors, visit the [Common - errors](/docs/pre-1.0/http/common-errors#missing-or-invalid-session) page for more information. + errors](/pre-1.0/http/common-errors#missing-or-invalid-session) page for more information. ### Session token lifetimes -By default, session tokens returned by [register, login, verify, and refresh](/docs/pre-1.0/http/player-auth-api) are long-lived and do not need to be renewed. Your game can store the token on the device and reuse it for as long as the player keeps playing. +By default, session tokens returned by [register, login, verify, and refresh](/pre-1.0/http/player-auth-api) are long-lived and do not need to be renewed. Your game can store the token on the device and reuse it for as long as the player keeps playing. If you prefer shorter-lived sessions, you can opt in to the refresh token flow using the `withRefresh` parameter. When enabled: - The session token expires after **15 minutes**. - A **30-day refresh token** is returned alongside it. -- Call the [refresh session](/docs/pre-1.0/http/player-auth-api) endpoint with the refresh token to receive a new session and refresh token. +- Call the [refresh session](/pre-1.0/http/player-auth-api) endpoint with the refresh token to receive a new session and refresh token. diff --git a/content/docs/pre-1.0/http/bruno-collection.mdx b/content/docs/pre-1.0/http/bruno-collection.mdx index f9ca2a5..18535b5 100644 --- a/content/docs/pre-1.0/http/bruno-collection.mdx +++ b/content/docs/pre-1.0/http/bruno-collection.mdx @@ -44,12 +44,12 @@ Most player-scoped endpoints expect two headers in addition to the API key: 1. `x-talo-player` - the player's ID 2. `x-talo-alias` - the ID of one of the player's identified alias -To get these, run the [Identify](/docs/pre-1.0/http/player-api) endpoint first (found in the **Players** folder of the collection). This will automatically set the variables for both of those headers. +To get these, run the [Identify](/pre-1.0/http/player-api) endpoint first (found in the **Players** folder of the collection). This will automatically set the variables for both of those headers. ### Talo player authentication -If your game uses [Talo's player authentication](/docs/pre-1.0/http/player-auth-api), you'll also need the `x-talo-session` header. +If your game uses [Talo's player authentication](/pre-1.0/http/player-auth-api), you'll also need the `x-talo-session` header. Run the **register** and **login** requests (from the **Player auth** folder). This will set the `x-talo-session` variable and refresh token variable (for refreshing the short-lived session token). -See [Player authentication](/docs/pre-1.0/http/authentication#player-authentication) for the full flow. +See [Player authentication](/pre-1.0/http/authentication#player-authentication) for the full flow. diff --git a/content/docs/pre-1.0/http/player-auth-api.mdx b/content/docs/pre-1.0/http/player-auth-api.mdx index 421e1f6..028931d 100644 --- a/content/docs/pre-1.0/http/player-auth-api.mdx +++ b/content/docs/pre-1.0/http/player-auth-api.mdx @@ -28,7 +28,7 @@ Learn more about player authentication [here](https://trytalo.com/players#authen ## Identifying players using Talo Authentication -Once you have registered a player, you can identify them using the [identify](/docs/pre-1.0/http/player-api) endpoint. You will need to ensure that: +Once you have registered a player, you can identify them using the [identify](/pre-1.0/http/player-api) endpoint. You will need to ensure that: 1. The `identifier` is the one you used to register the player (email, username, etc.) 2. The `service` is set to `talo` @@ -39,7 +39,7 @@ To create a new session token, you will need to go through the login flow again By default session tokens are long-lived. You can opt in to short-lived (15-minute) session tokens paired with a 30-day refresh token using the `withRefresh` parameter. See [Session token - lifetimes](/docs/pre-1.0/http/authentication#session-token-lifetimes) for the full details. + lifetimes](/pre-1.0/http/authentication#session-token-lifetimes) for the full details. ## Endpoints diff --git a/content/docs/pre-1.0/http/request-verification.mdx b/content/docs/pre-1.0/http/request-verification.mdx index 36615ac..68313db 100644 --- a/content/docs/pre-1.0/http/request-verification.mdx +++ b/content/docs/pre-1.0/http/request-verification.mdx @@ -94,7 +94,7 @@ You can then send the signature in the `x-talo-signature` header alongside your Enabling request verification also enables verification for socket messages. -See the [socket request verification docs](/docs/pre-1.0/sockets/request-verification) for details on how to prepend the signature to the message payload. +See the [socket request verification docs](/pre-1.0/sockets/request-verification) for details on how to prepend the signature to the message payload. ## When verification applies diff --git a/content/docs/pre-1.0/http/socket-ticket-api.mdx b/content/docs/pre-1.0/http/socket-ticket-api.mdx index 5922a96..0f2f2c6 100644 --- a/content/docs/pre-1.0/http/socket-ticket-api.mdx +++ b/content/docs/pre-1.0/http/socket-ticket-api.mdx @@ -18,7 +18,7 @@ export const pageToc = [ Talo provides a secure socket system for real-time communication between your game and players. The Talo Socket powers services like [channels](https://trytalo.com/channels?utm_source=socket-docs&utm_medium=api-docs) and [player relationships](https://trytalo.com/player-relationships?utm_source=socket-docs&utm_medium=api-docs). -To connect to the socket server, you need to obtain a socket ticket. Learn more about socket authentication [here](/docs/pre-1.0/sockets/intro#authentication). +To connect to the socket server, you need to obtain a socket ticket. Learn more about socket authentication [here](/pre-1.0/sockets/intro#authentication). ## Endpoints diff --git a/content/docs/pre-1.0/index.mdx b/content/docs/pre-1.0/index.mdx index bbe4096..12336dc 100644 --- a/content/docs/pre-1.0/index.mdx +++ b/content/docs/pre-1.0/index.mdx @@ -6,23 +6,23 @@ title: Talo overview This is the archived documentation for Talo releases before the 1.0 update. These docs cover the Talo Godot plugin ≤ 0.49.0 and the Talo Unity package ≤ 0.60.0. -If you're migrating to the latest version, see the [Godot upgrade guide](/docs/1.x/godot/upgrading-to-1.0) or [Unity upgrade guide](/docs/1.x/unity/upgrading-to-1.0). +If you're migrating to the latest version, see the [Godot upgrade guide](/1.x/godot/upgrading-to-1.0) or [Unity upgrade guide](/1.x/unity/upgrading-to-1.0). ## Choose your adventure - + - + - + - + - + - + diff --git a/content/docs/pre-1.0/integrations/apple-game-center.mdx b/content/docs/pre-1.0/integrations/apple-game-center.mdx index abd4911..06e299f 100644 --- a/content/docs/pre-1.0/integrations/apple-game-center.mdx +++ b/content/docs/pre-1.0/integrations/apple-game-center.mdx @@ -17,4 +17,4 @@ To get started, enter your app's Bundle ID into the dashboard. Talo will use thi To identify a player, fetch the local player's identity verification signature from Game Center and pass the values to Talo. Talo will cryptographically verify the signature against Apple's public key and automatically identify the player without them needing to create an account. -Check out the [Godot plugin docs](/docs/pre-1.0/godot/identifying#apple-game-center-integration) or [Unity package docs](/docs/pre-1.0/unity/identifying#apple-game-center-integration) for more details. +Check out the [Godot plugin docs](/pre-1.0/godot/identifying#apple-game-center-integration) or [Unity package docs](/pre-1.0/unity/identifying#apple-game-center-integration) for more details. diff --git a/content/docs/pre-1.0/integrations/google-play-games.mdx b/content/docs/pre-1.0/integrations/google-play-games.mdx index 4a43ba8..7963680 100644 --- a/content/docs/pre-1.0/integrations/google-play-games.mdx +++ b/content/docs/pre-1.0/integrations/google-play-games.mdx @@ -19,4 +19,4 @@ To identify a player, [request a server auth code](https://developer.android.com Talo will also add helpful `props` to your player such as their display name and avatar URL. -Check out the [Godot plugin docs](/docs/pre-1.0/godot/identifying#google-play-games-integration) or [Unity package docs](/docs/pre-1.0/unity/identifying#google-play-games-integration) for more details. +Check out the [Godot plugin docs](/pre-1.0/godot/identifying#google-play-games-integration) or [Unity package docs](/pre-1.0/unity/identifying#google-play-games-integration) for more details. diff --git a/content/docs/pre-1.0/integrations/steamworks.mdx b/content/docs/pre-1.0/integrations/steamworks.mdx index 7f691dc..d0fba7d 100644 --- a/content/docs/pre-1.0/integrations/steamworks.mdx +++ b/content/docs/pre-1.0/integrations/steamworks.mdx @@ -19,7 +19,7 @@ You'll need to pass the ticket generated by the [GetAuthTicketForWebApi](https:/ Talo will also add helpful `props` to your player such as app ownership details, profile names and avatars. -Check out the [Godot plugin docs](/docs/pre-1.0/godot/identifying#steamworks-integration) or [Unity package docs](/docs/pre-1.0/unity/identifying#steamworks-integration) for more details. +Check out the [Godot plugin docs](/pre-1.0/godot/identifying#steamworks-integration) or [Unity package docs](/pre-1.0/unity/identifying#steamworks-integration) for more details. ## Leaderboards diff --git a/content/docs/pre-1.0/sockets/common-errors.mdx b/content/docs/pre-1.0/sockets/common-errors.mdx index 7a7af06..ab20033 100644 --- a/content/docs/pre-1.0/sockets/common-errors.mdx +++ b/content/docs/pre-1.0/sockets/common-errors.mdx @@ -4,7 +4,7 @@ title: Common errors ## Missing authentication -A valid socket ticket is required when opening a socket connection. Learn more about how to obtain a socket ticket and connect to the socket server [here](/docs/pre-1.0/intro#connecting-to-the-socket-server). +A valid socket ticket is required when opening a socket connection. Learn more about how to obtain a socket ticket and connect to the socket server [here](/pre-1.0/intro#connecting-to-the-socket-server). Connections without a valid ticket will be closed immediately. @@ -129,7 +129,7 @@ A request listener can throw an error specific to its own internal logic. These } ``` -If your game has [request verification](/docs/pre-1.0/sockets/request-verification) enabled, all socket messages sent after identifying a player must include a valid signature. If the signature is missing, malformed or fails Talo's validation, you will receive this error. +If your game has [request verification](/pre-1.0/sockets/request-verification) enabled, all socket messages sent after identifying a player must include a valid signature. If the signature is missing, malformed or fails Talo's validation, you will receive this error. ## Rate limit exceeded diff --git a/content/docs/pre-1.0/sockets/intro.mdx b/content/docs/pre-1.0/sockets/intro.mdx index cea05a0..10ed603 100644 --- a/content/docs/pre-1.0/sockets/intro.mdx +++ b/content/docs/pre-1.0/sockets/intro.mdx @@ -7,7 +7,7 @@ title: Socket basics The socket used by Talo follows the web socket standard and is compatible with libraries that also do the same. -One major difference is that the Talo Socket will validate messages against a request type and payload structure. For example, if you send a message with the `v1.players.identified` request, your payload's data must also match the expected schema. The list of available [requests](/docs/pre-1.0/requests) and [responses](/docs/pre-1.0/responses) are available on their respective pages. +One major difference is that the Talo Socket will validate messages against a request type and payload structure. For example, if you send a message with the `v1.players.identified` request, your payload's data must also match the expected schema. The list of available [requests](/pre-1.0/requests) and [responses](/pre-1.0/responses) are available on their respective pages. Using the identification example, here is the JSON expected by the Talo Socket when identifying a player: @@ -51,7 +51,7 @@ Responses use a similar message structure, except that `req` is replaced by `res The Talo Socket provides two layers of authentication: -1. You must provide a [socket ticket](/docs/pre-1.0/http/socket-ticket-api) when opening a socket connection. This identifies your game and the key's scopes are used to determine whether a client is eligible to receive specific responses. +1. You must provide a [socket ticket](/pre-1.0/http/socket-ticket-api) when opening a socket connection. This identifies your game and the key's scopes are used to determine whether a client is eligible to receive specific responses. 2. When players are identified, a `socketToken` is stored against the player alias for 1 hour. While the socket token is valid, you can use it to authenticate your player with the socket. @@ -72,7 +72,7 @@ The default socket URL is `wss://api.trytalo.com`. When opening a socket connect wss://api.trytalo.com/socket?ticket=your-ticket-here ``` -Your ticket should be a valid socket ticket, i.e. it was created within the last 5 minutes. Visit the [API docs](/docs/pre-1.0/http/socket-ticket-api) for more information on how to obtain a socket ticket. +Your ticket should be a valid socket ticket, i.e. it was created within the last 5 minutes. Visit the [API docs](/pre-1.0/http/socket-ticket-api) for more information on how to obtain a socket ticket. ## Error responses @@ -103,4 +103,4 @@ Some errors may also return a "cause" key which drills down into why a request f } ``` -For a more detailed look into the available error codes, visit the [common errors](/docs/pre-1.0/common-errors) page. +For a more detailed look into the available error codes, visit the [common errors](/pre-1.0/common-errors) page. diff --git a/content/docs/pre-1.0/unity/channels.mdx b/content/docs/pre-1.0/unity/channels.mdx index 9a039d1..fbb7646 100644 --- a/content/docs/pre-1.0/unity/channels.mdx +++ b/content/docs/pre-1.0/unity/channels.mdx @@ -268,7 +268,7 @@ private void OnChannelPropsRejected(RejectedProp[] rejectedProps) **storage** prop errors, use `OnChannelStoragePropsFailedToSet` instead. -See [Players and props - Prop rejection reasons](/docs/pre-1.0/unity/player-props#prop-rejection-reasons) for the full list of rejection reason codes. +See [Players and props - Prop rejection reasons](/pre-1.0/unity/player-props#prop-rejection-reasons) for the full list of rejection reason codes. ## Channel storage @@ -311,7 +311,7 @@ void Start() } ``` -`ChannelStoragePropError` includes a `message` with a human-readable description of the error, alongside the `error` code. See [Players and props - Prop rejection reasons](/docs/pre-1.0/unity/player-props#prop-rejection-reasons) for the full list of rejection reason codes. +`ChannelStoragePropError` includes a `message` with a human-readable description of the error, alongside the `error` code. See [Players and props - Prop rejection reasons](/pre-1.0/unity/player-props#prop-rejection-reasons) for the full list of rejection reason codes. ### Setting storage prop arrays @@ -434,7 +434,7 @@ This function will return a `ChannelStorageProp` array, allowing you to iterate #### Prop arrays -If any of the keys you pass are [prop arrays](/docs/pre-1.0/unity/channels#getting-storage-prop-arrays), append `[]` to the key to fetch every item stored under it. Scalar and array keys can be mixed in a single call: +If any of the keys you pass are [prop arrays](/pre-1.0/unity/channels#getting-storage-prop-arrays), append `[]` to the key to fetch every item stored under it. Scalar and array keys can be mixed in a single call: ```csharp // storage_prop_1 is a scalar, world_items[] is a prop array diff --git a/content/docs/pre-1.0/unity/feedback.mdx b/content/docs/pre-1.0/unity/feedback.mdx index 5a1f1e4..919da1a 100644 --- a/content/docs/pre-1.0/unity/feedback.mdx +++ b/content/docs/pre-1.0/unity/feedback.mdx @@ -107,4 +107,4 @@ private void OnPropsRejected(RejectedProp[] rejectedProps) } ``` -See [Players and props - Prop rejection reasons](/docs/pre-1.0/unity/player-props#prop-rejection-reasons) for the full list of rejection reason codes. +See [Players and props - Prop rejection reasons](/pre-1.0/unity/player-props#prop-rejection-reasons) for the full list of rejection reason codes. diff --git a/content/docs/pre-1.0/unity/identifying.mdx b/content/docs/pre-1.0/unity/identifying.mdx index 415a755..bfb4d95 100644 --- a/content/docs/pre-1.0/unity/identifying.mdx +++ b/content/docs/pre-1.0/unity/identifying.mdx @@ -50,7 +50,7 @@ You cannot use "Talo" for the `service` parameter as this is reserved for **Talo If you are using Talo Player Authentication, `Talo.Players.Identify()` will be invoked automatically and the `Talo.Players.OnIdentified` event will also invoke as normal. -Visit the [Player authentication docs](/docs/pre-1.0/unity/player-authentication) to learn more about identifying players with authentication enabled. +Visit the [Player authentication docs](/pre-1.0/unity/player-authentication) to learn more about identifying players with authentication enabled. @@ -166,7 +166,7 @@ In the example above, the two players created with `Talo.Players.Identify()` are page](https://dashboard.trytalo.com/integrations). -If you have the Steamworks integration enabled, Talo can sync a Steam player ([as described here](/docs/pre-1.0/integrations/steamworks#authentication)). You can do this via the `Talo.Players.IdentifySteam` function. Here's a modified version of an example [provided by Unity](https://docs.unity.com/ugs/en-us/manual/authentication/manual/platform-signin-steam) using Steamworks.NET: +If you have the Steamworks integration enabled, Talo can sync a Steam player ([as described here](/pre-1.0/integrations/steamworks#authentication)). You can do this via the `Talo.Players.IdentifySteam` function. Here's a modified version of an example [provided by Unity](https://docs.unity.com/ugs/en-us/manual/authentication/manual/platform-signin-steam) using Steamworks.NET: ```csharp Callback m_AuthTicketForWebApiResponseCallback; @@ -201,7 +201,7 @@ The `identity` parameter is optional but strongly recommended as it ensures prop ### Steamworks player props -After successfully authenticating the player, several [props](/docs/pre-1.0/unity/player-props) will automatically be created for them: +After successfully authenticating the player, several [props](/pre-1.0/unity/player-props) will automatically be created for them: - `META_STEAMWORKS_VAC_BANNED` - "true" or "false" - `META_STEAMWORKS_PUBLISHER_BANNED` - "true" or "false" @@ -256,7 +256,7 @@ PlayGamesPlatform.Instance.RequestServerSideAccess( ### Google Play Games player props -After successfully authenticating the player, these [props](/docs/pre-1.0/unity/player-props) will automatically be created for them: +After successfully authenticating the player, these [props](/pre-1.0/unity/player-props) will automatically be created for them: - `META_GOOGLE_PLAY_GAMES_DISPLAY_NAME` - The player's chosen display name - `META_GOOGLE_PLAY_GAMES_AVATAR_URL` - A direct link to the player's avatar @@ -333,7 +333,7 @@ If the `cachePlayerOnIdentify` setting is enabled (default `true`), Talo will st ## Display names -Every player alias has a `displayName` that provides a human-readable name for the player. You can read it from `Talo.CurrentAlias.displayName` after a player has been identified. Display names are resolved from a [player's props](/docs/pre-1.0/unity/player-props) - arbitrary properties persisted across all of a player's aliases. +Every player alias has a `displayName` that provides a human-readable name for the player. You can read it from `Talo.CurrentAlias.displayName` after a player has been identified. Display names are resolved from a [player's props](/pre-1.0/unity/player-props) - arbitrary properties persisted across all of a player's aliases. ```csharp title="WelcomeLabel.cs" using TaloGameServices; diff --git a/content/docs/pre-1.0/unity/install.mdx b/content/docs/pre-1.0/unity/install.mdx index f5355fe..120bfa7 100644 --- a/content/docs/pre-1.0/unity/install.mdx +++ b/content/docs/pre-1.0/unity/install.mdx @@ -49,4 +49,4 @@ If you're self-hosting Talo, you can configure your custom endpoint here in the ### Settings reference -You can visit the [settings reference](/docs/pre-1.0/unity/settings-reference) for a detailed overview of Talo's configuration options. +You can visit the [settings reference](/pre-1.0/unity/settings-reference) for a detailed overview of Talo's configuration options. diff --git a/content/docs/pre-1.0/unity/leaderboards.mdx b/content/docs/pre-1.0/unity/leaderboards.mdx index 5447e41..fecd1f2 100644 --- a/content/docs/pre-1.0/unity/leaderboards.mdx +++ b/content/docs/pre-1.0/unity/leaderboards.mdx @@ -136,7 +136,7 @@ private void OnPropsRejected(RejectedProp[] rejectedProps) } ``` -See [Players and props - Prop rejection reasons](/docs/pre-1.0/unity/player-props#prop-rejection-reasons) for the full list of rejection reason codes. +See [Players and props - Prop rejection reasons](/pre-1.0/unity/player-props#prop-rejection-reasons) for the full list of rejection reason codes. ## Getting entries diff --git a/content/docs/pre-1.0/unity/live-config.mdx b/content/docs/pre-1.0/unity/live-config.mdx index dd40485..77f58a8 100644 --- a/content/docs/pre-1.0/unity/live-config.mdx +++ b/content/docs/pre-1.0/unity/live-config.mdx @@ -77,4 +77,4 @@ void Start() } ``` -The `OnLiveConfigUpdated` event is invoked (via the [Talo Socket](/docs/pre-1.0/socket)) whenever the live config is updated. +The `OnLiveConfigUpdated` event is invoked (via the [Talo Socket](/pre-1.0/socket)) whenever the live config is updated. diff --git a/content/docs/pre-1.0/unity/player-authentication.mdx b/content/docs/pre-1.0/unity/player-authentication.mdx index a5ee8af..4789586 100644 --- a/content/docs/pre-1.0/unity/player-authentication.mdx +++ b/content/docs/pre-1.0/unity/player-authentication.mdx @@ -289,7 +289,7 @@ You can migrate a player's account to a different service and identifier using ` The original player auth account will be deleted and they will only be able to use their new identifier. -Here is an example of migrating to a [Steam alias](/docs/pre-1.0/unity/identifying#steamworks-integration): +Here is an example of migrating to a [Steam alias](/pre-1.0/unity/identifying#steamworks-integration): ```csharp Callback m_AuthTicketForWebApiResponseCallback; @@ -318,7 +318,7 @@ async void OnAuthCallback(GetTicketForWebApiResponse_t callback) } ``` -You can also migrate to the `google_play_games` service by providing an [auth code](/docs/pre-1.0/unity/identifying#google-play-games-integration). +You can also migrate to the `google_play_games` service by providing an [auth code](/pre-1.0/unity/identifying#google-play-games-integration). When a migration is successful, the current session is cleared, the player's alias is updated to the new service and identifier, and the `OnPlayerIdentified` event is invoked. @@ -328,4 +328,4 @@ As shown in the examples above, whenever a request fails with an authentication- The exception provides a `ErrorCode` property that returns a matching `PlayerAuthErrorCode` enum value for the error response. -You can view all the authentication errors and their descriptions [here](/docs/pre-1.0/http/player-auth-api#error-codes). +You can view all the authentication errors and their descriptions [here](/pre-1.0/http/player-auth-api#error-codes). diff --git a/content/docs/pre-1.0/unity/player-props.mdx b/content/docs/pre-1.0/unity/player-props.mdx index 60661cc..32eaa3f 100644 --- a/content/docs/pre-1.0/unity/player-props.mdx +++ b/content/docs/pre-1.0/unity/player-props.mdx @@ -51,7 +51,7 @@ private async void SearchPlayers() Players can have a list of arbitrary properties that are persisted across all of their aliases. These props are identified by their unique key and can have any string value. Keys can be up to 128 characters long and values can be up to 512 characters long. -All functions that modify props accept an optional `update` parameter (default `true`) that controls whether the player is synced with Talo after the change. Set it to `false` to batch multiple changes and avoid redundant [debounces](/docs/pre-1.0/unity/settings-reference#debouncetimerseconds). +All functions that modify props accept an optional `update` parameter (default `true`) that controls whether the player is synced with Talo after the change. Set it to `false` to batch multiple changes and avoid redundant [debounces](/pre-1.0/unity/settings-reference#debouncetimerseconds). ### Getting props diff --git a/content/docs/pre-1.0/unity/player-relationships.mdx b/content/docs/pre-1.0/unity/player-relationships.mdx index dc456c3..16e74fc 100644 --- a/content/docs/pre-1.0/unity/player-relationships.mdx +++ b/content/docs/pre-1.0/unity/player-relationships.mdx @@ -33,7 +33,7 @@ A complete sample is available in the Unity package at `Assets/Talo Game Service To subscribe to a player, you need to first decide what type of relationship you want to create: unidirectional or bidirectional. Unidirectional relationships create a subscription to the target player and bidirectional relationships will create a reciprocal subscription between both players. -You also need to know the target player alias' ID. You can get this through [player presence updates](/docs/pre-1.0/unity/player-presence), or by searching for players using [player search](/docs/pre-1.0/unity/player-props#searching-for-players). +You also need to know the target player alias' ID. You can get this through [player presence updates](/pre-1.0/unity/player-presence), or by searching for players using [player search](/pre-1.0/unity/player-props#searching-for-players). Once you have both of these pieces of information, you can create the relationship: diff --git a/content/docs/pre-1.0/unity/settings-reference.mdx b/content/docs/pre-1.0/unity/settings-reference.mdx index 537a98b..846cb40 100644 --- a/content/docs/pre-1.0/unity/settings-reference.mdx +++ b/content/docs/pre-1.0/unity/settings-reference.mdx @@ -23,7 +23,7 @@ At a minimum, the Talo Unity package requires the `read:players` and `write:play ### apiUrl -This is the location of the Talo API. The default cloud version is `https://api.trytalo.com`. If you're [self-hosting Talo](/docs/pre-1.0/selfhosting/overview), this should be the address of your `backend` container. +This is the location of the Talo API. The default cloud version is `https://api.trytalo.com`. If you're [self-hosting Talo](/pre-1.0/selfhosting/overview), this should be the address of your `backend` container. ### socketUrl @@ -37,7 +37,7 @@ If enabled, the package will automatically connect to the Talo Socket when the g Talo uses the `OnApplicationQuit()` message to flush events before the game is closed. This is not available on the WebGL platform so a timer is used to flush events periodically instead. This setting controls how often events are flushed (in seconds). -Learn more about [event flushing here](/docs/pre-1.0/unity/events#flushing). +Learn more about [event flushing here](/pre-1.0/unity/events#flushing). ### cachePlayerOnIdentify @@ -45,11 +45,11 @@ If enabled, Talo will automatically cache the player after a successful online i ### continuityEnabled -If enabled, Talo will try to automatically replay failed network requests - [learn more about Continuity here](/docs/pre-1.0/unity/continuity). +If enabled, Talo will try to automatically replay failed network requests - [learn more about Continuity here](/pre-1.0/unity/continuity). ### autoStartSession -If enabled and a valid session token is found, the player will be automatically authenticated. This is documented on the [Player Authentication page](/docs/pre-1.0/unity/player-authentication#automatic-logins). +If enabled and a valid session token is found, the player will be automatically authenticated. This is documented on the [Player Authentication page](/pre-1.0/unity/player-authentication#automatic-logins). ### logRequests @@ -71,7 +71,7 @@ It is strongly recommended that you do not set this value below the default. A l ### verificationEnabled -Enable request verification to cryptographically sign requests and socket messages. This must also be enabled in the Talo dashboard. Learn more on the [Request verification page](/docs/pre-1.0/unity/request-verification). +Enable request verification to cryptographically sign requests and socket messages. This must also be enabled in the Talo dashboard. Learn more on the [Request verification page](/pre-1.0/unity/request-verification). ### verificationKeyVersion diff --git a/content/docs/pre-1.0/unity/socket.mdx b/content/docs/pre-1.0/unity/socket.mdx index 18804b0..5ff1695 100644 --- a/content/docs/pre-1.0/unity/socket.mdx +++ b/content/docs/pre-1.0/unity/socket.mdx @@ -11,7 +11,7 @@ Ideally you should never need to use the socket directly because individual serv The socket connection is automatically established (this can disabled by setting `autoConnectSocket` to `false` in your config). When a player gets identified, they also get automatically identified with the socket server. -You can learn more about how the socket works [here](/docs/pre-1.0/sockets/intro). +You can learn more about how the socket works [here](/pre-1.0/sockets/intro). ## Obtaining a socket ticket @@ -23,7 +23,7 @@ Opening a socket connection using `Talo.Socket.OpenConnection()` will automatica ## Receiving messages -The `OnMessageReceived` event provides you with a [response](/docs/pre-1.0/sockets/responses) and payload. For example, if you were building a chat system, you would connect a function similar to the one below to listen for new chat messages: +The `OnMessageReceived` event provides you with a [response](/pre-1.0/sockets/responses) and payload. For example, if you were building a chat system, you would connect a function similar to the one below to listen for new chat messages: ```csharp private void Start() @@ -51,7 +51,7 @@ private void OnMessageReceived(SocketResponse response) ## Sending messages -Sending messages is handled by functions in services like `Talo.Channels.SendMessage()` where the correct data is prepared and sent for you. You can also use the `Talo.Socket.Send()` function to send your own [requests](/docs/pre-1.0/sockets/requests): +Sending messages is handled by functions in services like `Talo.Channels.SendMessage()` where the correct data is prepared and sent for you. You can also use the `Talo.Socket.Send()` function to send your own [requests](/pre-1.0/sockets/requests): ```csharp public void SendMessage(int channelId, string message) @@ -72,7 +72,7 @@ public void SendMessage(int channelId, string message) -The socket server can disconnect for a number of reasons such as the player going offline or being [rate limited](/docs/pre-1.0/sockets/common-errors#rate-limit-exceeded). The socket will invoke a `OnConnectionClosed` event with a status code and reason. +The socket server can disconnect for a number of reasons such as the player going offline or being [rate limited](/pre-1.0/sockets/common-errors#rate-limit-exceeded). The socket will invoke a `OnConnectionClosed` event with a status code and reason. The Talo socket automatically reconnects when the [connection is restored](continuity#onconnectionrestored). If you need to manually re-open the socket, you can establish a connection and re-identify the player like this: @@ -94,7 +94,7 @@ You can choose to manually end the socket connection using `Talo.Socket.CloseCon ## Request verification -If your game has [request verification](/docs/pre-1.0/unity/request-verification) enabled, socket messages are automatically signed for players. The server validates these signatures to prevent replay attacks and tampering. +If your game has [request verification](/pre-1.0/unity/request-verification) enabled, socket messages are automatically signed for players. The server validates these signatures to prevent replay attacks and tampering. ## Error handling diff --git a/react-router.config.ts b/react-router.config.ts index 5b0365c..4ad4a11 100644 --- a/react-router.config.ts +++ b/react-router.config.ts @@ -2,7 +2,7 @@ import type { Config } from '@react-router/dev/config' import { createGetUrl, getSlugs } from 'fumadocs-core/source' import { glob } from 'node:fs/promises' -const getUrl = createGetUrl('/docs') +const getUrl = createGetUrl('/') export default { ssr: false, @@ -10,7 +10,7 @@ export default { const paths: string[] = [] for (const path of getStaticPaths()) { - // `/` redirects to `/docs` via the client loader + // `/` navigates to the default version via the client component if (path !== '/') { paths.push(path) } diff --git a/workers/app.ts b/workers/app.ts index 3a5c6b3..79ab11a 100644 --- a/workers/app.ts +++ b/workers/app.ts @@ -6,11 +6,6 @@ type Env = {} // Pre-versioning paths (e.g. /docs/godot/install) redirect to the default version. const DEFAULT_VERSION = '1.x' const LEGACY_SECTIONS = ['godot', 'unity', 'http', 'sockets', 'selfhosting', 'integrations'] -const VERSION_REDIRECTS: Record = { - '1.0': '1.x', - '0.49': 'pre-1.0', - '0.60': 'pre-1.0', -} const requestHandler = createRequestHandler( () => import('virtual:react-router/server-build'), @@ -20,22 +15,16 @@ const requestHandler = createRequestHandler( export default { async fetch(request) { const { pathname, origin } = new URL(request.url) - // Default the docs root to the default version. + // Old `/docs/*` URLs redirect to the prefix-less paths. if (pathname === '/docs' || pathname === '/docs/') { - return Response.redirect(`${origin}/docs/${DEFAULT_VERSION}`, 301) + return Response.redirect(`${origin}/${DEFAULT_VERSION}`, 301) } - const match = pathname.match(/^\/docs\/([^/]+)(\/.*)?$/) + const match = pathname.match(/^\/docs\/(.+)$/) if (match) { - const [, first, rest = ''] = match - let target: string | null = null - if (LEGACY_SECTIONS.includes(first)) { - target = `/docs/${DEFAULT_VERSION}/${first}${rest}` - } else if (VERSION_REDIRECTS[first]) { - target = `/docs/${VERSION_REDIRECTS[first]}${rest}` - } - if (target) { - return Response.redirect(`${origin}${target}`, 301) - } + const rest = match[1] + const [first] = rest.split('/') + const target = LEGACY_SECTIONS.includes(first) ? `/${DEFAULT_VERSION}/${rest}` : `/${rest}` + return Response.redirect(`${origin}${target}`, 301) } return requestHandler(request) },