This reference material is generated from this directory in the repo.

These handle incoming PDUs by their PDU Type. They can respond with one, or many PDUs.

When a PDU is received from the client in nio2so, the PDU given to the Protocol-Regulator that has a matching Handler function. These are broken-down into three types:

1. TSOProtocolHandler - These are simple TSOVoltron PDUs, deriving from TSOVoltronPacket. They fall into this category if they are not one of the other two.
2. TSOProtocolDatabaseHandler - These are Database PDUs, they derive from TSODBRequestWrapper.cs, which in turn derives its logic from TSOVoltronPacket, and therefore is also a TSOVoltron PDU. They have a different structure and format than a normal TSOVoltron PDU and are used primarily in Database operations, hence the name.
3. TSOProtocolDatablobHandler - These are used specifically in the Simulation of the game. They have Broadcast and Transmit types of Datablob PDUs.

1. Respond to the Client with a PDU it forms
2. Insert a new PDU into the receiving queue (pass messages to another regulator)
3. Append a PDU to the end of the receiving queue
4. Ignore it
5. Run other code depending on what the needs are.

These regulators have a connection to the nio2so Data Service to supply data to the Client.

    /// <summary>
    /// Handles incoming requests related to the Avatars and their DB operations
    /// </summary>
    [TSORegulator("AvatarProtocol")]
    internal class AvatarProtocol : TSOProtocol

nio2so Protocol-Regulators have the TSORegulator attribute and inherit TSOProtocol (TSORegulatorBase).

• Inbox Lifecycle: The GET_MPS_MESSAGES_PDU handler follows a "fetch-and-clear" pattern. It downloads all pending messages for the avatar from the data service, transmits them to the client as individual flash packets, and then immediately calls ClearInboxMessages to empty the server-side queue.

• Flash Message Routing: The FLASH_MESSAGE_PDU logic differentiates between two types of communication:

  • SMS: Attempts a real-time delivery using TrySendTo. If the recipient is online and the packet sends successfully, it confirms back to the sender.

  • Letter: Persists the message to the database via SendInboxMessageToAvatar for later retrieval, acting as an offline mailing system.

• Data Conversion: The class includes helper methods ToLetter and FromLetter to bridge the gap between the network-layer TSOFlashMessagePDU and the data-service-layer Letter object.

• Unified Logic: Both exact and wildcard searches are routed through UnifiedSearchHandler. This method determines the search type by checking the object type (TSOExactSearchRequest) and then awaits the results from the data service.

• Category Mapping: The search utilizes the TSO_PreAlpha_Categories enum, which is converted to a string before being sent to the nio2soVoltronDataServiceClient.

• Search Results: The results are mapped from the data service IDs and names into TSOSearchResultStruct objects before being packaged into either a TSOExactSearchResponse or a standard TSOSearchResponse.

• Dynamic Image Conversion: The class includes a unique TO_RLE8 method. Since The Sims Online (Pre-Alpha) requires specific legacy formats, this converts modern images into 8-bit Indexed BMPs with RLE (Run-Length Encoding) compression on the fly.

• Resource Caching: It uses a ConcurrentDictionary to cache these encoded bytes during a single request cycle to avoid redundant processing, though it calls FLUSH_CACHE() at the end of the GET_TOP_LIST_REQUEST to prevent memory bloat.

• Format Constraints: Images are explicitly cropped and clamped to a maximum size of 96x23 pixels during the conversion process to ensure they fit the UI constraints of the Top 100 list icons.

• Top 100 Lists: The logic supports different list types (e.g., "Most Popular Places") by mapping the remote data service results into the TSOTop100List and TSOTopListResultStruct formats required by the client.

This handler manages incoming telemetry and logging from the client.

• UPDATE_PLAYER_PDU this PDU tells the client "who" the player is, their name and account ID.

• This Protocol handles when someone disconnects from Voltron, ensuring their session is properly closed: their house they're hosting is taken offline, and they're properly marked as being offline.

• BC_VERSION_LIST_PDU is currently unknown what it does.

• InsertGenericLog_Request is sent from the Client when it wants to log something important, and it is shown in nio2so as well.