SimTX API v24/Packets/CatalogUpload: Difference between revisions
SimTX API documentation |
m Clanker moved page SimTX API/Packets/CatalogUpload to SimTX API v24/Packets/CatalogUpload: Archive the v24 protocol reference |
(No difference)
| |
Revision as of 16:14, 24 October 2026
| Frame | {{{frame}}}, field {{{field}}}
|
|---|---|
| Member | {{{member}}}
|
| Direction | Client → server |
| Session | Control (catalog) |
| Roles | |
| Permission | catalog.publish
|
| Answered by | CatalogUploadResult |
| Defined in |
|
CatalogUpload publishes an extension or preset to the server's extension catalog, or publishes a new revision of an entry the account already owns. It requires an authenticated control session whose account holds catalog.publish. The server answers with CatalogUploadResult.
Layout
| Field | Type | Description |
|---|---|---|
packetId |
u8 |
Always 22.
|
kind |
UTF |
extension or preset. At most 16 characters.
|
name |
UTF |
Entry name, 1–64 characters after trimming. |
description |
UTF |
At most 500 characters. |
categoryCount |
i32 |
0–12. |
categories |
categoryCount × UTF |
Each 1–32 characters, no commas or control characters. |
fileCount |
i32 |
1–64 (presets: exactly 1). |
files |
fileCount × { UTF path, UTF content } |
Path at most 128 characters; content at most 60,000 characters and 60,000 UTF-8 bytes. |
Validation
The server checks the upload against the rules in Upload rules and reports the first problem it finds in CatalogUploadResult. Field lengths beyond the limits in the layout above close the connection instead, because the server stops reading the packet.
Without catalog.publish, the body is read and discarded, and the result is Publishing requires catalog.publish.
Revisions
Uploading an entry with the name of an entry the same account already owns replaces it: the ID stays the same and the revision increases. Names are compared without regard to case.