diff --git a/.opencode/commands/docs-review.md b/.opencode/commands/docs-review.md index 08a9c70..0847873 100644 --- a/.opencode/commands/docs-review.md +++ b/.opencode/commands/docs-review.md @@ -2,6 +2,7 @@ name: docs-review description: Review the current branch --- + # Docs review You are a pragmatic technical documentation expert. Review the changes using the guidance below. @@ -24,32 +25,43 @@ You are a pragmatic technical documentation expert. Review the changes using the ### Categories to check 1. **📖 Clarity & Readability** - - Is the documentation easy to understand for developers of all skill levels? - - Are technical concepts explained clearly without jargon overload? - - Are sentences concise and direct (avoid unnecessary words)? - - Are examples provided where they would help understanding? + +- Is the documentation easy to understand for developers of all skill levels? +- Are technical concepts explained clearly without jargon overload? +- Are sentences concise and direct (avoid unnecessary words)? +- Are examples provided where they would help understanding? + 2. **✅ Accuracy & Completeness** - - Are code samples syntactically correct and functional? - - Do examples match the current API? - - Are all necessary steps included (no missing prerequisites or assumptions)? - - Are parameter names, types, and descriptions accurate? + +- Are code samples syntactically correct and functional? +- Do examples match the current API? +- Are all necessary steps included (no missing prerequisites or assumptions)? +- Are parameter names, types, and descriptions accurate? + 3. **🎯 Structure & Organization** - - Is information presented in a logical order? - - Are headings and sections properly organized? - - Is frontmatter (sidebar_position, description) set correctly? - - Are related topics cross-referenced appropriately? + +- Is information presented in a logical order? +- Are headings and sections properly organized? +- Is frontmatter (sidebar_position, description) set correctly? +- Are related topics cross-referenced appropriately? + 4. **💻 Code Examples** - - Are code samples formatted correctly with proper language tags? - - Do examples follow best practices (not just working code, but good code)? - - Are code samples complete enough to be useful (not too minimal)? + +- Are code samples formatted correctly with proper language tags? +- Do examples follow best practices (not just working code, but good code)? +- Are code samples complete enough to be useful (not too minimal)? + 5. **⚡ Developer Experience** - - Would a developer be able to accomplish their goal using just this documentation? - - Are common pitfalls or gotchas highlighted (warnings, tips, cautions)? - - Is the tone welcoming and helpful (not condescending or assuming knowledge)? + +- Would a developer be able to accomplish their goal using just this documentation? +- Are common pitfalls or gotchas highlighted (warnings, tips, cautions)? +- Is the tone welcoming and helpful (not condescending or assuming knowledge)? + 6. **🔗 Links & References** - - Are internal links using the correct format (`/docs/path/to/page`)? - - Do all links point to valid destinations? - - Are images referenced correctly from `/img/` or other static paths? + +- Are internal links using the correct format (`/docs/path/to/page`)? +- Do all links point to valid destinations? +- Are images referenced correctly from `/img/` or other static paths? ### Issue categories @@ -67,12 +79,16 @@ You are a pragmatic technical documentation expert. Review the changes using the 1. **Analysis Phase**: Review the PR diff and identify potential issues 2. **Validation Phase**: For each issue you find, verify it by: - - Re-reading the relevant code carefully - - Checking if your suggested fix is actually different from the current code + +- Re-reading the relevant code carefully +- Checking if your suggested fix is actually different from the current code + 3. **Draft Phase**: Write your review only after validating all issues 4. **Quality Check**: Before posting, remove any issues where: - - Your "before" and "after" code snippets are identical - - You're uncertain or use phrases like "appears", "might", "should verify" + +- Your "before" and "after" code snippets are identical +- You're uncertain or use phrases like "appears", "might", "should verify" + 5. **Final Output Phase**: Output your complete, validated review text. ### Things to avoid @@ -87,4 +103,3 @@ You are a pragmatic technical documentation expert. Review the changes using the - Suggest fixes with code snippets where helpful. - Be pragmatic, don't force criticism. - Ensure feedback is actionable. - diff --git a/content/docs/1.x/godot/leaderboards.mdx b/content/docs/1.x/godot/leaderboards.mdx index b1be441..9c4e580 100644 --- a/content/docs/1.x/godot/leaderboards.mdx +++ b/content/docs/1.x/godot/leaderboards.mdx @@ -275,3 +275,39 @@ var options := Talo.leaderboards.GetEntriesOptions.new() options.end_date = "2025-09-30" # options.start_date is omitted - returns all entries created before October 1, 2025 00:00:00 UTC ``` + +## Getting top entries + + + +`Talo.leaderboards.get_top_entries()` fetches a leaderboard's top entries alongside the current player's own entries. This is the quickest way to build a leaderboard screen without paginating: + +```gdscript title="get_top_entries_button.gd" +extends Button + +@export var leaderboard_name: String +@export var limit: int = 10 + +func _on_pressed() -> void: + var res := await Talo.leaderboards.get_top_entries(leaderboard_name, limit) + + if res == null: + return + + for entry in res.top_entries: + print("#%s: %s scored %s" % [entry.position + 1, entry.player_alias.display_name, entry.score]) + + for entry in res.player_entries: + print("You are #%s with %s" % [entry.position + 1, entry.score]) +``` + + + The `limit` argument applies to both arrays and must be between 1 and 200. + + +`get_top_entries()` returns a `TopEntriesResult` with two sorted arrays: + +- `top_entries` - the leaderboard's top entries +- `player_entries` - the current player's entries, each with its global `position` + +Neither array is added to the [entry cache](#entry-cache). diff --git a/content/docs/1.x/unity/leaderboards.mdx b/content/docs/1.x/unity/leaderboards.mdx index 02a0374..9955705 100644 --- a/content/docs/1.x/unity/leaderboards.mdx +++ b/content/docs/1.x/unity/leaderboards.mdx @@ -309,3 +309,40 @@ var entries = await Talo.Leaderboards.GetEntries(internalName, new GetEntriesOpt // startDate is omitted - returns all entries created before October 1, 2025 00:00:00 UTC }); ``` + +## Getting top entries + + + +`Talo.Leaderboards.GetTopEntries()` fetches a leaderboard's top entries alongside the current player's own entries. This is the quickest way to build a leaderboard screen without paginating: + +```csharp title="GetTopEntries.cs" +string internalName = "time-survived"; +int limit = 10; + +public async void FetchTopEntries() +{ + var res = await Talo.Leaderboards.GetTopEntries(internalName, limit); + + foreach (var entry in res.topEntries) + { + Debug.Log($"#{entry.position + 1}: {entry.playerAlias.displayName} scored {entry.score}"); + } + + foreach (var entry in res.playerEntries) + { + Debug.Log($"You are #{entry.position + 1} with {entry.score}"); + } +} +``` + + + The `limit` argument applies to both arrays and must be between 1 and 200. + + +`GetTopEntries()` returns a `LeaderboardTopEntriesResponse` with two sorted arrays: + +- `topEntries` - the leaderboard's top entries +- `playerEntries` - the current player's entries, each with its global `position` + +Neither array is added to the [entry cache](#entry-cache). diff --git a/package.json b/package.json index bc678cb..b5e2f2f 100644 --- a/package.json +++ b/package.json @@ -49,13 +49,13 @@ "vite": "^8.2.0", "wrangler": "^4.122.0" }, - "engines": { - "node": ">=24" - }, "devEngines": { "packageManager": { "name": "pnpm", "version": "12.0.0" } + }, + "engines": { + "node": ">=24" } }