The Sims Online Regulators Reference Material

This information is based off of research into disassembly, console logs, etc. and is subject to change as new information is discovered.

Helpful Context

The Sims Online's infrastructure is based off of messaging from regulators to other regulators. They send each other messages (called kMSGs) with an ID and a specific function. This means that the Client has its own messaging framework that can send messages Client to Client, Client to Server, and Server to Client.

The game will log vital information about how a regulator should typically function as shown here:

What this shows is that the Connection Regulator can enter the kConnectedState and transition to the following other state from this state:

• kConnectedState -> kDisconnectedState if it receives the kConnectionFailed kMSG.

It follows this same formula for each entry in the log:

• F: (From State) M: (Message received to invoke transition to...) T: (The new state)

Reference materials shown below will use this information to document how these regulators function.

It is also important to know that it can map a state transition to the same state if it receives a certain message. In this case, it can perform work based on the received kMSG, but receiving that message will not change the state to a new one.

Do note: The log will only print out other states that it can transition to when the state changes. It doesn't document the entire functionality of the regulator at one time.

cTSORegulator::ConnectionRegulator

When the ConnectionRegulator gets Enabled, it starts in the kDisconnectedState.

From kDisconnectedState it can enter the following states:

• kDisconnectedState -> kConnectedState when receiving the kConnectionEstablished message.
• kDisconnectedState -> kDisconnectedState when receiving the kConnectionFailed message.

From kConnectedState it can enter the following states:

• kConnectedState -> kDisconnectedState when receiving the kConnectionFailed message.
• kConnectedState -> kDisconnectedState when receiving the kConnectionTerminated message.
• kConnectedState -> kConnectedState when receiving the kMSGID_SaveGame message.
• kConnectedState -> kConnectedState when receiving the kMSGID_ForceSaveGame message.

With no further mapped state transitions, this appears to be the entirety of the state-map this Regulator.

cTSORegulator::HouseLoadRegulator

When the HouseLoadRegulator gets Enabled, it starts in the kStartedState.

From kStartedState it can enter the following states:

• kStartedState -> kLoadingState when receiving the kMSGID_LoadHouse message.

From the kLoadingState it can enter the following states:

• kLoadingState -> kLoadingState2 when receiving the kDBGetHouseBlobByID_Query message.
• kLoadingState -> kUnloadingState when receiving the kMSGID_UnloadHouseTimeout message.
• kLoadingState -> kLoadingState when receiving the kClientHasConnected message.
• kLoadingState -> kLoadingState when receiving the kMSGID_AvatarLeft message.
• kLoadingState -> kLoadingState when receiving the kMSGID_AvatarJoinDone message.

Entering the kLoadingState will cause it to log this message:

The House ID will be whatever you tell the Client using the TSOHouseSimConstraintsResponsePDU