Skip to content

Commit d6b222d

Browse files
authored
Added dialogs and menus article (#54)
1 parent 4768036 commit d6b222d

10 files changed

Lines changed: 723 additions & 141 deletions

File tree

‎.agent.md‎

Lines changed: 0 additions & 127 deletions
This file was deleted.
Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,2 @@
1+
- [Project architecture](project-architecture.md) — Two-layer API (Core vs Entities), key services, dialog/menu internals
2+
- [Docs conventions](docs-conventions.md) — Article structure, style, code sample idioms, toc.yml layout, AGENTS.md content
Lines changed: 40 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,40 @@
1+
---
2+
name: docs-conventions
3+
description: Documentation structure, style, and formatting conventions observed from existing feature articles
4+
metadata:
5+
type: project
6+
---
7+
8+
## File locations
9+
- Feature articles: `docs/features/*.md`
10+
- Each feature directory has a `toc.yml` listing article hrefs
11+
- Top-level `docs/toc.yml` exists; features have their own `docs/features/toc.yml`
12+
13+
## Article structure (from vehicles.md, timers.md, objects.md, commands.md)
14+
- YAML frontmatter: `title:` and `uid:` only — no other fields
15+
- Single H1 matching the title
16+
- Short intro paragraph (2–3 sentences max), no preamble fluff
17+
- H2 for major sections, H3 for sub-topics
18+
- **Bold lead** before code blocks ("Example: ...", or inline description)
19+
- Code blocks use `csharp` fence; always use `[Event]` attribute on event handler methods
20+
- xrefs with `<xref:FullyQualifiedTypeName>` for API types
21+
- Inline cross-links rather than a dedicated "See Also" section
22+
- End of section: `See <xref:...> for all available properties and methods.` is a common closing pattern
23+
24+
## Tone and density
25+
- Direct, instructional — no marketing filler
26+
- Assume C# developer; explain SA-MP-specific concepts (dialogs, menus) when first introduced
27+
- Short sentences, active voice
28+
- DocFX alerts used sparingly — only when genuinely useful (not decorative)
29+
30+
## Code sample idioms
31+
- Event handlers shown inside `ISystem` class with `[Event]` attribute
32+
- Services injected as method parameters (not constructor-injected in samples unless needed)
33+
- Named parameters used in constructor calls for clarity (`caption:`, `button1:`, etc.)
34+
- `async Task` return type shown when using `ShowAsync`
35+
36+
## AGENTS.md is actually a DocFX xref cheat sheet
37+
- The file at `docs/AGENTS.md` (which is loaded as the project AGENTS file) is actually a DocFX cross-reference guide, not a traditional agent instructions file
38+
- Key rule: prefer `<xref:uid>` syntax; use `[text](xref:uid)` only for custom link text
39+
- UID for conceptual docs comes from YAML frontmatter `uid:` field
40+
- UID for API docs is the fully-qualified type/member name
Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
---
2+
name: project-architecture
3+
description: SampSharp source layout, key namespaces, and the two-layer API pattern (Core vs Entities)
4+
metadata:
5+
type: project
6+
---
7+
8+
SampSharp has two distinct layers in `sampsharp-src/src/`:
9+
10+
**Layer 1 — `SampSharp.OpenMp.Core` (`SampSharp.OpenMp.Core.Api` namespace)**
11+
- Raw open.mp API bindings: `IPlayerDialogData`, `IDialogsComponent`, `IMenu`, `IMenusComponent`, etc.
12+
- Enums here use ALLCAPS or abbreviated names (e.g. `DialogStyle.MSGBOX`, `DialogResponse.Left/Right`)
13+
- Accessed directly only when working at the native level
14+
15+
**Layer 2 — `SampSharp.OpenMp.Entities` (`SampSharp.Entities.SAMP` namespace)**
16+
- The idiomatic C# API developers actually use
17+
- Higher-level types: `MessageDialog`, `InputDialog`, `ListDialog`, `TablistDialog`, `Menu`, `Player`, `Vehicle`, etc.
18+
- Enums have friendly names: `DialogStyle.MessageBox`, `DialogResponse.LeftButton/RightButtonOrCancel/Disconnected`
19+
- Services registered as singletons: `IDialogService`, `IWorldService`, `ITimerService`, etc.
20+
- Event handlers live in `ISystem` implementations using `[Event]` attribute
21+
22+
**Why this matters:** Always document the Entities layer API — that is what gamemode developers use. The Core layer is an implementation detail.
23+
24+
**Key service for dialogs:** `IDialogService` — registered automatically, no setup needed.
25+
**Key service for menus:** `IWorldService.CreateMenu(...)` — menus are world entities.
26+
27+
**Dialog ID note:** `DialogService` internally uses dialog ID `10000`. Dialog IDs are not exposed to gamemode code.

0 commit comments

Comments
 (0)