Jump to content

SimTX API/Packets/CatalogUploadResult: Difference between revisions

From SimTX Wiki
Clanker (talk | contribs)
Protocol v25 reference: CatalogUploadResult
Tag: Removed redirect
Clanker (talk | contribs)
Remove development history and server internals
 
Line 13: Line 13:
| file = control.proto
| file = control.proto
}}
}}
'''CatalogUploadResult''' confirms a successful [[SimTX API/Packets/CatalogUpload|CatalogUpload]]. A refused upload is answered with [[SimTX API/Packets/Error|Error]] instead; the v24 <code>ok</code> and <code>message</code> fields are gone.
'''CatalogUploadResult''' confirms a successful [[SimTX API/Packets/CatalogUpload|CatalogUpload]]. A refused upload is answered with [[SimTX API/Packets/Error|Error]] instead.


== Definition ==
== Definition ==
Line 19: Line 19:
message CatalogUploadResult {
message CatalogUploadResult {
   reserved 2, 3;
   reserved 2, 3;
  reserved "ok", "message";
   int64 request_id = 1;
   int64 request_id = 1;
   int32 entry_id = 4;
   int32 entry_id = 4;
Line 37: Line 36:
|}
|}


Reserved, never reused: field numbers 2, 3 and the names <code>ok</code>, <code>message</code>.
Field numbers 2 and 3 are reserved; do not use them.


== Example ==
== Example ==
Complete frames, including the varint length prefix, from the protocol's golden test vectors (<code>protocol/simtx/v25/testdata/frames.json</code>).
Complete frames, including the varint length prefix.


'''<code>catalog_upload_result_updated</code>''' (server to client, 10 bytes):
'''<code>catalog_upload_result_updated</code>''' (server to client, 10 bytes):

Latest revision as of 17:16, 24 October 2026

CatalogUploadResult
Frame ServerFrame, field 38
Member catalog_upload_result
Direction Server → client
Session Control (catalog)
Roles ROLE_CONTROL.
Permission None
Answered by
Answers CatalogUpload
Defined in control.proto

CatalogUploadResult confirms a successful CatalogUpload. A refused upload is answered with Error instead.

Definition[edit | edit source]

message CatalogUploadResult {
  reserved 2, 3;
  int64 request_id = 1;
  int32 entry_id = 4;
  bool updated = 5;            // true: replaced your existing publication of that name
}

Fields[edit | edit source]

# Field Type Description
1 request_id int64 The request this answers.
4 entry_id int32 ID of the published entry.
5 updated bool True: the upload replaced your existing entry of that name and its revision increased.

Field numbers 2 and 3 are reserved; do not use them.

Example[edit | edit source]

Complete frames, including the varint length prefix.

catalog_upload_result_updated (server to client, 10 bytes):

09        frame length 9
B2 02 06  catalog_upload_result (CatalogUploadResult), 6 bytes
  08 2B   request_id = 43
  20 11   entry_id = 17
  28 01   updated = true

See also[edit | edit source]

SimTX API reference (protocol v25)
Start OverviewQuick startFramingData typesPacket listSchemaLimits and errorsCompatibility and versioning
Account service OverviewDevice loginServer directoryStation endpointsGame ticketsPermissionsPublic endpoints
Game protocol Connection and handshakeSession statusReceiver sessionTransmitter sessionControl sessionCatalogModeration
Stations StationsSatellitesTracking and pointing
Connection ClientHelloPingServerHelloPongErrorBanner
Session AntennaPointingUpdateSessionStatus
Receiver ForwardedClientAddressReceiverStartReceiverRetuneIqStreamDescriptorIqBlock
Transmitter TransmitterStartSampleBlockTxUpdateTxModeInfoTxQueueTxAcceptTxTelemetryTxUpdateAck
Control ListStationsStartMonitorStopMonitorWeatherMapRequestServerHealthRequestCoverageMapRequestEphemerisRequestPassPredictionRequestStationListMonitorBlockMonitorEndWeatherMapResponseServerHealthReportCoverageMapResponseEphemerisResponsePassPredictionResponseMonitorAck
Catalog CatalogListRequestCatalogFetchCatalogUploadCatalogDeleteCatalogListCatalogEntryCatalogUploadResultCatalogDeleteResult
Moderation KickRequestIpModerationRequestBroadcastBannerKickResultIpModerationResultStationImpactList
Archive Protocol v24 reference