This page describes the protocol for ARIES/Voltron, an MMO framework developed by Kesmai (acquired by Electronic Arts) and used by Maxis for The Sims Online. For the new protocol being developed for Niotso, see Niotso Protocol.

Because the client uses the system-wide wininet.dll, it will happily connect to any HTTPS website with a valid X.509 certificate. All pages requested by the client may redirect but must eventually return 200 OK. All HTTP headers including content-type and date-modified are ignored by the client.

This page discusses the protocol and game binaries of the TSO New & Improved trial, version 1.1097.1.0. (and Pre-Alpha)

Note: If suddenly The Sims Online starts crashing whenever you open it, delete status.dat.

Reference: authlogin.dll

The host for the authorization server is specified in (gamedata/)sys/gameentry.ini. HTTPS can be disabled by changing the 2 bytes at offset 0x8327 in authlogin.dll from 30 C0 to 00 40; the port can be changed from 443 to 80 by changing the 2 bytes at offset 0x82AD in authlogin.dll from BB 01 to 50 00.

Note: Pre-Alpha hard-codes the host name for the authorization server ("www.ea.com") at offset 0x7FB60 in TSOProtocolsD.dll. HTTPS can be disabled by changing the 2 bytes at offset 0x22B9 in authlogin.dll from 30 C0 to 00 40; the port can be changed from 443 to 80 by changing the 2 bytes at offset 0x20A3 in authlogin.dll from BB 01 to 50 00.

Interestingly, auth.east.ea.com is the only EA server still running to this day (even auth.west.ea.com is down). The DNS records for auth.east.ea.com (159.153.234.80) and auth.west.ea.com (159.153.199.220) went down in December 2014, but if you place those into your hosts file, the situation is otherwise the same; auth.east.ea.com is still running to this day, and it currently responds with the following:

When the user attempts to log in, the client will connect to https://auth.east.ea.com/AuthLogin?username=&password=&serviceID=2147&version=2.5 with the "username" and "password" GET variables set to those supplied by the user. AuthLogin should log the player in and return a ticket (session cookie), which the client will later pass to the city selection server. The client must receive "Valid=TRUE" to continue.

The normal response is as such:

Valid=TRUE
Ticket=0123456789abcdef0123456789abcdef

The error response is as such:

Valid=FALSE
Ticket=0
reasoncode=INV-199
reasontext=INV-199: Game authentication is currently experiencing technical difficulties and this game is temporarily unavailable. Please try again later.
reasonurl=

Certain reason codes will override the "reasontext" field with a hardcoded string. These reason codes are as such:

Other valid fields are as such:

Reference: TSOServiceClientD.dll

The host for the city selection server is specified in (gamedata/)sys/cityselector.ini. HTTPS can be disabled by changing the 4 bytes at offset 0x923C4 in TSOServiceClientD.dll from 73 3A 2F 2F to 3A 2F 2F 00. The game makes two connections to the city selection server when requesting each page, one on port 443, and another on the port specified in cityselector.ini. To make it use the port in the INI file each time, change the byte at offset 0x17B2 in InternetServiceD.dll from 74 to EB.

Note: Pre-Alpha hard-codes the host name for the city selection server ("xo.max.ad.ea.com") at offset 0x7F860 in TSOProtocolsD.dll. HTTPS can be disabled by changing the 2 bytes at offset 0x22B9 in authlogin.dll from 30 C0 to 00 40; the port can be changed from 443 to 80 by changing the 2 bytes at offset 0x20A3 in authlogin.dll from BB 01 to 50 00.

Each page the client requests from the city selection server is in XML format.

Interestingly, the DNS records for tsocs.tso.ea.com are still up, with DNS 159.153.230.176. Putting this in your hosts file does nothing else though, as the page will take too long to respond.

Once authorized by the authorization server, the client connects to https://tsocs.tso.ea.com/cityselector/app/InitialConnectServlet/?ticket=&version= with the "ticket" variable set to that specified by the authorization server and the "version" variable set to a string such as "Version 1.1097.1.0". InitialConnectServlet should verify that the client is up-to-date and that the ticket (session cookie) is valid. InitialConnectServlet should set the "TSOSession" and "TSOSession2" HTTP cookies (see below for details) and respond with either Error-Message, User-Authorized, or Patch-Result as the root element of the XML response.

Error-Message indicates an error, usually an invalid session cookie. The format of Error-Message is as such:

<Error-Message>
  <Error-Number>1337</Error-Number>
  <Error>This error brought to you by InitialConnectServlet.</Error>
</Error-Message>

The error number which the client will override the server's error text for is 132: 

Patch-Result indicates that the client must download an update before it can continue. (InitialConnectServlet may wish to enforce this by logging the user out.) The format of Patch-Result is as such:

<Patch-Result>
  <Authorization-Ticket>0123456789abcdef0123456789abcdef</Authorization-Ticket>
  <Patch-Address>http://downloads.tso.ea.com:26100/games/PSW/TSO/Maxis-Patch-Production2</Patch-Address>
</Patch-Result>

In response to Patch-Result, the client displays an error requiring the user to apply an update. If the user accepts, the client closes itself, launches the updater utility, and retrieves the update information from the "Patch-Address" field. Interestingly, if the user instead declines the update, the Create-A-Sim Hint dialog will appear if that hint has not yet been disabled, and the user is then brought back to the login dialog.

For experimentation purposes, it may be desired to allow the client to continue even if it is an old version (that is, do not return Patch-Result for old client versions). However, for the updater utility to work, it is important that InitialConnectServlet always returns Patch-Result for version "0.0.0.0". Specifically, when the updater wants to verify the TSOClient game directory, it sends a request with version=0.0.0.0 to ensure that the server responds with Patch-Result so that it can get the URL of the TSOClient Marimba transmitter (presumably Maxis-Patch-Production2). If User-Authorized is returned in this case, the updater will show an error saying that the game verification has failed.

User-Authorized specifies that the user is authorized to continue. The format of User-Authorized is as such:

<User-Authorized>
  <csr /> <!-- Optional: Specifies that the user is a CSR. -->
</User-Authorized>

In addition to sending User-Authorized, InitialConnectServlet should set the "TSOSession" HTTP cookie, which the other JSP pages will check to ensure that the user is logged in. However, there is a cookie-parsing bug in versions of TSO prior to New & Improved, in that the last cookie in the HTTP response is ignored. To ensure TSOSession is not the last cookie in the response, the city server should also set another cookie directly after TSOSession, such as "TSOSession2".

If the server responds with the optional <csr /> tag, the client will log in as a Customer Service Representative (CSR). As a CSR, the player is not presented with SAS or CAS; instead, the player selects from a list of cities, and a new temporary character is created for this gameplay session with CSR capabilities (ejecting Sims).

Note: Pre-Alpha connects to /cityselector/initial-connect.jsp rather than /cityselector/app/InitialConnectServlet/. The server responses are the same for all elements except User-Authorized; in Pre-Alpha, User-Authorized does not provide a <csr /> child.

After passing InitialConnectServlet, the client connects to https://tsocs.tso.ea.com/cityselector/app/AvatarDataServlet to request the list of avatars. AvatarDataServlet should respond with either Error-Message or The-Sims-Online as the root element of the XML response.

Error-Message follows the same format as described in InitialConnectServlet with the same recognized error number of 132. Interestingly, if AvatarDataServlet returns Error-Message, once the user dismisses the error, the user is still brought to the Select-A-Sim screen.

The-Sims-Online provides a list of 0-3 avatars. The format of The-Sims-Online is as follows:

<The-Sims-Online>
  <!-- The first avatar. -->
  <Avatar-Data>
    <AvatarID>1337</AvatarID>
    <Name>JollySim</Name>
    <Shard-Name>Blazing Falls</Shard-Name>
    <!-- Move-Request is only used for Sim Move, which was implemented in versions of TSO from December 2004 and onwards. The game will check for this tag every time the list of avatars is reloaded. -->
    <Move-Request>Betaville</Move-Request>
    <!-- Primary-Avatar is only used for EA-Land. The game will check for this tag every time the list of avatars is reloaded. "false" is also only used for the Primary-Avatar tag to indicate that the avatar is not their main Avatar. Any value other than "false" will not count in the tag.
    <Primary-Avatar>false</Primary-Avatar>
  </Avatar-Data>
 
  <!-- The second avatar. -->
  <Avatar-Data>
    <AvatarID>1338</AvatarID>
    <Name>Guy</Name>
    <Shard-Name>Alphaville</Shard-Name>
  </Avatar-Data>
 
  <!-- The third avatar. -->
  <Avatar-Data>
    <AvatarID>1339</AvatarID>
    <Name>Coolio</Name>
    <Shard-Name>Test Center</Shard-Name>
  </Avatar-Data>
</The-Sims-Online>

The "Shard-Name" field for each avatar should refer to a shard (city server) defined later in shard-status.jsp.

Note: Pre-Alpha connects to /cityselector/avatar-data.jsp rather than /cityselector/app/AvatarDataServlet. The format of the The-Sims-Online element in Pre-Alpha is different, shown below:

<The-Sims-Online>
  <!-- The first avatar. -->
  <Avatar-Data>
    <AvatarID>1337</AvatarID>
    <Name>JollySim</Name>
    <Simoleans>20000</Simoleans>
    <Simolean-Delta>5000</Simolean-Delta>
    <Popularity>10</Popularity>
    <Popularity-Delta>1</Popularity-Delta>
    <Shard-Name>Blazing Falls</Shard-Name>
  </Avatar-Data>
  <Player-Active />
</The-Sims-Online>

After passing AvatarDataServlet, the client connects to https://tsocs.tso.ea.com/cityselector/shard-status.jsp to obtain the status of each shard (city server). shard-status.jsp should respond with either Error-Message or Shard-Status-List as the root element of the XML response.

Error-Message follows the same format as described in InitialConnectServlet with the same recognized error number of 132. Interestingly, if shard-status.jsp returns Error-Message, once the user dismisses the error, the user is still brought to the Select-A-Sim screen.

TSOMania.net has shared packet logs of shard-status.jsp from 2007 and 2008, which you can find here:

• http://niotso.org/files/shard-status-2007-08-31.xml
• http://niotso.org/files/shard-status-2008-08-01.xml

The format of Shard-Status-List is as such:

<Shard-Status-List>
<!-- The timestamp of when the shard-status.xml file was generated. This tag is never read by the game. -->
<Timestamp>Fri Aug 31 15:52:46 GMT 2007</Timestamp>
  <!-- The first shard (city). -->
  <Shard-Status>
    <Name>Dragon's Cove</Name>    <!-- The name of the city. -->
    <Rank>1</Rank>                <!-- This city appears first in the list of cities. -->
    <Location>UNDEFINED LOCATION</Location> <!-- This tag was removed after Pre-Alpha, but EA's servers still included it anyway. -->
    <Online-Avatars>2000</Online-Avatars> <!-- This tag was used in Pre-Alpha and the first versions of Play Test, but it was removed either before or after the version of Play Test FilePlanet gave out. -->
    <GMT-Range>-06+06</GMT-Range> <!-- A range of timezones. The game seems to ignore this field. -->
    <Status>Down</Status>         <!-- Valid statuses: Up, Down, Busy, Full, Closed, Frontier. -->
    <Status>Full</Status>         <!-- Multiple statuses can be combined. -->
    <Status>Frontier</Status>     <!-- Frontier means the "hardcore" city and was used only with Dragon's Cove. -->
    <Map>10</Map>                 <!-- Map 10: The Dragon's Cove map. -->
    <MotD-List>                   <!-- "Message-of-the-day"s. -->
      <!-- The first message of the day. -->
      <MotD>
        <MotD-From>Fatbag</MotD-From>
        <MotD-Subject>Happy Hacking!</MotD-Subject>
        <MotD-Message>This server is hosted by Niotso.org. Spread the word!</MotD-Message>
      </MotD>
 
      <!-- The second message of the day. -->
      <!-- ... -->
    </MotD-List>
  </Shard-Status>
 
  <!-- The second shard. -->
  <!-- ... -->
</Shard-Status-List>

Status should be one or more of the following: Up, Down, Busy, Full, Closed, Frontier. "Closed" seems to be the same as Busy. "Frontier" means the hardcore city and was used only with Dragon's Cove. Multiple statuses can be combined, usually in this order:

• (Required) One of the following: Up, Down
• (Optional) One of the following: Busy, Closed
• (Optional) Full
• (Optional) Frontier

For example, specifying Down, Busy, and Full causes the game to say "Online: No, Status: Busy/Full" under the "What City Do You Want to Live In?" menu.

The list of maps is as follows:

Note: Pre-Alpha connects to the same location, /cityselector/shard-status.jsp. The format of Shard-Status-List in Pre-Alpha is as follows:

<Shard-Status-List>
  <Shard-Status>
    <Location>public</Location>
    <Name>somename</Name>
    <Status>somestatus</Status>
    <Online-Avatars>20</Online-Avatars>
  </Shard-Status>
</Shard-Status-List>

In Pre-Alpha, if Location is not defined (anywhere in the server response) as "public", the rest of the XML file is ignored. Also, Status should be only: Up, Down.

The user can enter the city by selecting an existing Sim or by asking to create a Sim in a new city.

When the user enters the city, the client connects to https://tsocs.tso.ea.com/cityselector/app/ShardSelectorServlet?shardName=&avatarId= in order to get the hostname and port of the city server, as well as obtain the avatar id of the newly created Sim (if entering Create-A-Sim). The client passes two GET variables:

• The "shardName" GET variable is set to the name of the city (as specified by shard-status.jsp).
• If the player is entering the city as an existing Sim, the "avatarId" GET variable is set to that avatar's ID. (If the player is instead asking to create a new Sim, no avatarId is specified in the request.)

ShardSelectorServlet should verify that the action is legal, generate an avatar id for the newly created Sim (if the player is entering CAS), and respond with either Error-Message, Patch-Result, or Shard-Selection as the root element.

Error-Message follows the same format as described in InitialConnectServlet with the same recognized error number of 132. If shard-status.jsp returns Error-Message, once the user dismisses the error, the user is brought back to the login screen.

Patch-Result follows the same format as described in InitialConnectServlet.

The format of Shard-Selection is as such:

<Shard-Selection>
  <!-- The host may be a domain name or IPv4 address. -->
  <!-- Note that "100" is appended to the port number; hence, 49 becomes port 49100. -->
  <Connection-Address>localhost:49</Connection-Address> <!-- Host: localhost, Port: 49100 -->
  <Authorization-Ticket>0123456789abcdef0123456789abcdef</Authorization-Ticket>
  <PlayerID>5</PlayerID>                 <!-- The player id for the EA account. -->
  <ConnectionID>1</ConnectionID>         <!-- Perhaps 1 means Blazing Falls, 2 means Alphaville, ... -->
  <EntitlementLevel>0</EntitlementLevel> <!-- The EntitlementLevel is currently only visible when the CSR Tools dialog is shown in-game. -->
  <AvatarID>1337</AvatarID>              <!-- The avatar id for this avatar. -->
</Shard-Selection>

In response to Shard-Selection, the client will produce the file launchfile.lch with the following data:

[Launch]
Title=RoomServer
App=RoomServer
Missing=The Sims Online is not installed on your machine.
Server={host}:{port}100
Product=1
ServiceIdent=P
Authserv=VoltronAuthserv
[identification]
user={PlayerID}
password={Authorization-Ticket}
email={PlayerID}@{ConnectionID}*{EntitlementLevel}

Notice that "100" will be appended to the port specified by Shard-Selection. For instance, if Shard-Selection specifies a port of 33, the client will connect over port 33100.

Note: Pre-Alpha connects to /cityselector/shard-selector.jsp rather than /cityselector/app/ShardSelectorServlet. The format of Shard-Selection in Pre-Alpha is as follows:

<Shard-Selection>
  <Connection-Address></Connection-Address>
  <Authorization-Ticket></Authorization-Ticket>
  <PlayerID></PlayerID>
</Shard-Selection>

DeleteAvatarServlet is used for three functions:

• Retiring a Sim (command=delete) - If the player chooses to retire a Sim, the client connects to https://tsocs.tso.ea.com/cityselector/app/DeleteAvatarServlet?command=delete&avatarId= with the "avatarId" GET variable set to the ID of the avatar to be deleted. DeleteAvatarServlet should delete the avatar and respond with either Error-Message, or any arbitrarily-named tag other than Error-Message (such as "<root />" or "<x />"), as the root element. (Note that if there is no root element in the response, the client will display the error "The game has experienced an internal error".)

• Moving a Sim (command=move) - If the player chooses to move a Sim to another city, the client connects to https://tsocs.tso.ea.com/cityselector/app/DeleteAvatarServlet?command=move&avatarId=&city= with the "avatarId" GET variable set to the ID of the avatar to be moved and the "city" GET variable set to the name of the destination city. DeleteAvatarServlet should move the avatar; the response is the same as for command=delete.

• Moving a Sim (command=primary) - If the player chooses to change his primary Sim, the client connects to https://tsocs.tso.ea.com/cityselector/app/DeleteAvatarServlet?command=primary&avatarId= with the "avatarId" GET variable set to the ID of the new primary Sim.

Error-Message follows the same format as described in InitialConnectServlet with the same recognized error number of 132.

Afterwards, if the server did not return Error-Message, the client reconnects to AvatarDataServlet to reload the list of avatars.

Note that if there is no root element in the response, the client will display the error "The game has experienced an internal error".

Note: Pre-Alpha connects to /cityselector/delete.jsp rather than /cityselector/app/DeleteAvatarServlet. The server responses are the same.

When the player logs out, the client connects to https://tsocs.tso.ea.com/cityselector/app/LogoutServlet to log out. LogoutServlet should simply log the user out; the client discards the server's response, even if it was not 200 OK.

Note: Pre-Alpha does not make use of LogoutServlet.

This is a backup of the Niotso Wiki Page - Maxis Protocol

Please see original source of this wiki page here.